Most curated newsletters die from the same thing. The first six issues are great because the saved-up reading from the past two months goes in. Issue seven is harder. By issue ten, you're scrambling on Sunday night to find five things worth linking. By issue twenty, the newsletter is a chore, the writing is flat, and you're posting links you haven't really read.
This guide is about building a curation system that doesn't depend on you having a great week of reading. The system holds the material between weeks, the agent helps with the structural assembly, and your weekly hour is spent writing the commentary that makes the newsletter actually worth reading.
What a curated newsletter is actually for
The job of a curated newsletter isn't to share links. Anyone can share links. The job is to give the reader your perspective on what's worth their attention this week — the small synthesis you bring as someone who's been paying attention to this topic for a while.
The links are scaffolding. The commentary is the product.
Which means the system has to make commentary cheap. If writing the commentary takes thirty minutes per item because you have to re-read everything you saved, the newsletter dies. If the commentary is already in your vault from when you read the piece, the weekly assembly is a different kind of work.
The shape that holds:
- A saved-reads inbox — every article, podcast, video, or paper you read goes in, with a couple of lines of your own commentary while it's fresh.
- A themes file — three to five recurring topics your newsletter is about, with the threads you've been tracking under each.
- A draft surface — one page per issue, where the actual writing happens.
- A weekly assembly pass — the hour where the issue gets put together.
If you also write longer-form content alongside the newsletter, this pairs with how to draft emails, proposals, and newsletters inside your notes app for the writing-side workflow.
The saved-reads inbox — capture with commentary
The single biggest difference between a healthy newsletter and a struggling one is whether the commentary gets written when you read the piece, not when you sit down to publish.
The pattern: when you read something worth saving, you save it with two sentences. What it is. Why you cared. That's it. Two sentences. Thirty seconds.
The "Saved reads" sub-page holds everything. An inline database via the :::database::: directive works well — columns for title, source, link, date saved, your commentary, the theme it maps to, and a status (unused / used in issue / archived). Adding a row takes thirty seconds.
For PDFs of papers or longer reads, drop the PDF on a sub-page under the entry. It auto-converts to markdown via docstrange, so the paper becomes searchable text. When you reference it later in a newsletter and want to quote a specific passage, the agent can pull it.
The discipline is the commentary. Without the two sentences, you're back to scrolling through links on Sunday night trying to remember what each one was about. With them, the issue assembles itself.
The themes file — what the newsletter is actually about
Most successful curated newsletters have a small set of recurring themes that the curator keeps coming back to. Not a single topic — a handful of related angles that compound over months. The reader subscribes because they trust your perspective on those specific things.
A "Themes" page captures them. Three to five themes, each with a sub-page that holds the threads you've been tracking. For each theme: what you're paying attention to, the recurring questions, the people whose work you keep coming back to, the open arguments you don't think have been resolved.
When you save a new read, tag it to a theme. Over months, each theme page builds up a real archive of relevant material. When you draft an issue, the themes page is the source — not just the saved-reads inbox.
The agent reads across the themes when drafting. "Pull every saved read from the past two weeks tagged to the customer-success theme. For each, summarize what's interesting and how it connects to the threads I've been tracking. Suggest which two should be the focus of this week's issue."
The weekly assembly pass
A regular assembly cadence is what keeps the newsletter healthy. Pick the day. Block the hour. Do the issue then.
The hour breaks roughly into four parts.
First, fifteen minutes of triage. Open the saved-reads inbox. Look at everything from the past week. Decide what's making the cut. Mark the rest as archived. The agent helps: "Pull every entry from the past seven days. Group by theme. Flag the three that are most likely to be the lead item."
Second, fifteen minutes of structural drafting. Open the new issue page. Decide the structure — usually a small set of items, organized by theme or by some throughline you've spotted. Ask the agent to draft the link blurbs from the saved-read commentary you already wrote. "From the commentary I wrote when I saved each of these five reads, draft the link blurbs for the issue. Keep my voice. Don't add filler."
Third, twenty minutes of editorial work — writing the introduction, tightening the link blurbs, finding the throughline that makes the issue feel intentional rather than a list. This is the part the agent doesn't do well and shouldn't try.
Fourth, ten minutes of polish — checking links, fixing the headline, scheduling. Done.
The hour is real work, but it's bounded. The newsletter ships. The Sunday-night scramble doesn't happen.
The introduction — where the newsletter actually earns its keep
Most curated newsletters live or die by the intro. The link blurbs are functional; the intro is where the curator's voice comes through. It's also the part most people resent writing because it requires actually thinking.
The intro shouldn't be assembled by the agent. It should be written by you, in your voice, about something you actually have a view on this week. The agent can help with the structural part — pulling the relevant context from your themes file, surfacing the connection between the items in the issue, suggesting where the natural through-line is. But the writing is yours.
A trick that helps: the intro doesn't have to be about the issue's items. It can be about something you're thinking about that ties to one of the themes. The reader subscribes for your perspective. The intro is where that perspective shows up. The items are downstream.
For pulling reference material when writing the intro, ask the agent: "From the themes file on the customer-success theme, what's the most recent angle I've been developing? Pull the last three saved reads on it and the commentary I wrote." You get the relevant context in front of you. You write the intro from a real place, not from a blank page.
Building the back catalog into a research asset
A long-running newsletter has a real archive. Hundreds of issues. Thousands of links. Years of your own commentary. Most curators leave that archive on a Substack page and rarely look at it again.
Pulling the back issues into your vault changes that. When you're working on the next issue and want to remember whether you covered a particular topic before, the agent reads across the archive: "Find every issue in the past year where I covered the rural broadband angle. Pull the items I linked and the commentary I wrote. Have I ever mentioned the FCC ruling from March?"
You get a real answer. You stop accidentally repeating yourself. You spot the recurring theme you've been developing without naming it. You notice that two items from different issues are actually the same conversation, and the next issue can connect them.
For curators who repurpose material into other formats — long-form posts, podcast episodes, talks — the archive becomes a content engine. See content repurposing across platforms for the multi-channel workflow that runs alongside.
Subscriber feedback and a boundary on AI
A newsletter is also a relationship. A "Reader feedback" sub-page captures the threads worth coming back to — notable replies, useful pushback, questions that recur across multiple readers. Three weeks later when you're drafting on a related theme, the agent can pull from the feedback: "Find every reader reply from the past month that pushed back on the rural broadband angle. Pull the substantive points." Some become the seed of the next issue. For replies themselves, the discipline is just to do them — the curators who reply consistently are the ones whose newsletters compound.
A practical note: the agent helps with assembly, structural drafting, and surfacing material from your archive. It doesn't write your commentary. Newsletters that are AI-generated end-to-end have a flat tone you can hear in three sentences. The shape that works: AI does the chores — pulling reads, drafting the link blurbs from commentary you already wrote, surfacing connections across the archive. The intro is yours. The commentary is yours. For the broader practice of building a content engine from your own notes, see how to build a content calendar from your notes.
A calmer way to publish weekly
Curating a weekly newsletter doesn't have to feel like a treadmill. The treadmill comes from doing the curation in one panicked hour with no system. The shape that calms it down is small, consistent capture during the week, a themes file that gives the work direction, and a bounded assembly hour that produces a real issue every time.
Try Docapybara free — sign up, build a themes file with three things your newsletter is about, drop in the last ten things you've read with a sentence of commentary on each, and ask the agent for a draft of the next issue grounded in that material.