Most teams discover multi-agent development by accident. They give Claude Code a task that is too large for one session, the context fills up, and something goes wrong. Then they find out about Dynamic Workflows or Agent Teams, throw multiple agents at the problem, and wonder why the output is noisier than a single-agent run.
The failure mode is not using agents at all — it is using agents without an architecture. Here are the four patterns that work, when to reach for each one, and how to wire them up in Claude Code.
Why Multi-Agent Now#
The shift from single-agent to multi-agent software development is not a product launch; it is a capability threshold. Claude Code’s Dynamic Workflows (shipped with Opus 4.8 in May 2026) generates its own orchestration scripts on the fly and deploys subagents into isolated worktrees. One team used it to rewrite 750,000 lines across a legacy codebase in six days — something that would have taken months or failed on context limits with a single agent.
Parallel subagent execution is not primarily about speed, though speed is real. It is about scope isolation. An agent that is responsible for one file, one service, or one test suite cannot corrupt the work of the agent next to it. Multi-agent systems trade coordination overhead for containment guarantees.
The same logic applies at every scale: five agents reviewing a 50-file PR in parallel, each owning a domain (security, performance, correctness, style, tests), produce better signal than one agent skimming all fifty with a decaying context window.
Pattern 1: Fan-Out and Synthesize#
Use when: You have a large, decomposable body of work where each piece can be evaluated independently.
Structure: A coordinator agent breaks the work into N units, spawns one agent per unit, waits for all of them to complete, and synthesizes the results.
Classic examples: security audit across 40 services, translation of a codebase from one framework to another, parallel test generation for each module.
The synthesis step is the barrier. It deliberately waits for all fan-out agents before assembling the result. This is the right pattern when the synthesizer genuinely needs the full picture — for deduplication, for cross-cutting analysis, or for generating a coherent summary that references multiple agent outputs.
In Claude Code Dynamic Workflows this maps directly to the parallel() call followed by a synthesis agent. The synthesis agent receives all prior results and has one job: merge, dedup, and produce a unified output.
Anti-pattern: Using fan-out-synthesize when the synthesis step does not actually need all prior results. If you can emit useful output as soon as each subagent finishes, use a pipeline instead.
Pattern 2: Pipeline Chain#
Use when: Work flows through distinct, ordered stages where each stage’s output feeds the next.
Structure: Items move through a sequence of agent types (researcher → planner → implementer → reviewer), with no barrier between stages. Item A can be in the reviewer stage while item B is still being planned.
This is the workhorse pattern for multi-file feature development. A typical pipeline for a new API endpoint: spec agent writes the contract → implementation agent writes the handler → test agent generates test cases → review agent checks correctness and style. Each of those agents gets a narrow brief and returns structured output.
The key property is that stage N does not wait for all items to complete stage N-1. The wall-clock time equals the slowest single-item chain, not the sum of each stage’s slowest run. On a 20-endpoint migration, this is often a 4x speedup over sequential processing.
In Claude Code, pipeline chains map to Dynamic Workflows’ pipeline() primitive. Each stage callback receives the prior result and the original item; structured schemas on each stage enforce clean handoffs.
Anti-pattern: Adding barriers between pipeline stages because it feels cleaner. Coordination overhead grows linearly with the number of barriers.
Pattern 3: Classify and Route#
Use when: Incoming tasks vary enough in type that a single agent cannot handle all of them well.
Structure: A classifier agent inspects each task and routes it to a specialist. The classifier does not do the work — it decides who should.
In a support-engineering workflow, the classifier routes to one of three specialists: a bug-investigation agent (accesses logs, traces, test history), a performance-investigation agent (profiles, benchmarks, flame graphs), and a dependency-update agent (audits package lock files, checks CVEs). Each specialist is given exactly the context and tools it needs for its class of task and nothing else.
The payoff is dual: specialist agents get better prompts and better results, and you can optimize each specialist independently without touching the classifier. You can also version-control the routing logic explicitly — the classifier’s rules are auditable code, not opaque model judgment calls.
In Claude Code Agent Teams, this pattern is the mailbox architecture: the coordinator broadcasts task classifications to named specialists. In Dynamic Workflows, it is a classify → conditional branch structure in the orchestration script.
Anti-pattern: Building a classifier that is doing too much work. If the classifier is writing substantial code or analysis, you have collapsed two roles into one agent and lost the isolation benefits.
Pattern 4: Review in Loop#
Use when: Output quality matters more than speed, and you need adversarial validation before accepting results.
Structure: After a primary agent produces output, one or more independent review agents attempt to refute or improve it. Results that survive the review loop are promoted; results that fail are retried or flagged.
This pattern is the safest path for AI-generated code going directly into production. A primary implementer writes the code. Three independent review agents each attack from a different angle: one checks for correctness and edge cases, one checks for security vulnerabilities, one checks for performance regressions. A result survives only if two of three reviewers sign off.
The independent review requirement is essential. If you use the same model instance for both writing and reviewing, you get the same blind spots twice. Spawn separate agents with separate contexts; give reviewers an explicit brief to find failures, not to confirm the implementer’s work.
Claude Code’s /code-review with an effort level, Claude Code Review GA’s multi-agent PR review, and Dynamic Workflows’ adversarial verify pattern all implement variations of this loop.
Anti-pattern: Treating review-in-loop as a way to get perfect code. It reduces the rate of defects that escape; it does not eliminate them. The loop is a confidence multiplier, not a proof.
Which Claude Code Feature Maps to Each Pattern#
| Pattern | Claude Code feature |
|---|---|
| Fan-out and synthesize | Dynamic Workflows parallel() |
| Pipeline chain | Dynamic Workflows pipeline() |
| Classify and route | Agent Teams mailbox / Dynamic Workflows conditional branch |
| Review in loop | /code-review, Code Review GA, Dynamic Workflows adversarial verify |
The /goal command and agent view (v2.1.139) are monitoring and outcome-checking layers that sit above all four patterns — they track whether a multi-agent run is converging on the stated goal and surface blocked agents before context window exhaustion.
When Not to Use Multiple Agents#
Multi-agent setups have real costs: orchestration scripts, synthesis latency, higher token spend, and harder debugging when something goes wrong. A single-agent run with a clear CLAUDE.md and a well-specified task often produces better output than a poorly-scoped multi-agent run that amplifies confusion.
Use multiple agents when:
- The task genuinely decomposes into independent units (no shared state across agents during execution)
- Context limits would compromise quality on a single-agent run
- You need adversarial review, not just a second pass by the same agent
- Parallelism materially reduces wall-clock time on a deadline-sensitive task
Do not use multiple agents when a single, well-prompted agent can handle the scope, when task decomposition requires constant cross-agent communication, or when you are still learning what a feature should do. Discovery and specification are single-agent work. Execution and review benefit from parallelism.
The Architecture Shift#
The first wave of AI coding tools automated the keystrokes. The multi-agent wave automates the team structure. Fan-out-synthesize is a parallel sprint. Pipeline chain is a handoff. Classify and route is a triage process. Review in loop is a peer review cycle.
The patterns existed before AI. What changed is that you can now instantiate them in code and run them in minutes. The developers who understand the underlying coordination logic — not just the API calls — are the ones who get 6x productivity gains. The ones who scatter agents without architecture get expensive noise.
Sources: Dynamic Workflows Guide · InfoQ: Dynamic Workflows · Claude Code 750K Lines Case Study · Dynamic Workflows vs Agent Teams · Deterministic Multi-Agent Orchestration · Anthropic Opus 4.8 Release