- Automate the busywork around the editor, not the editor.
- Build it as separate stages, so each can be checked, paused or improved on its own.
- Spend most of your effort on checks: citations, grounding and repetition across issues.
- Nothing reaches a reader without a person approving it.
Start with the job, not the model
A newsletter issue is not one task. It is a dozen small ones: finding stories, ranking them, checking sources, writing, formatting, filling sponsor slots, scheduling and sending. Language models are very good at some of these and unreliable at others. The trick is to give each step to the right worker, person or machine, and to connect them so nothing gets copied and pasted.
When we build a production pipeline, we map those steps first. Only then do we decide where AI earns its place.
The pipeline, stage by stage
- Research: 42 stories pulled from 11 sourcesDone
- Ranked and deduplicated against last 10 issuesDone
- Draft: 6 sections, 1,240 words, house styleDone
- Checks: citations, grounding, topic and tone18/18
- Render: template v4 with sponsor Northwind FreightDone
- Scheduled in ESP for 6:30 AM, pending approvalReview
Illustrative example. Names and figures are fictional.
1. Sources
Pull candidate stories automatically from the feeds, sites and data sources your editor already trusts. Public data APIs are worth adding here: numbers that refresh themselves before every issue are one less thing to look up.
2. Research and ranking
Rank stories by relevance and source quality, and remove anything covered in recent issues. A simple source-tier list, with primary reporting above aggregators, does more for quality than any prompt.
3. Drafting
Draft in your house style, from your best past issues, with explicit rules: length per section, tone, words you never use. Treat the draft as a first pass for your editor, never as finished copy.
4. Checks
This is where most pipelines cut corners, and where yours should not. Check that every citation points to a source that actually supports the sentence, that claims are grounded in the source text, and that nothing off-topic slipped in. A second, cheaper model is well suited to this kind of verification.
5. Rendering
Fill a tested email template automatically, including any sponsor slot booked for that date, with the right disclosure label and tracked links.
6. Review and send
The draft lands in your ESP as a scheduled draft, not a sent email. Your editor reads it, changes what they want and approves the send.
Guardrails that matter
- Citation matching. Every link must support the sentence it is attached to.
- Diversity across issues. Avoid repeating the same story, source or angle week after week.
- Banned phrasing. Keep a list of words and patterns that read as machine-written, and filter them out.
- Deliverability checks. Screen subject lines and copy for spam-trigger wording before scheduling.
- Kill switches. Make it easy to pause any stage without breaking the rest.
What to build first
Do not automate everything at once. Start with the step that eats the most time, usually research and ranking, and ship it to your editor within weeks. Each release teaches you what the next one should be.
What most guides miss
Lessons from systems we have built and run, not the usual checklist.
Repetition is the quiet killer
Most pipelines check a single issue in isolation. Readers notice when the same story, source or angle shows up three issues in a row. Check every draft against your recent issues, not just against itself.
Check the citation, not just the claim
A model can write a true sentence and attach the wrong link. Verify that each linked source actually supports the sentence it sits next to. A second, cheaper model does this well.
Write rules for what the model must never do
Banned phrases, competitor names you never mention, words that read as machine-written, and spam-trigger wording in subject lines. A short list of hard rules beats a long, polite prompt.
Warm the archive before you send
If issues link to a web archive, load those pages before the email goes out. The first readers to click should not be the ones waiting for a slow page.
How we do it
We built exactly this kind of pipeline for an independent B2B newsletter published three times a week by one operator. It has produced every issue since May 2026, and the editor still reads and approves each one. Read the case study, or see what we build for operations.