Content Machine

The problem

Writing a usable SEO article takes hours. Keyword research, competitor analysis, outline, drafting, formatting, images, metadata. Seven manual steps that all happen in different tools, with most of the time spent switching between them.

The first attempt was a single oversized n8n workflow that tried to do everything in one prompt. It blew through context limits and burned tokens on tasks that didn't need a frontier model. The opposite extreme, a one-shot ChatGPT prompt, produced output that looked fine and read shallow.

Neither end of the spectrum works for production SEO content.

What it is

Five specialised agents, one responsibility each, chained in n8n. Each handoff is a JSON document that the next agent reads. No agent is allowed to know more than it needs to.

Strategist

Takes the keyword. Analyses search intent and competing content. Produces a research document. Facts, angles, what the top results miss.

Architect

Takes the research document. Decides the structural shape: H2s, subsections, key claims per block, internal-link opportunities. Output is a briefing the Writer cannot deviate from.

Writer

Takes the briefing. Drafts the article. Has access to the site's existing content map and sitemap so internal links resolve. Outputs prose, not Markdown.

Auditor

Takes the draft. Checks against the briefing. Does every required claim land, are the facts traceable, is the angle the one the Strategist set? Flags drift back to the Writer for one rewrite pass.

UX Writer

Takes the audited text. Splits walls into scannable blocks. Tightens subheadings. Adds bullet lists where prose drags. Mobile-first formatting pass.

Picking the model per agent

Not every agent runs on the same LLM. The Strategist and Writer need the strongest reasoning model available (currently Gemini for research-heavy work, Claude for prose). The Architect and Auditor work on structured JSON. Smaller, faster models handle those well. Choosing per-agent kept the total cost roughly a third of running everything on the biggest model, with no quality drop on the output that matters.

Guardrails as inputs, not edits

Each agent receives positioning and content guidelines as part of its system prompt, not as post-hoc editing instructions. "Eric's voice" is encoded once, in the guidelines, and every agent reads it. The Writer doesn't have to be reminded what to sound like; it already knows. This keeps the pipeline composable and stops the temptation to bolt on a "voice fixer" agent at the end.

The image side

Image generation is its own flow, parallel to the text. The Writer marks image placeholders with unique IDs in the draft. The image generator picks up the placeholder IDs, matches them to the briefing, and produces images that map back. Alt text is generated alongside. Files are converted to WebP before they land in WordPress.

What I'd do differently

Google Sheets as the intermediate store didn't hold up under concurrent runs. I moved it to n8n Data Tables and the reliability problem went away.

I underestimated evaluation metrics at the start. Per-run runtime, per-agent token cost, per-agent completion rate. Without those numbers, the pipeline can drift and nobody notices until the output gets bad enough to spot by eye. Worth setting up on day one.

Error handling has to be specific. "Agent stuck for > 60 seconds" and "API returned 429" are different failures and need different recoveries. A generic retry hides the first one and makes the second one worse.

On n8n

n8n is the right base for this pipeline. Orchestration cost is low, the API nodes work, and the visual layout means I can audit a run by looking at it. The parts I'd move out are the research and audit steps, where the agent works better with a real file-tree to navigate. Claude Code or an agentic IDE fits that shape. On the list.

What I do now: read the draft and approve it, or send it back. Everything before that step runs on its own.