How to Build an AI Agent Content Engine

A prompt that takes one idea and turns it into a researched brief, a draft, and the repurposed versions for every channel you use — running on a schedule, so publishing stops depending on whether you got to it that week.

01The Problem

Why content stalls at the research step

The writing is not the bottleneck. Deciding what to write about, checking what already exists, and finding the three sources worth reading is where every plan quietly stops.

The idea is easy, the research is not

Anyone can name a topic worth writing about. Turning that into something worth reading means finding out what has already been published on it, where the consensus actually is, and which of the obvious points are wrong — and that is a couple of hours of reading that happens silently, which is why it so often does not happen at all.

One piece, rewritten seven times

The work after the draft is mechanical and takes forever. A long post becomes a thread, a thread becomes an email, an email becomes five posts, and each needs a different opening, a different length, and a different level of assumed knowledge. Done by hand it is a full day of reshaping for something that should take minutes, so it is the part that gets cut.

Consistency dies of scheduling, not of ideas

Most content programmes do not fail because nobody had ideas. They fail in a fortnight when the person running it has a bad week, and nothing is scheduled to cover the gap. By the time the rhythm is broken, restarting feels like starting again, so the calendar stays empty and the channel goes quiet for good.

02The How-To

The content engine AI agent prompt, step by step

Copy it once, paste it into Zaira, and it takes the calendar from idea to channel: research what is already been said, draft against it, and reshape the result for each audience — with every claim traceable to something it actually read.

Content pipeline
Access to the @Zapier MCP server. Act as my content engine. My goal is that one researched idea becomes a finished draft and every channel version, on a schedule — so publishing stops depending on whether I had a good week.

My context

- Who I write for and what they care about: [e.g., early-stage SaaS founders hiring their first engineer] - My voice and the house rules: [e.g., concrete examples over advice, no hype words, British spelling, first person] - Channels and their formats: [e.g., 1200-word blog, newsletter, 6-post LinkedIn thread, 3 short posts] - Where content lives and who publishes it: [e.g., drafts in Notion, published by me] - Topics I will and will not write about: [list both] - What good looks like for a piece: [e.g., one argument, one memorable example, a specific number with a source]

Step 0: Check tools

List the Zapier tools you have (discover actions, enable, inspect, execute read and write actions). Use the discovery tools to find the exact actions available for my CMS and mailing list, then enable only the ones this workflow needs. Never guess an action name or its parameters — inspect first, then call.

Step 1: Research before drafting

Take this week's topic from my calendar and research it properly: what has already been published on it, what the consensus is, which commonly-repeated claims are actually wrong or outdated, and the three to five sources worth reading. Report what you found and what it changed about the angle before writing a word. If existing coverage makes the piece redundant, say so and propose a different angle rather than drafting the same article twice.

Step 2: Draft against the research

Write the draft using the argument and evidence from Step 1 — every factual claim traceable to something you actually read, with the source noted. One argument, not five. Include the specific number, example, or quote that makes it memorable, and flag any claim you could not verify rather than smoothing over it. My voice and house rules exactly, and no filler paragraph that exists only to reach a length.

Step 3: Reshape for each channel

From that one draft, produce every version in my format list: the newsletter, the thread structure, and the short posts. Each opens differently and assumes a different amount of context — a thread should not be the blog post chopped up. Every version keeps the argument and the source links. No channel version invents anything the draft did not say.

Step 4: Assemble and stop

Create a draft for the blog and a separate document for each channel version in the tool I nominated, each with the source list attached. Set them ready for my review with nothing published automatically. Do not schedule anything to go live without my approval.

Step 5: Report

Tell me the angle, the sources, the pieces produced, and where each one is waiting. Flag anything you could not verify and any topic where you think I should reconsider. Keep the whole report under 200 words — I want to know what to look at, not to read the work twice.
03Why People're Using

What this does once it's running

Three stages, one goal. The calendar keeps filling itself, so the question stops being what to post and becomes which of the finished pieces is actually any good.

The calendar fills without your attention

Because the engine runs on a schedule rather than on your initiative, a bad week becomes a gap in review rather than a gap in publishing. Most programmes die from one missed week, and this is the structural fix for that.

One idea, every channel

The reshaping that used to eat a day per piece happens in one run, with each version opening differently and assuming a different amount of context. That is the difference between repurposing and cutting up a post into fragments.

Claims come with their sources attached

Every factual claim traces to something the agent actually read, and anything unverified gets flagged rather than smoothed over. It is a meaningful constraint on the failure mode that makes AI-written content unpublishable.

04FAQ

Frequently asked questions

The practical questions people ask before letting an agent plan their content.

No — Step 4 assembles drafts in the tool you nominated and stops there, with nothing scheduled to go live. Publishing is the one step worth keeping as yours, because it is the only point where a human has looked at the piece and decided it is worth your name. Once you trust the drafts after a few weeks, the reshaped channel versions are the safest thing to release first, since they cannot introduce anything the approved draft did not say.

The context section is the answer, and specificity is what counts: two or three real sentences about your voice and house rules, plus an example of something you have written that sounds right. Vague adjectives get averaged into the same neutral prose. Step 1 also helps more than it looks — deciding the angle against what already exists is most of what makes a piece feel written by someone with a position rather than someone summarising.

It replaces the parts of the job that are mechanical — the research sweep, the reshaping, the format changes, the scheduling — which is most of the hours and none of the judgement. A writer using it does less formatting and more editing, and the thing they spend their judgement on is whether the argument is any good. If nobody on the team has that judgement, this produces a high volume of work that does not deserve to be published.

Step 1 is the safeguard: it checks what has already been published on the topic and tells you plainly when a piece would be redundant, proposing a different angle rather than drafting a near-duplicate. That matters most for the long tail, where the same thin article at six URL variants is worse than no article. Do not let the engine publish to a new URL by default — the duplication problem is created at the publishing step, not the drafting one.

The prompt is written for the formats you list in the context section, and each one is a reshaping of the same draft rather than new work, so adding channels is mostly naming. Zapier charges are worth checking against your plan for the volume you plan to run, since that is the part that scales with output rather than with research. Start with two channels and one weekly piece; the value is in the rhythm being unbroken, not in the width.

Only what Step 0 discovers and enables — the actions for your CMS and mailing list, and nothing else. Discovery happens before any action is called, and Step 0 tells it not to guess action names or parameters, because a guessed write action against a real CMS is the failure mode worth designing against. You can revoke the connection from your Zapier account at any time, and keeping it to drafting rather than publishing keeps the blast radius small.