Coordinator/Orchestrator Pattern
PatternsDefinition
A multi-agent architecture where a central coordinator manages specialized subagents using hub-and-spoke communication. The coordinator handles task decomposition, routing, and result aggregation. Subagents never communicate directly with each other, keeping the system auditable.
Example Usage
The coordinator decomposes a research query, delegates to web search and document analysis subagents in parallel, then aggregates results.
In Depth
Hub-and-Spoke, Not Mesh
In a coordinator/orchestrator pattern, one Claude instance acts as the central hub: it receives the original task, decomposes it, delegates subtasks to specialised subagents, and aggregates results. Crucially, subagents communicate only with the coordinator — never directly with each other. This hub-and-spoke topology keeps the system auditable and makes failure isolation straightforward.
Compare this with a mesh topology where any agent can call any other agent. Meshes can handle emergent collaboration, but they are hard to debug, hard to constrain, and produce convoluted execution traces that are nearly impossible to audit.
Roles and Responsibilities
Coordinator responsibilities:
- Task decomposition — break the goal into subtasks with clear input/output contracts.
- Routing — decide which subagent handles which subtask (see model routing for tier selection).
- Parallel dispatch — invoke independent subtasks concurrently via the Task Tool.
- Result aggregation — combine subagent outputs into a coherent final answer.
- Error escalation — decide whether a subagent failure is retryable, skippable, or fatal.
Subagent responsibilities:
- Execute exactly the subtask they were given.
- Return structured results the coordinator can parse reliably.
- Never exceed the scope of their assigned tools (least privilege).
Why Subagents Must Not Talk Directly
Direct subagent-to-subagent communication creates hidden state and makes it impossible to audit what happened. If subagent A passes data to subagent B outside the coordinator's view, the coordinator cannot verify correctness, catch errors, or replay the execution. Every data flow must pass through the coordinator's context.
Failure Propagation
The coordinator decides how to handle subagent failures:
| Failure type | Recommended handling |
|---|---|
| Transient tool error | Retry with same subagent (up to N attempts) |
| Subagent returns low-confidence result | Escalate: re-run with a higher-tier model |
| Subtask is optional / non-blocking | Skip and note in aggregated result |
| Subtask is required and failing | Abort and surface to human |
For more on failure handling see the Error Propagation and Coordinator-Subagent Pattern concept pages.
How It's Tested & Common Confusions
How the Orchestrator Pattern Is Tested
Architecture identification: The exam presents multi-agent system descriptions and asks which pattern they implement. The coordinator/orchestrator pattern is characterised by a single central agent that sees all data flows; if subagents communicate directly with each other, the answer is a different pattern (peer-to-peer or mesh).
Common confusion — tool selection: Candidates mix up the coordinator's tool access with the subagents' tool access. The exam will present a scenario where a subagent has been granted broad tool permissions; the correct answer notes this violates least-privilege and the coordinator should restrict each subagent to only the tools needed for its specific subtask.
Parallel vs sequential dispatch: The exam tests whether you know which subtasks can be parallelised. Independent subtasks (e.g., web search and database lookup for different aspects of a query) should be dispatched concurrently. Dependent subtasks (e.g., fetch data first, then summarise it) must be sequential.
Error propagation scenario: You will encounter questions about what the coordinator should do when a subagent returns an error or a low-quality result. Understand the difference between retryable failures and fatal ones, and when to escalate to human review.
Frequently Asked Questions
Can the coordinator itself be a subagent of a higher-level coordinator?
Yes — coordinators can nest. A top-level coordinator may delegate an entire research workflow to a mid-level coordinator, which in turn manages several specialised subagents. Each layer maintains hub-and-spoke internally. This hierarchical decomposition is appropriate for very large tasks but adds latency and makes debugging harder, so it is only justified when a single coordinator would face context window pressure from managing too many subagents simultaneously.
Should the coordinator use the most capable Claude model?
Usually yes, or at least the Sonnet tier. The coordinator performs the hardest cognitive work: decomposing ambiguous goals, handling subagent failures, and aggregating heterogeneous results. Under-powering the coordinator (e.g., using Haiku) to save cost often produces poor decomposition that defeats the purpose of the architecture. Subagents, by contrast, are good candidates for [model routing](/glossary/model-routing) to cheaper tiers because their scopes are narrow and well-defined.
What is the difference between the coordinator pattern and a simple sequential chain of prompts?
A sequential chain is a fixed pipeline: step 1 always feeds into step 2, always feeds into step 3. There is no dynamic routing, no parallel execution, and no error recovery. The coordinator pattern is dynamic: the coordinator decides at runtime which subtasks to create, which can run in parallel, and how to handle failures. The coordinator also maintains a global view of the task state that a sequential chain lacks.
Referenced in These Lessons
Coordinator-Subagent (Orchestrator) Pattern
Agentic ArchitectureAll communication flows through the coordinator (hub-and-spoke)
Error Propagation in Multi-Agent Systems
Context & ReliabilityHandle errors at the lowest level capable of resolving them
Tool Distribution & Least Privilege
Tool Design & MCPEach agent should have only the tools needed for its specific role (4-5 tools, not 18)