I Built an AI Agent to Run My Newsletter Without Me. The First Version Wasn't an Agent.

Last reviewed: 16 August 2026

Worth reading next: How to Have AI Draft a Letter for You (Without It Sounding Like a Robo.

By Lilach Bullock

I am about to spend three weeks travelling for work across the US and UK.

My calendar is full. My laptop will not always be open. I will be moving between meetings and airports on a packed work trip. And my newsletter is still supposed to arrive every week as if none of that is happening.

That made this experiment fairly urgent.

I did not want another clever prompt that writes an email when I remember to paste something into it. I wanted an AI newsletter agent that could do the whole preparation job in the cloud: find the AI news, check the dates, decide what matters to a small business, write the digest, prepare the Weekly Experiment when there is one, choose four useful resources, write the newsletter, run the quality checks and put everything in front of me for approval.

Then stop.

It must never publish or send under my name without me.

That sounds like a small distinction. It is the entire experiment.

The first version I found claimed to be an agent. It was a folder on my computer.

The first cloud version I built failed before it wrote a word.

Both failures taught me more about building useful AI agents than another hundred agent demos ever could.

The rebuild in public, experiment by experiment

If you are new here, I have been rebuilding my business in public and showing the good weeks, the ugly ones and the experiments I would rather forget.

1. Week 1: I de-indexed 1,300 pages to save my website
2. Week 2: My open rate crashed to 11%
3. Week 3: The unglamorous SEO work nobody talks about
4. Week 4: I triaged 1,219 crawled, not indexed pages
5. Week 5: I took my open rate from 11% to 70%
6. Week 6: I conquered my inbox instead of my blog posts
7. Week 7: The income stream that saved my business three times
8. Week 8: I let Claude loose on my website and went to do my hair
9. Week 9: I redesigned my newsletter and the click rate imploded
10. Week 10: I built a tool to automate WordPress publishing
11. Week 11: I dug 786 de-indexed pages back out
12. Week 12: AI inbox management gave me my life back
13. Week 13: The month my website started paying me again
14. Week 14: My rebuild in public numbers, the month traffic crossed half a million
15. Week 15: A stranger proved I was getting found by AI
16. Week 16: How I set up cold email with AI
17. Week 17: My hands-free cold email automation was an epic failure
18. The five-month passive income comeback
19. Week 19: I asked one AI to audit another

You can also browse the full experiment archive here.

This experiment is the next part of that story.

The short answer: can AI run a weekly newsletter for you?

AI can run most of the preparation for a weekly newsletter if you turn the job into a system with fixed inputs, evidence rules, quality gates and clear stopping points.

It can research, shortlist, draft, check, package and queue the work in the cloud.

It should not be allowed to make unverified claims, invent a personal story, mistake an old announcement for new AI news or send to thousands of people without approval.

The useful version is not hands-free publishing.

It is hands-free preparation with human judgement at the edge.

That matters because a newsletter is not one job. Mine contains several:

• a long Weekly AI Digest built from current sources
• a long Weekly Experiment built from something I have done
• four links to useful free resources
• the email itself
• the locked Thank you subject line and preview text
• SEO, AI-search and internal-linking work
• WordPress preparation
• newsletter-platform preparation
• several rounds of checking

When I treated all of that as "write my newsletter", the AI could produce something competent and completely forgettable.

When I treated it as an operating system, the weaknesses became visible enough to fix.

The problem I was trying to remove

The newsletter has become a recurring tax on the end of my week.

The writing is only part of it. There is the research, the tabs, the source checking, the decisions about what deserves a place, the internal links, the uploading, the formatting and the final horrible moment where I wonder whether the subject line is good enough to justify bothering 15,000 people. I had already tested how much the newsletter design and delivery experience could affect the result. This build had to protect the whole chain, not simply generate paragraphs.

That last part matters more than it sounds.

My list is not growing quickly enough at the moment. Every send loses subscribers. I learned the hard way what happens when an email open rate crashes to 11%, and I am not interested in handing that risk to an unsupervised writing tool. If I am not adding enough people between sends, a weak newsletter does not merely underperform. It makes the list smaller.

So the goal was never to make newsletter production faster at any cost.

The goal was to remove the mechanical work without removing the judgement that protects the list.

I wanted the agent to arrive with the work done and ask me for decisions, not labour.

For a normal week, the only editorial input should be the Weekly Experiment brief. During my travel weeks, even that slot is optional. No experiment means no experiment. The agent must not make one up and must not hold the rest of the newsletter hostage.

The first uncomfortable discovery

I had already asked for this system.

I found the earlier work. There was a neat local scaffold with schemas, scripts, a runbook, tests and a state file. It could assemble sources and produce review files. It was useful in the same way my earlier attempt to automate WordPress publishing was useful: it proved the parts, but it did not yet own the complete recurring job.

It looked like the beginning of an agent.

It was not running in the cloud. It had no weekly schedule. It could not wake up without my computer. It could not do the job while I was travelling.

In other words, it was a useful prototype wearing an agent's name badge.

This is one of the biggest traps in AI automation. I had already seen it when my AI cold email automation failed: connecting several capable tools does not make the whole system reliable.

A workflow is not autonomous because it has several steps. A script is not an agent because it produces a polished output. A prompt is not a system because you saved it somewhere sensible.

If it still needs you to remember it, start it, feed it and move its output to the next tool, you have automated a task.

You have not removed the job.

What I built instead

I split the newsletter into five layers.

Layer 1: evidence

The agent begins with sources, not prose. That rule came directly from my experiment in asking one AI to audit another, where a plausible report collapsed as soon as a second system checked the live evidence.

For the AI Digest, it collects current announcements from official company sources. Every story needs a title, source URL, publisher and publication date. If the date cannot be proved, the story does not get into the writing prompt.

For the Weekly Experiment, it needs a verified brief based on something that happened in my business. If there is no brief, the slot stays empty. The AI Agent Brief Template is the same idea in a form you can steal for your own system.

For the free resources, it starts with links that have already earned clicks from my own audience. It does not pick four at random because the titles sound nice. The AI Savings Calculator also gives the agent a commercial filter: is the job worth automating in the first place?

This is deliberately boring. Boring evidence is what stops exciting nonsense reaching the page.

Layer 2: judgement

The agent ranks AI news by the question my readers care about:

What does this change for a small business owner?

A model release can be technically impressive and commercially useless. A tiny feature change can save someone an hour every week. The digest is not there to prove I read the news. It is there to save readers from reading all of it.

That means each item has to answer three things:

1. What changed?
2. Why should a small business care?
3. What can they do with it?

If a story cannot survive those three questions, it is noise.

Layer 3: writing

This is where I refused to save pennies.

Writing is the weakest part of most AI systems, especially when the output has to sound like one person rather than the average of the internet.

So the agent uses the strongest available model for the digest, experiment and newsletter. It gets my previous newsletters, my best-performing structures, my banned phrases, my punctuation rules, my click data and examples of copy I have rejected.

The cheap work stays cheap. Code counts links. Code checks dates. Code finds forbidden punctuation. Code checks whether the experiment exists.

The expensive model is reserved for the part where judgement and language matter.

Then a separate model reads the result as a hostile editor. Its job is not to be encouraging. Its job is to find generic AI language, weak curiosity, repetition, unsupported claims and reasons someone might unsubscribe. This is the production version of the independent AI audit method I tested the week before.

I would rather have one strong draft and one brutal review than pay five models to produce five flavours of beige.

Layer 4: hard gates

The agent has three approval gates:

• Weekly AI Digest approved
• Weekly Experiment approved, when one exists
• final newsletter approved

They are separate on purpose.

Approving the digest does not approve the email. Approving the experiment does not approve a subject line. Editing an approved file changes its fingerprint and cancels the approval.

There is no send button in the scheduled workflow. There are no WordPress credentials in the preparation job. There is no Kit sending code tucked away behind a setting. The Agent Guardrails Checklist contains the permission checks I would use before giving any agent access to customers, money or live publishing.

The agent can prepare everything while I sleep.

It cannot impersonate my judgement.

Layer 5: cloud execution

The operator now lives in a private cloud repository. A scheduled workflow wakes it each week whether my laptop is open or not.

It collects sources, runs the writing and review passes, creates a private review bundle and opens an approval item. That separation matters because my AI inbox management experiment taught me that useful automation needs a clear line between preparing an action and taking it.

For the three weeks I am travelling, the Weekly Experiment is switched off. The agent will still build the digest-led newsletter and choose the four supporting resources. It will not wait for a story I have already decided not to write.

That is the difference between a useful system and a system that becomes another person asking me for something.

The false-news trap I nearly shipped

The most useful part of this build was not the writing.

It was catching a freshness failure.

During research, several old product announcements appeared to be new. The sitemap showed a fresh modification date, so at first glance they belonged in this week's digest. I have spent months rescuing de-indexed pages and working with crawl data, so I knew a modification date and a publication date were not the same thing. The first source collector still treated them as if they were.

They did not.

One announcement came from months earlier. Another was even older. The page had been updated or recrawled, but the news itself had not happened this week.

This is a nasty problem because the source looks authoritative. It is the company's own website. The date looks current. The model has no reason to feel uncertain unless you force it to distinguish between the page modification date and the publication date.

So I changed the rule.

A sitemap date is not evidence that a story is current.

The agent now needs the publication date from the article or its official publication feed. If it cannot prove that date, it rejects the story.

This sounds like a small technical fix. It is exactly the kind of small technical fix that decides whether your content is trustworthy.

Then the cloud version failed its first test

Once the operator was in the cloud, I ran it with this experiment as the brief.

It stopped at the source gate.

Zero usable stories.

That was not because there had been no AI news. Two official sites did not provide the feeds their obvious URLs suggested, and a tiny XML parsing mistake discarded valid links from the feeds that did work.

The agent did the correct thing with bad inputs.

It refused to write.

That is a success disguised as a failure.

The dangerous version would have carried on, filled the gap from memory and produced a confident digest with stale stories. The safe version made no copy at all and showed me the broken step.

I repaired the feeds and the parser, then ran it again.

The second run found 21 current stories from official sources.

Then the writing service returned a 410 error.

The free GitHub Models route I had wired into the first cloud build had been retired on 30 July. The workflow was sound. The engine I had put inside it no longer existed.

That is another useful test for an agent: what happens when the service underneath it changes while nobody is watching?

I replaced the retired route with a direct Anthropic connection. The API key is encrypted inside the private repository. The strongest model writes. A separate model attacks the result as an editor. The workflow itself has no WordPress or newsletter sending credentials.

The third run collected the sources and produced all three drafts in just over five minutes.

Then the hard quality gate blocked them.

The writing model had used several phrases I ban because they make copy sound like generic AI. It had been told not to use them. It used them anyway.

A banned phrase in a finished draft proved the point: an instruction is not a control.

I added a deterministic cleanup pass, a structured hostile review, one automatic repair round and a model-call ceiling. If the repaired copy still fails, the run stays blocked and uploads the evidence instead of hiding the failure.

The fourth cloud run reached the hostile editor.

The editor then spent its entire output allowance thinking about the drafts and returned no answer at all.

That is a wonderfully modern failure: the system used the whole budget doing invisible work, then forgot to deliver the thing the next step needed.

I increased the review allowance and kept the no-text check. A missing verdict still blocks the run. The workflow does not treat expensive silence as approval.

The fifth cloud run made it through drafting, automatic repair and the second hostile review in eight minutes.

The reviewer still blocked it.

One repaired FAQ had been cut off because the writing model used its entire output allowance. The newsletter also contained a number the reviewer could not trace because I had given the writer the verified resource evidence but forgotten to give the same evidence to the editor.

Both are system failures, not copy edits.

I changed the operator so an output that reaches its token ceiling is rejected as potentially incomplete. I also gave the editor the same source and resource packet as the writer, so it can distinguish an invented claim from a verified one.

The sixth run finished without truncation.

The second editor caught two smaller factual mismatches. The deterministic check caught something the editor did not: repairing the Digest had reduced its internal links from the required twelve to eight.

That is exactly the kind of regression a polished rewrite can hide.

I added a second repair round and moved the link requirements into the repair process itself. The agent now counts at least twelve internal links in the Digest, twenty-five in the Experiment and fourteen click opportunities in a newsletter that contains an Experiment. It also checks for two links to every featured resource and two meeting links at the close.

Six cloud tests. Six different failures. Every one produced evidence. Not one stale story, truncated article, unsupported claim or unapproved newsletter reached a live system.

"It writes beautifully" is a poor standard for an AI agent.

A useful agent must also know when it has not earned the right to write.

What the agent does every week

1. Wake up in the cloud

The job runs on a schedule. It does not rely on my laptop, a browser tab or my memory.

2. Build a dated source packet

It gathers official AI announcements inside the allowed date window and stores the publication evidence with every story.

3. Reject bad inputs

Undated, stale and duplicate stories are removed before a writing model sees them. Too few valid stories blocks the run.

4. Rank for business usefulness

The agent favours stories that change cost, speed, access, risk, customer experience or the way a small team works.

5. Draft the AI Digest

The long article follows the same structure as my strongest earlier digests: a pattern-led opening, practical story sections, what it means for your business, a short action plan, a final takeaway and useful FAQs.

6. Draft or skip the Weekly Experiment

If a verified brief exists, it writes the experiment and links the earlier series at the top. If the date is marked as a travel week, it skips the slot cleanly.

7. Choose four resources

The system can now choose from all 249 free resources plus my AI Savings Calculator. It is blocked if the four choices collapse into one theme: at least two must be non-agent resources from different areas such as LinkedIn, content, email, SEO, sales or lead generation.

8. Write the newsletter

The subject line is always Thank you because that is the proven open-rate winner in my own list. The agent creates preview options and one final email. The email's job is not to summarise every article. It opens loops strong enough to earn the click without making a promise the article cannot keep.

9. Attack its own work

The editorial reviewer looks for the AI smell: polished emptiness, predictable rhythm, repeated phrases, over-explaining, fake drama and sentences that could belong to anyone.

10. Run mechanical QA

The code checks the things models should never be trusted to remember consistently: the exact Thank you subject, forbidden punctuation, banned phrases, missing links, altered URLs, one-theme resource selections, wrong resource counts, absent files and locked approvals.

11. Hand me the decisions

I receive the digest, the experiment when there is one, and the final newsletter as separate review items.

Nothing publishes or sends until I approve it.

The part I am not pretending is solved

An agent can learn my structures, compare previous performance and remove a large amount of preparation.

It cannot decide whether I love the final email.

That is not a technical limitation I am trying to engineer away. It is the point where my name, taste and relationship with the reader enter the system.

The goal is not zero involvement.

The goal is zero avoidable involvement.

I should not be checking dates, counting links, searching for four resources, formatting headings or remembering which weeks need an experiment.

I should be making the decisions that deserve me:

• Is this interesting enough?
• Would I say it this way?
• Does the promise earn the click without becoming dishonest?
• Is this worth sending to 15,000 people?

That is a much smaller job than producing the whole thing from a blank page.

It is also the job I should have kept all along.

How to build a useful AI newsletter agent for your business

You do not need my exact stack. You need the same boundaries.

Start with the recurring contract

Write down what appears every issue. Separate required sections from optional ones. Define the number of links, the source window, the output format and the moment the system must stop.

If your format changes every week, the agent will spend its intelligence guessing the job instead of doing it.

Give it evidence before voice

Voice without facts gives you confident fiction in a familiar tone.

Create a source packet first. Every personal claim needs a receipt. Every news item needs a date and URL. Every recommended resource needs a verified destination.

Put code around the model

Do not pay a model to count to four.

Use deterministic checks for dates, counts, file presence, allowed domains, duplicate links and forbidden characters. Save model calls for ranking, synthesis, writing and critique. My AI Agent Failure Mode Playbook gives you twelve failure classes to test before the polished demo persuades you the work is finished.

Separate preparation from publication

Your scheduled job should not hold the keys to every live system.

Let preparation run automatically. Keep publication and sending behind explicit approval. The greater the possible damage, the closer the human belongs to the final action.

Test failure before success

Remove a source. Add a stale item. Delete the experiment. Insert forbidden punctuation. Change an approved file.

You learn more from watching the agent stop correctly than from watching a perfect demo finish once.

Design for the week you disappear

Do not test an automation only while you are sitting beside it.

Ask what happens when your laptop is closed, the optional input is missing, one source site changes and the first model call fails.

That is where the agent begins.

Everything before that is a promising prototype.

What this experiment changed for me

I started with a fairly simple demand: keep my newsletter alive while I travel.

I ended with a sharper definition of automation.

The value is not that AI can write a lot of words. We solved that years ago.

The value is that the work can begin without me, police its own evidence, refuse bad inputs, adapt when an optional section disappears, and arrive at the exact point where my judgement is useful.

That is what I want from every agent I build now.

I want a system that takes responsibility for the repeatable work and knows where its responsibility ends. I do not want a robot version of me, another dashboard or a folder full of clever prompts.

Frequently asked questions

Can an AI agent write a complete newsletter?

Yes, if the format, sources, voice examples and quality rules are explicit. The output still needs human approval when it carries a person's name or reaches a large audience.

What is the difference between a newsletter workflow and a newsletter agent?

A workflow follows fixed steps after someone starts it. An agent can wake on a schedule, gather inputs, make bounded decisions, handle optional branches, stop on failed evidence and package the result for approval without being manually moved between every stage.

Should an AI newsletter agent send automatically?

Mine does not. A newsletter reaches thousands of people under my name, so the downside of a bad output is too high. Preparation is automatic. Publication and sending require approval.

Which AI model should write a newsletter?

Use the strongest model you can justify for the final writing and editing passes. Use cheaper models or code for extraction, ranking, counting and validation. Saving a few pennies on the sentence your audience reads is poor economics.

How do you stop AI-written newsletters sounding generic?

Give the system a corpus of your strongest past work, examples you rejected, banned phrases, performance data and specific source material. Then use a separate editorial pass whose job is to block generic language, not praise the draft.

What happens when there is no Weekly Experiment?

The slot is skipped. The digest and four resources still run. Optional content should never block a recurring publishing system or tempt the model to invent a story.

How much does a cloud newsletter agent cost?

The infrastructure can be close to free when it runs once a week on included cloud automation minutes. The main variable cost is model usage. Keeping counting, checking and file work in code leaves the paid model budget for writing quality.

The final word

The first version was not an agent, and the first cloud run failed. I am pleased about both.

The local prototype showed me what had already been designed. The failed cloud run showed me the safety gate worked before stale or invented news reached a draft.

The failures are the useful part of building agents.

My newsletter no longer needs my laptop to begin. It does not need a made-up experiment to finish. It cannot send without me. And if the evidence is bad, it stops before the writing starts.

I will still make the final call.

I just will not spend the limited gaps in a packed work trip doing the work a well-built system can do first.