I built an AI writing pipeline. The hard part wasn't the AI.
A walkthrough of building an AI writing pipeline in Claude Code that takes a keyword to a near-publishable article. It covers research, outlining, drafting, and separate editing, fact-checking, and de-AI-flavor passes, with manual gates, brand voice inputs, and SERP and AI Overviews citation checks.

A few months ago, I set myself a goal: build a content pipeline inside Claude Code.
After all the tinkering, it can now keep our company blog and our external posts rolling out, and it will usually carry an article to within one step of publishing — about 95% of the way there.
The thing that surprised me most along this road wasn't how capable the AI turned out to be.
It was something else.
Getting an AI to write an article was never the hard part. The hard part is that you first have to decide: what does a publishable article actually look like?
So if you want to build a system like this too, don't rush to let the AI start writing.
Work backward instead.
First, answer one question: is this worth building?
For me, it is.
It squeezes every drop out of the modest resources I have, producing lots of content that no person alone could create.
But it carries risks. Two worries are always at the back of my mind — the AI talking in machine-speak, and the AI fabricating "facts." My defense is threefold: do more research, put more manual quality gates into the flow, and keep a dedicated fact-checker whose whole job is catching hallucinations.
And there's a bigger picture I should flag for you.
Google is now aggressively noindexing "non-commodity content" out of its search results. If your brand lives off that kind of content, this system may genuinely not be for you.
Also, this isn't something you can finish in a single night.
The good news: most of the parts you need to build agents, you probably already have in hand. If not, no panic — build it in stages, adjust it as you go. Once a feature is built, you can feed it into other workflows and reuse it.
What does "good" mean? Define that first, then work backward to the inputs.
This is the step that makes or breaks the whole system.
Picture the scenario: you have just a keyword, and you want to turn it into a publishable article. How many checkpoints stand between you and publishing?
What does a usable content pipeline actually have to produce?
Something useful and original, in your brand's voice; genuinely helpful to your ideal customer (ICP); accurate about your business and your product; and it reads like a human wrote it. Ideally, it also has a chance of ranking and of being cited.
Define "good" clearly first, and only then will you know what content to feed into the system.
What you feed it splits into two buckets.
The first is the constants. These are the same every run, hardcoded into the process, because they're the context shared by every task.
What do the constants look like? Let me run through them.
- Brand brief: who you are, who your ICP is. For B2B, write the industry, the job levels, the pain points — and you can pull the pain points straight out of customer call recordings. For B2C, write age, gender, occupation, pain points.
- Brand voice guide: note here that what's needed are "examples," not adjectives. Just writing "friendly but formal" won't cut it. You need positive examples and then counter-examples. And if you don't have any on hand? Then have an LLM distill a guide from your best content.
- Great samples: good briefs, good outlines, completed articles — bring a few of each.
- Descriptions of your product, service, and methodology: they help the AI talk accurately about what you do. Sales material is especially useful here.
- A list of your existing content: if you want internal-linking suggestions or to distinguish yourself from what you've already published, throw in a Screaming Frog export, or your sitemap.
- Internal research and case studies: these are the backbone of that "non-commodity" content — without them, the content goes soft.
- Writing and publishing standards: at the base level, that's generating a meta description, giving the piece a URL slug, and weaving in keywords naturally. If you want to go further, ask for SERP research, require an answer-first layout, and set paragraph-length rules.
The second bucket is the variables, things you fill in fresh each run: topic, angle, keyword.
Do you have other standards of your own? List them, and add them all in.
How do you decide the order? Copy a real newsroom, then add your own gates.
Once the inputs are in order, it's time to set the running order.
At its core, this is recreating a newsroom.
How do humans work? Pitch a story, outline it, draft it, revise it. At a big operation, different people are on each stage.
Your agents do these jobs. But there's one difference: the gates a real newsroom doesn't need are the ones you have to add yourself.
Why? Because the AI has two inborn flaws: it talks in machine-speak, and it fabricates "facts."
Should you also have a chief coordinator?
I strongly recommend adding an orchestrator agent. It writes out the whole flow start to finish, marking which agent is responsible for what. When the flow changes, that document changes with it. You can build it last — or build it alongside the other agents.
For every step below, I'll give you both "what documents to prepare" and "how to build it."
Step 1: Decide how to kick off
First, decide how you launch things.
For myself, I built a local panel — I type in a keyword and an angle, hit submit, and Claude starts researching.
If you have several different ICPs, or you want every article to carry a specific product, set those as initial inputs before you start.
My advice: start with just one content type, like blog posts or LinkedIn posts. Once that's running smoothly, add if/then so that one pipeline produces multiple content types.
Let one content type run end-to-end first; don't grab for too much at once.
Step 2: Research
As soon as the keyword goes out, the researcher should get moving: research the topic, check what your brand has already written, look for gaps on the current SERP that can be exploited, and then produce a dossier for the next agent to pick up.
The document I hand this agent: reliable, citable sources in the industry; sources to avoid; research requirements (timeliness, scope); your sitemap or content list; and links or documents from your primary research.
Should it look at the SERP? Decide clearly what kind of results you want it to analyze: do you want to see who's being cited in AI Overviews (Google's AI-generated answer summaries)? Or do you want the top sites beyond the directory-style listing sites?
How do you build it? Make "what the research should achieve" as specific as possible — especially "what counts as a good source," and what counts as your own content.
Step 3: Outline
After the research, have Claude produce an outline, then add one manual gate.
That way, before you've burned many tokens, you get a clear look at what the finished piece will be. At this point you have exactly three options: kill it, revise the outline, or continue.
Feed it what? Sample outlines, the voice guide, and the research agent's dossier.
How do you build it? Give it a sample outline and spell out what sections are required. If you like a hierarchical outline, say so explicitly.
Step 4: Write
The LLM draws on the outline and the research and starts writing the body.
Feed it what? The dossier, the outline, the brand voice guide, ICP details, case studies, and the primary research.
How do you build it? Give it a polished final piece written from an outline as the benchmark, and let it analyze the narrative flow, the logical progression, and its word choices. If you have rules of your own — like BLUF (Bottom Line Up Front) or MECE (Mutually Exclusive, Collectively Exhaustive) — tell it explicitly when it should apply them.
Step 5: Edit, fact-check, and strip out the "AI flavor"
Don't rush to hand the draft to a human. First, at least let the AI revise it once itself.
I gave it three roles.
- Editor: checks the piece against the brand guidelines, looks for words we shouldn't use, and reviews narrative structure, logical order, vague phrasing, and smooth transitions.
- Fact-checker: devoted to catching hallucinations, and deliberately combative in its stance — assume every fact in the article is wrong, then try to disprove each one in turn.
- An "anti-AI-flavor" editor: devoted to stripping out AI flavor. Hand it your own pet peeves, plus a checklist of the telltale signs of AI writing.
Each of those three passes opens a fresh context window, and the instructions are written up separately.
There's a pitfall I've walked straight into.
At first, I let a single editor handle both "structure + coverage" and "wording + de-AI-flavor" at the same time, and the output was only mediocre. When I split it into two, the results improved instantly. Tried to have the editor also do fact-checking? Both jobs fell apart.
Exactly — split things up where they need splitting.
It's best to run the editor twice before it goes to a human.
But remember: the AI, plus two rounds of editing, can carry an article very close to 99%. The very last step still has to be a human. An article no human has ever touched should never be published.
One last thing to say: context is the lifeline
The tools only get more powerful — Opus, Fable, and others all help you sketch out agent files much faster.
But even the fastest documentation won't rescue a system that has no context.
No ICP information, no high-quality content samples, no links to primary research — no matter how smooth the pipeline, we won't put out "non-commodity" content that lands.
The tools make things fast. You do the feeding.
Looking back, I've been building for months now, and the more I build, the more sure I am of one thing: a system that actually works is never won by how smart the AI is — it's won by how clearly you've thought through what "good" means, and by how steadily you feed clear input at every stage.
You may not agree with all of this, but it's worth a try.