What You Need to Know
A multi-agent system splits one task across several agents. In the production-proven orchestrator-worker shape, a lead agent (the coordinator) analyses the goal, develops a strategy and decomposes the goal into subtasks. It spawns subagents that explore in parallel. Each subagent has its own context window. The coordinator synthesises the results that the subagents return. Two skills apply. One skill is knowing when a multi-agent system is justified. The other skill is orchestrating the agents so that the classic failure modes cannot occur.
This lesson uses one made-up example throughout: a software company that compares five payment providers on fees and country coverage, to choose one for its product. Each provider can be researched alone.
When Multi-Agent Is Justified and What It Costs
Multi-agent architectures excel at breadth-first work, which covers many independent directions and splits easily into parallel parts:
- research across independent directions
- analysis of many independent units
- tasks exceeding a single context window
- work needing distinct specialisms with different tools and permissions
Subagents work alone. So the split helps when no direction needs the result of another direction, as with the five payment providers. A multi-agent system has difficulty where agents must share context tightly or depend on each other's intermediate results. Anthropic's engineering assessment is that most coding tasks have fewer truly parallelisable parts than research does.
According to Anthropic's production data, agent interactions use roughly 4× the tokens of chat, and multi-agent systems use roughly 15×. Each subagent spends its own tokens. The value of the task has to justify the cost of that increased performance. The software company pays its provider a fee on every sale, so a better choice can justify that cost. A proposal with no value case (a statement of why the value justifies the cost) is incomplete (see the business value pillars in objective 1.6).
Key Concept
The exam tests whether you avoid a multi-agent system when one agent is enough. Consider a task that one agent handles well. The task has no parallel breadth and no need for separate tools and permissions. A multi-agent system for that task is a wrong answer, however competent the orchestration is. Justify the architecture first.
The Orchestrator-Worker Architecture
Subagents start with a fresh context. A fork is a subagent that inherits the coordinator's conversation. A subagent that is not a fork does not inherit it or see the findings of other subagents. The coordinator must explicitly pass every piece of context that the subagent needs in the subagent's brief. The subagent for the third provider cannot know that the company needs only card payments and bank transfers unless the coordinator tells it. Any design that assumes that agents share knowledge without being told cannot work. Current Claude Code docs (October 2026) add two exceptions. One exception is that a fork inherits the coordinator's conversation. The other exception is that a subagent with the SendMessage tool can message other named agents.
Delegation quality determines system quality. The brief is all a subagent knows. Anthropic's research-system team found that without detailed task descriptions, subagents duplicate work, leave gaps, or fail to find necessary information. An effective subagent brief contains:
- an explicit objective
- an expected output format
- tool and source guidance
- clear task boundaries
The brief for the third provider asks for fees and a source for each fee. It excludes the other four providers. "Research this topic" alone is a defect.
Failure Modes and Their Root Causes
The failures form a short list. Each failure has a signature, a typical symptom that identifies it:
- Narrow decomposition. The coordinator splits a broad goal into subtopics covering only part of the goal. Output has systematic gaps, such as no subagent checking country coverage. The root cause is the coordinator's decomposition, not subagent capability, and not agent count.
- Duplicated work. Subagent scopes overlap because the coordinator never partitioned the boundaries. Two subagents both collect the card fees of the same provider. The signature is near-identical sections in the synthesis.
- Effort mismatch. The coordinator spawns ten subagents for a simple fact-check, such as the card fee of one provider. Match the number of agents and the tool budget to the complexity of the task. Simple fact-finding needs one agent and a few tool calls. Only genuinely complex research justifies many subagents with divided responsibilities.
- Lost attribution. When agents pass findings between them as free prose, the findings lose their sources. The report names the cheapest provider, and nobody can trace the fee. Structured claim and source data must pass across every agent boundary, or the synthesis produces confident, uncitable claims.
Duplication plus gaps in one output is the signature of unpartitioned decomposition. Overlapping scopes cause the duplicates, and parts of the goal that no subagent covers cause the gaps. Both start in the coordinator's briefs, so the fix belongs in the coordinator's briefing strategy. More agents with the same overlapping briefs produce more overlap. The software company gives each payment method and provider to one subagent.
Orchestration Strategy
- Parallel where independent, sequential where dependent. Spawning subagents in parallel reduces wall-clock time (the real time that the work takes) for independent subtasks. Dependencies force the subtasks to run in sequence. The five provider checks run at once, and the comparison waits for all five.
- Durable state and checkpointing are for long-running systems. They let a run resume from a checkpoint (a saved point in the run) after a mid-run failure, instead of restarting. At 15× token cost, restarts are expensive by definition. If the run fails on the fifth provider, the first four results are kept.
- Observability of agent decisions: you can see which agent did what, which tools it used, and what it cost. The software company can see which subagent researched which provider, and what that cost. (Domains 3 and 4 cover monitoring depth. This objective covers the duty to design for observability.)
- Through-the-coordinator remains the default communication topology (the pattern of which agents send messages to which). This topology concentrates control and observability in one place. Peer-to-peer agent protocols exist, and Domain 3 examines how to choose between them.
In the exam
At the Professional level the exam tests both skills. It tests the second skill largely through diagnosis questions. A diagnosis question describes a broken multi-agent system and gives four candidate root causes from the failure modes above. One of them is correct. The two facts under The Orchestrator-Worker Architecture are the most important part. Subagents start with a fresh context, and delegation quality determines system quality. "Add more subagents" and "use a larger model" are the deliberate wrong answers.
Exam Traps
Diagnosing overlapping or missing report sections as a subagent capability problem
Duplication plus gaps is the signature of unpartitioned coordinator decomposition. A stronger model given the same overlapping briefs produces the same overlap. Trace the failure to its origin.
Assuming subagents can see the coordinator conversation or each other's findings
A subagent starts with a fresh context window and does not see other subagents' findings, so the coordinator briefs each one. Current Claude Code docs (October 2026) add exceptions: a fork inherits the parent conversation, and a subagent with SendMessage can message named agents.
Proposing multi-agent for a task that fits comfortably in one context window
The roughly 15x token multiplier, added latency and orchestration complexity give little benefit when one agent can do the job with one set of tools and permissions. A split is worth its cost when the work needs separate tools and separate permissions.
Fixing systematic coverage gaps by adding more subagents
More agents with the same unpartitioned briefs produce more duplication, not more coverage. The fix is mutually exclusive, explicitly bounded briefs from the coordinator.
Practice Scenario
A due-diligence system uses a coordinator plus six parallel research subagents. Final reports keep arriving with three sections nearly identical to each other and two risk areas missing entirely. What is the root cause?
Build Exercise
Design a Bounded Orchestrator
What you'll learn
- When a multi-agent architecture is justified and when it is not
- How to write a coordinator decomposition strategy with partitioned scopes
- What a complete subagent brief contains
- How to preserve attribution across agent boundaries
- How to write the value case that justifies the token multiplier
- Pick a genuinely parallelisable research task — competitor analysis across five companies works well — and state why it parallelises
Why: The justification step is the one most designs skip. Breadth-first, independent directions is the pattern that justifies multi-agent cost.
You should see: One sentence naming the independent directions and confirming no direction depends on another finding.
- Write the coordinator brief: the decomposition strategy, the number of subagents, and an effort budget per subagent
Why: Effort scaling is a designed property. Anthropic embeds explicit guidelines — simple fact-finding gets one agent and a handful of tool calls; more complex tasks get more.
You should see: A short paragraph: how the goal splits, how many subagents, and a tool-call budget per subagent with a sentence of justification.
- Write one subagent brief in full: objective, output schema with source-attribution fields, tool guidance, and explicit scope boundaries
Why: Delegation quality determines system quality. The complete brief is the artefact that prevents duplication, gaps, and lost attribution simultaneously.
You should see: A brief another person could execute without asking questions: one objective, a JSON output schema including a sources field, named tools, and a boundary list.
- Define the synthesis step: how the coordinator merges structured findings, and what happens on conflict between subagent claims
Why: Synthesis is where lost attribution and unresolved conflicts appear. Designing the merge rules in advance keeps the final output citable and consistent.
You should see: Merge rules in three or four lines: how findings combine, how conflicts resolve, and how sources carry into the final report.
- Write the value case: estimate the token multiplier against a single-agent baseline and state why the task value justifies it
Why: The professional argument for multi-agent is about cost and value, not about how impressive the design looks. Anthropic reports multi-agent at roughly fifteen times chat tokens — the value must justify that cost.
You should see: Three lines: single-agent cost estimate, multi-agent estimate, and the value statement (time saved, coverage gained) that justifies the difference.
Sources
- How we built our multi-agent research system — Anthropic
- Subagents in the SDK — Anthropic
- Building Effective AI Agents — Anthropic