Building a Production Multi-Agent Pipeline

From Individual Agents to a System

You have now built every component: agent definitions with scoped tools and permissions, MCP server pairings, lifecycle hooks, persistent memory, parallel fan-out, nested hierarchies, and the Agent SDK. The final step is combining them into a pipeline that works reliably in production.

A production pipeline is more than a collection of agents. It is a designed system with clear data flow, explicit error handling, monitoring, and a structure that degrades gracefully when individual components fail.

Worked Example: A Content-Review Pipeline

Consider a content pipeline that takes a draft article and produces a polished, fact-checked, formatted version. The pipeline has four stages, each implemented as a specialized subagent:

Stage 1: Researcher — reads the draft, identifies all factual claims, and produces a list of claims that need verification. Tool access: Read only. Memory: project scope, to remember what sources were already checked for this topic.

Stage 2: Fact-checker — receives the claims list and verifies each one against authoritative sources. Tool access: WebSearch, WebFetch. MCP servers: web-search. Returns a structured report: verified, disputed, or unverifiable, with sources.

Stage 3: Editor — receives the original draft plus the fact-check report. Revises claims that were disputed, flags unverifiable claims for human review, and improves prose clarity. Tool access: Read, Write, Edit. Worktree isolation: yes, to keep edits separate from the original.

Stage 4: Summarizer — produces a brief executive summary of what changed, what was verified, and what requires human attention. Tool access: Read only.

Stages 1 and 2 can run in parallel (the researcher does not depend on the fact-checker). Stages 3 and 4 must run sequentially after 1 and 2 complete. The orchestrator manages this dependency.

Error Handling in Multi-Agent Pipelines

Agents fail. They hit context limits, encounter unexpected file structures, or return incomplete results. A production pipeline needs to handle these failures without requiring human intervention for every one.

Three strategies for robust error handling:

• Retry with context. If an agent returns a clearly incomplete result (empty output, error message), the orchestrator spawns it again with additional context about what went wrong and what to try differently.
• Graceful degradation. Design stages so each one can operate with partial input from the previous stage. The editor can still run if the fact-checker returns results for only 80% of the claims.
• Checkpoint hooks. Use SubagentStop hooks with validation scripts to catch failures immediately when an agent finishes, rather than discovering them when the next stage tries to use the bad output.

Dynamic Workflows: The Next Frontier

The pipelines described so far use Claude's own judgment to orchestrate — the main session decides which agents to spawn, in what order, and how to synthesize results. This works well for many workflows, but it means orchestration logic lives inside a context window that eventually fills up.

Dynamic Workflows (launched as a research preview in May 2026) represent a shift in how orchestration works. Instead of Claude deciding the orchestration plan, you write a script that decides — a script that calls Claude in a loop.

Boris Cherny, Head of Claude Code at Anthropic, described the shift this way: "I don't prompt Claude anymore. I write loops that prompt Claude."

The practical difference: in a Dynamic Workflow, your code defines the structure. For each item in a list, spawn an agent. When all agents finish, run a validation step. If validation fails, retry up to three times. This logic is deterministic, inspectable, and not subject to context pressure. Claude's intelligence is applied within each step — analyzing, writing, deciding — but the control flow lives in your code.

To build a Dynamic Workflow today, use the Agent SDK. Write Python or TypeScript that calls query() in loops, processes results, and decides what to do next based on the output. You control the flow; Claude does the work.

What Belongs in Each Layer

A useful mental model for production pipeline design:

• Your code (or CLAUDE.md): High-level goals, constraints, and the definition of done. What the pipeline produces. What counts as failure.
• Orchestrator session: Task decomposition, sequencing decisions, synthesis. Claude's judgment about how to achieve the goal.
• Specialist agents: Domain-specific work within clear boundaries. Each agent is an expert in its domain with the right tools and MCP servers for that domain.
• Worker agents: Specific, bounded tasks. One function, one file, one check. Structured output that the specialist can aggregate.
• Hooks: Observability, quality gates, notifications. The operational layer that makes the pipeline trustworthy.
• Memory: Accumulated knowledge that makes the pipeline smarter over time without requiring manual updates to agent definitions.

Production multi-agent systems are not built in one session. They are designed, tested with simple inputs, extended one capability at a time, and refined based on what the transcript logs reveal about where they actually fail.