Multi-Agent Pipelines

Module 5: Multi-Agent Pipelines

A single agent handles a single task well. A pipeline handles a process well.

The difference is coordination. In a pipeline, agents hand work to each other. The output of one becomes the input of the next. Each agent specialises; the pipeline generalises. You get complex results without building complex agents.

The Content Pipeline

The clearest example in the system is content-pipeline. It coordinates the full journey from idea to published piece:

1. Topic selection — Check the topic backlog, verify it hasn’t been covered recently
2. Research — Route to newsletter-researcher for deep investigation, sources, quotes
3. Outline — Build structure from the research brief
4. Draft — Route to newsletter-writer with the outline and research as inputs
5. Review — Route the draft through draft-reviewer for quality and voice checks
6. Publish — Route through publish-guard for final checks before distribution

No single agent does all of this. newsletter-writer doesn’t know how to do research. draft-reviewer doesn’t know how to publish. Each does its piece, well, and passes work forward.

The pipeline agent’s job is coordination, not execution. It knows the sequence, enforces the order, and passes the right context to the right agent at the right stage.

Quality Gates

The moment between research and drafting is a quality gate. The moment between drafting and review is another. The moment between review and publishing is the most important one.

A quality gate asks: is the output of this stage good enough to pass to the next? If yes, continue. If no, either loop within the current stage or surface the problem to the user.

publish-guard exists specifically as a gate. Before anything goes public, it runs a checklist: factual claims verified, voice consistent, no internal infrastructure details exposed, formatting correct. Only when all gates pass does the content move to distribution.

Gates are where pipelines earn their value. Without them, you have an automated assembly line where defects propagate. With them, you have a production system that catches problems before they’re visible.

Subagent-Driven Development

There’s a skill called subagent-driven-development in the system. It applies the pipeline pattern to code work.

The idea: complex coding tasks get broken into discrete stages, each handled by a focused agent. One agent maps the codebase. Another identifies what needs changing. Another implements the change. Another reviews the diff. Another runs the tests. Another writes the commit.

No single agent needs to hold the entire problem in mind. Each sees its slice, handles its slice, and produces clear output for the next agent.

This is why Claude Code’s ability to spawn subagents matters. The parent agent doesn’t do the work — it directs agents that do the work. The parent’s job is judgment and coordination. The subagents’ job is execution.

Context Handoff

The hardest part of multi-agent pipelines is context handoff. What does the next agent need to know that the previous agent produced?

The discipline: be explicit. Don’t assume the next agent will infer what happened in the previous stage. Pass the output clearly, with structure:

• What was the input to this stage?
• What decisions were made?
• What is the output?
• What constraints carry forward?

When newsletter-writer receives its task from content-pipeline, it gets the research brief, the outline, the voice profile reference, and explicit constraints from earlier stages. Not a summary. The actual material, structured.

Agents that receive vague handoffs produce vague output. The garbage-in problem applies across agent boundaries just as much as within a single agent.

When to Use a Pipeline

Not every task needs a pipeline. A single, focused agent that does one thing well is better than a pipeline with unnecessary stages.

Pipelines make sense when:

• The task has genuinely distinct phases that require different capabilities
• Quality gates between stages add real value
• The complexity of any single phase justifies its own agent
• The whole process is run frequently enough to justify the investment

If you’re running a process once, orchestrate it manually. If you’re running it weekly, build the pipeline. Automation should earn its complexity.

The Compounding Effect

The thing pipelines do that single agents cannot: they compound.

Every improvement to draft-reviewer improves everything that runs through it — sbc-writer output, newsletter-writer output, any content that touches the pipeline. Every improvement to writing-quality propagates to draft-reviewer and from there to every writer agent.

This is the architectural dividend of composable systems. You improve a piece, and the improvement flows downstream through everything that depends on it. The work compounds without duplication.

---

Next: how to keep a growing ecosystem of agents coherent over time.