Multi-Agent Patterns
A multi-agent setup uses more than one Claude instance working on the same goal — one coordinating, others executing. This makes it possible to parallelize work, isolate context per task, and review output with a fresh set of eyes before accepting it.
Why multiple agents
Section titled “Why multiple agents”A single Claude session accumulates context. After a long session, Claude is carrying the entire conversation history — earlier decisions, wrong turns, corrections — which can cause it to conflate tasks or drift from the original goal.
A fresh agent has none of that baggage. It reads only what you give it, which makes its output more predictable and easier to review.
The coordinator–executor pattern
Section titled “The coordinator–executor pattern”The most common pattern: one agent coordinates (breaks down the task, dispatches work, reviews results) while separate agents execute individual tasks.
The coordinator never writes code — it only reasons about what needs to happen and whether it happened correctly. Executors never see the full plan — they get exactly the context needed for their task.
When to use it
Section titled “When to use it”Use multi-agent when:
- A task has multiple independent steps that don’t share state
- You want a second opinion on output before accepting it (spec review, quality review)
- A session has grown long enough that context pollution is a real risk
- You want to run different models for different roles (cheap model for mechanical work, capable model for review)
Don’t use it when:
- Tasks are tightly sequential and each step depends on the previous one’s output
- The overhead of coordinating agents outweighs the benefit
- A single well-scoped prompt would do the job
Passing context between agents
Section titled “Passing context between agents”Agents don’t share memory. The coordinator must explicitly pass everything an executor needs: the task description, relevant file contents, constraints, and expected output format.
The more precisely the coordinator briefs the executor, the less back-and-forth is needed.
Review agents
Section titled “Review agents”A review agent is a special case: its only job is to read another agent’s output and check it against a spec. It has no implementation context — just the requirement and the result. This is what makes it useful. A reviewer that doesn’t know what the implementer was thinking gives more honest feedback.
See Superpowers Skills for how the subagent-driven-development skill implements this pattern.