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 (combining the findings into one account) 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 bank whose strategy team has a research system. The team wants a report on why customers close their accounts. The 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 bank'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 bank's synthesis subagent needs the web search results, so the coordinator puts them in the synthesis subagent's prompt.
Current Claude Code and the Agent SDK have one exception to this rule, the fork. The last note under In the exam explains it.
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 an analyst asks only for the central bank's current interest rate, 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 account closure report, one subagent searches news about competing banks while another analyses the bank's customer survey.
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 nothing on the mobile app, the coordinator sends a targeted search for app reviews 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 bank's coordinator splits "why do customers close their accounts?" into fees and interest rates. 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 branch closures, the mobile app or customer service. The coordinator asked no subagent about these causes.
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 hub-and-spoke rule, that subagents never communicate directly with each other, is a simplification for the exam, not a hard product limit.
Current state
Checked 29 October 2026: Claude Code and the Agent SDK now have one exception to isolation, the fork. A fork is a subagent that copies the coordinator's whole conversation when it starts. It has the coordinator's system prompt, tools, model and message history, so it also sees any subagent results the coordinator already holds. Forks have been on by default since Claude Code v2.1.302, and this includes the Agent SDK. So Claude can choose to start a fork. Because the system prompt and tools match, its first request reuses the coordinator's prompt cache. For a task that needs the same context, a fork costs less than a fresh subagent, which builds its own cache. Its own tool calls still stay inside it, and only its final result returns to the coordinator. Every other subagent, including a custom one such as each of the bank's four, still starts fresh with only its prompt. That is the case exam guide v1.0 describes and the exam tests, so answer with the isolation rule. Do not confuse a fork with fork_session from 1.3, which branches a resumed session. Also do not confuse it with a skill's context: fork from 3.2. That skill runs in a subagent that starts without the conversation history.
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.
Sources
- Claude Agent SDK Overview — Anthropic
- Claude Code: Create custom subagents — Anthropic
- Agent SDK: Subagents in the SDK — Anthropic
- CCAR-F Exam Guide v1.0: Scenario 3, Multi-Agent Research System — Anthropic
- CCAR-F Exam Guide v1.0: Task Statement 1.2 — Anthropic