Inside the Agent System That Runs My Content

A multi-agent system is one where a lead agent plans a job, hands slices of it to smaller agents that each do one thing well, and stitches their results back together. Think of a general contractor and a crew, not one person doing every trade. The value is not more intelligence. It is division of labour and a place to check the work.

I get asked how my content pipeline actually runs, usually by people who assume there is some single clever prompt behind it. There is not. There is an architecture, and the architecture is the whole point. A single agent asked to do a long, messy job tends to wander. A crew with a foreman does not, as long as you build the foreman properly.

Here is how mine is wired, and why each piece earns its place.

The orchestrator does no real work

The mistake I see most often is asking one agent to research, decide, write, and check itself in a single pass. It runs out of attention halfway through and starts confusing its own earlier guesses for facts.

So my lead agent, the orchestrator, is deliberately kept thin. Its only jobs are to hold the plan, decide what happens next, and route each slice of work to a subagent built for exactly that slice. It reasons about sequence and delegation. It does not draft copy or crunch sources itself.

When a job is small enough to see in one glance, this feels like overkill. On a job that runs unattended for an hour, it is the difference between a finished draft and a confident mess.

Each subagent has one job and a narrow brief

The research agent gathers and clusters sources. The draft agent writes in my voice from those sources. The check agent verifies claims and sends weak work back. None of them knows about the others. Each gets a narrow brief, does its one thing, and returns a clean result.

Narrow is the trick. An agent told to "write a good post" has infinite ways to disappoint you. An agent told to "write 200 words on this single point, using only these three sources, in this voice" has almost nowhere to go wrong. I push as much of the judgement as I can up into the brief, before the agent ever starts.

Here is what a real brief looks like when it leaves the orchestrator. Note how much of it is constraint rather than instruction:

agent: draft
task: "Write section 3 of the post: why narrow briefs beat clever prompts"
constraints:
  words: 180-220
  sources: [notes/agent-brief-tests.md]   # nothing else, no web
  voice: voice-principles.md
  banned: ["delve", "leverage", "seamless", "game-changing"]
  dashes: 0
returns: markdown_only        # no commentary, no preamble
on_missing_evidence: "say 'I could not confirm this' and stop"

Everything in that block is a decision I made once, in advance, so the agent never has to make it at run time. The brief is where the quality is set.

The self-correcting loop is where trust comes from

The part that makes this safe to leave alone is the check agent and the loop behind it. Work does not go straight from draft to done. It goes to a verifier whose only job is to be sceptical, and if the draft fails a check, it goes back with the specific reason, and the draft agent tries again. There is a hard cap on retries so it can never spin forever.

Stripped of everything else, the loop is about ten lines, and the cap on line 2 is the part that keeps it safe to walk away from:

let draft = await draftAgent(brief);

for (let attempt = 0; attempt < 3; attempt++) {   // hard cap, never unbounded
  const check = await checkAgent(draft, brief);   // sceptic, sees the brief too
  if (check.passes) return draft;
  draft = await draftAgent({ ...brief, fix: check.reason });  // specific reason
}

return escalate(draft);   // three strikes and a human looks at it

Two details do the work. The checker is told what the brief promised, so it measures the draft against the same constraints rather than its own taste. And a failure comes back with a specific reason, not a score, because "too vague in paragraph two, no source for the 40% claim" is fixable and "6/10" is not.

I learned to build this the unglamorous way. An early version of the pipeline had no verifier, and it once produced a paragraph of plausible, completely invented figures. It read beautifully. It was wrong. A tool that quietly makes things up is worse than no tool. The verifier, and the rule that an agent must say "I could not confirm this" rather than guess, is what turned the system from a demo into something I actually rely on.

Tools live behind one clean interface

The agents reach the outside world, search, files, my own data, through a single tool layer rather than each agent holding its own keys and connections. In my setup that layer is MCP, the Model Context Protocol. One place defines what the agents are allowed to touch and how, which means guardrails live in one spot instead of scattered across every agent. When I want to add a capability or lock one down, I do it once.

That is the same reason a well-run kitchen has one pass. Everything goes through it, so nothing goes out unchecked.

Where the human stays

The whole system is built around one honest seam. The crew handles research, drafting, and checking. I stand at the points where taste lives: which topics, which angle, the final cut. The stage-by-stage version of that pipeline, including which stages I keep by hand and why, is in the content engine write-up.

I could push the automation further into the editorial decisions. I have chosen not to yet, because the judgement about what is actually good is the part I most want to keep my hands on. Building in the open means telling you where the line is, rather than pretending the loop is fully closed.

Put the two shapes side by side and the difference is not intelligence. It is where the work can be inspected.

The bottom line: a multi-agent system is not about a smarter model. It is a thin planner, narrow specialists, a sceptical checker with a retry cap, and one tool layer where the guardrails live. Get that shape right and you can leave it running. Get it wrong and you get a confident mess, faster.

Common questions

What is a multi-agent system?

A multi-agent system is one where a lead agent plans a job, hands slices of it to smaller agents that each do one thing well, and stitches the results back together. A general contractor and a crew, not one person doing every trade. The value is division of labour plus a defined place to check the work.

Why use multiple agents instead of one long prompt?

A single agent asked to research, decide, write, and check itself in one pass runs out of attention partway through and starts treating its own earlier guesses as facts. Splitting the job gives each agent a brief it can actually satisfy, and it gives you a separate agent whose only job is to be sceptical about the result.

What does the orchestrator agent actually do?

It holds the plan, decides what happens next, and routes each slice of work to the subagent built for it. Deliberately no production work of its own: no drafting, no source-crunching. Keeping it thin is what stops it losing the plan halfway through a long unattended run.

How do you stop AI agents from hallucinating in an automated pipeline?

With a separate check agent and a bounded retry loop. Work never goes straight from draft to done. A verifier tests the claims, failed work goes back with the specific reason, and a hard retry cap stops it spinning. Agents are also required to say "I could not confirm this" rather than fill a gap with a guess.

What is MCP and why does it matter here?

MCP, the Model Context Protocol, is the single tool layer the agents reach the outside world through: search, files, private data. One place defines what they may touch and how, instead of every agent holding its own keys. Guardrails live in one spot, so adding or revoking a capability is one change.

Which parts of a content pipeline should stay human?

The judgement calls: which topics are worth doing, what the angle is, and the final cut. The machine runs the straightaway of research, drafting, and checking. Automating the taste is possible. It is also the part worth keeping your hands on, because it is what makes the output yours.