What You Need to Know
Multi-agent orchestration is several Claude agents working together on one complex task. A coordinator agent receives the task and splits it into parts. Subagents each handle one specialised task, such as web search, document analysis, synthesis or report generation. In the hub-and-spoke pattern, the coordinator is the hub (the centre) and the subagents are the spokes. When the coordinator splits a task into subtopics, the result is its decomposition.
This lesson uses one made-up example throughout: a skip hire firm that wants a report on what drives its costs. Its system has a coordinator and the four subagents above.
Hub-and-Spoke Architecture
The coordinator receives the initial task and decomposes it. It decides which subagents to invoke and passes context to them. It aggregates their results, handles errors, and routes information between them. Each subagent receives instructions from the coordinator and returns results to it.
All communication routes through the coordinator. Subagents never communicate directly with each other, whether for efficiency, convenience or any other reason. The skip hire firm's web search subagent returns its findings to the coordinator, never directly to the synthesis subagent.
One hub gives three things. A direct message between subagents would bypass them.
- Observability: you can log and monitor every message in one place.
- Consistent error handling: the coordinator applies uniform error recovery policies.
- Controlled information flow: the coordinator decides what context each subagent receives.
Key Concept
The basic architectural constraint of hub-and-spoke orchestration is this: all communication between subagents routes through the coordinator.
The Critical Isolation Principle
Isolation is the most misunderstood idea in multi-agent systems. Subagents do not automatically inherit the coordinator's conversation history. A new subagent starts with only what the coordinator explicitly includes in the subagent's prompt. It has no access to:
- The coordinator's system prompt (unless explicitly included)
- Previous messages in the coordinator's conversation
- Results from other subagents (unless the coordinator passes them)
- Any "shared memory" or global state
Subagents also do not share memory between invocations. If the coordinator invokes the web search subagent twice, the second invocation knows nothing about the first.
So the coordinator explicitly puts every piece of information that a subagent needs in that subagent's prompt. There is no shared store where a subagent can find information. The skip hire firm's synthesis subagent needs the web search results, so the coordinator puts them in the synthesis subagent's prompt.
Exam Trap
When a multi-agent system produces incomplete or incorrect output, trace the failure to its origin. Before you blame the subagent that produced the output, check whether the coordinator gave that subagent the right input.
Coordinator Responsibilities
The coordinator has four responsibilities.
1. Dynamic subagent selection. The coordinator analyses what a query requires and selects only the subagents it needs. A simple factual question might need only web search, not the full chain of research, analysis and synthesis. A coordinator that routes every query through every subagent wastes time and resources. If the owner asks for the landfill site's opening hours, the coordinator invokes the web search subagent alone.
2. Research scope partitioning. The coordinator partitions the research scope to minimise duplicate work. It assigns each subagent distinct subtopics or source types, such as academic papers for one and news articles for another. No two subagents search the same sources. For the cost report, one subagent searches fuel price news while another analyses the firm's invoices.
3. Iterative refinement loops. The coordinator evaluates the synthesis output for gaps. If it is incomplete, the coordinator re-delegates to the search and analysis subagents with targeted queries. It re-invokes synthesis and repeats the cycle until coverage is sufficient. If the first draft has no tyre costs, the coordinator sends a targeted search for them and runs synthesis again.
4. Centralised communication routing. All subagent communication routes through the coordinator for observability, consistent error handling and controlled information flow.
The Narrow Decomposition Failure
Overly narrow task decomposition by the coordinator leads to incomplete coverage of broad research topics. Each subagent researches only what it is assigned. A subtopic nobody is assigned never gets researched.
The skip hire firm's coordinator splits "what drives our costs?" into fuel and lorry maintenance. The web search subagent searches thoroughly for what the coordinator assigned to it. The synthesis subagent synthesises everything it receives. The report says nothing about landfill gate fees, staff wages or insurance. The coordinator asked no subagent about these costs.
When subagents execute their assigned tasks correctly but coverage is missing, the root cause is what the coordinator assigned them. The fault is in the coordinator's decomposition, not in any downstream subagent. So when a report misses entire categories, check the decomposition before you blame the subagents. If output is incomplete in scope (not depth), the decomposition is almost always the root cause.
The fix is a decomposition that covers the full breadth of the topic. Better search queries would not fix the problem, and nor would a more capable synthesis subagent. More subagents would receive equally narrow assignments.
In the exam
The exam tests one orchestration pattern: hub-and-spoke, with a coordinator at the centre. It tests all four coordinator responsibilities. Direct communication between subagents is the wrong answer, even when an option offers it as a way to make the system more efficient. The exam often tests the confusion about isolation.
The exam guide's sample set includes a question (Question 7) where a coordinator decomposes "impact of AI on creative industries" into only visual arts subtopics. This decomposition misses music, writing and film entirely. The root cause is the coordinator's task decomposition. The exam expects you to trace the failure to its origin, not blame the subagents.
Current state
Checked 6 October 2026: in Claude Code a subagent can itself spawn subagents, up to three layers below the main conversation. So the strict "never" rule is a simplification for the exam, not a hard product limit.
Exam Traps
Blaming downstream subagents for coverage gaps when the coordinator's task decomposition was too narrow
Subagents research what they are assigned. If the coordinator only assigns solar and wind as subtopics for renewable energy, no subagent can cover geothermal or tidal. Trace failures to their origin: the coordinator's decomposition.
Assuming subagents share memory or inherit the coordinator's conversation history
A subagent does not inherit the coordinator's conversation history, its system prompt or other subagents' results. It starts with what the coordinator puts in its prompt, so pass everything it needs there explicitly.
Proposing direct inter-subagent communication as an efficiency improvement
Direct messages bypass the coordinator's observability, consistent error handling and controlled information flow, so the exam guide routes all subagent communication through the coordinator. Current SDK docs (October 2026) also let a subagent message other named agents with SendMessage.
Routing every query through the full subagent pipeline and caching the unused subagents' results to cut cost
Invoking subagents that a query does not need adds latency and API call overhead, cached or not. Have the coordinator analyse each query and invoke only the subagents it needs, such as web search alone for a simple factual lookup.
Practice Scenario
A multi-agent research system produces a report on 'renewable energy technologies' that only covers solar and wind, missing geothermal, tidal, biomass, and nuclear fusion. Each subagent produced thorough coverage of its assigned topic. Where is the root cause?
Build Exercise
Build a Hub-and-Spoke Research Coordinator
What you'll learn
- How hub-and-spoke architecture centralises all communication through a coordinator
- Why subagent isolation means every piece of context must be explicitly passed
- How to implement broad task decomposition that avoids a decomposition so narrow that whole subtopics are missed
- How iterative refinement loops detect and fill coverage gaps
- Why tracing failures to the coordinator decomposition is the correct diagnostic approach
- Create a coordinator agent that accepts a broad research topic as input
Why: The coordinator is the central hub in hub-and-spoke architecture. The exam tests whether you understand that the coordinator owns task decomposition, subagent selection, and result aggregation — not the subagents.
You should see: A coordinator function that accepts a topic string and returns a structured research report. It should have a system prompt defining its role as the orchestrating hub.
- Implement task decomposition logic that breaks the topic into at least 5 distinct subtopics covering the full breadth of the subject
Why: Narrow decomposition is a specific exam failure pattern. The coordinator that only assigns solar and wind for renewable energy misses entire categories. The exam expects you to recognise that incomplete output traces back to the coordinator decomposition.
You should see: A decomposition function that produces 5 or more subtopics for any broad topic. For renewable energy, it should cover solar, wind, geothermal, tidal, biomass, and fusion at minimum.
- Spawn two subagents (web search and document analysis) with explicit context passing — include all relevant information in each subagent prompt
Why: Subagent isolation means no shared memory and no inherited context. The exam heavily tests this: if a subagent produces poor results, check whether the coordinator gave it sufficient context, not whether the subagent itself is flawed.
You should see: Two subagent invocations where each receives the full assigned subtopic, the research goal, and any relevant context from prior agents — all explicitly included in the prompt.
- Aggregate results from both subagents and evaluate coverage completeness
Why: The coordinator must evaluate whether the combined results cover the full breadth of the original topic. This is where iterative refinement starts — gaps detected here trigger re-delegation.
You should see: An aggregation function that combines results from both subagents and produces a coverage assessment listing which subtopics are well-covered, partially covered, or missing.
- Implement an iterative refinement loop: if the coordinator identifies coverage gaps, re-delegate to subagents with targeted queries and re-invoke until coverage is sufficient
Why: Iterative refinement is a core coordinator responsibility the exam tests. A single round of delegation is not enough — the coordinator must evaluate output and re-delegate for gaps. This distinguishes a coordinator from a simple dispatcher.
You should see: A loop that checks coverage, identifies gaps, sends targeted follow-up queries to subagents for the missing subtopics, and re-evaluates until a coverage threshold is met or a maximum iteration count is reached.
- Test with the topic renewable energy technologies and verify that the final output covers solar, wind, geothermal, tidal, biomass, and fusion
Why: This specific test case matches the exam pattern where a too-narrow decomposition misses subtopics. If your output only covers solar and wind, the root cause is the coordinator decomposition — the exact diagnostic the exam expects you to make.
You should see: A final research report with substantive sections on all six energy types: solar, wind, geothermal, tidal, biomass, and fusion. The coverage evaluation should show 100% completeness.