- In short
- Coordinator responsibilities are the duties a hub agent owns in a multi-agent system: decomposing the task, dynamically selecting which subagents to invoke, passing each the context it needs, aggregating their results, and routing errors. The coordinator is the single point of control and observability.
What the coordinator is responsible for
In a hub and spoke architecture the coordinator is the active brain at the centre, and its job is a bundle of distinct coordinator responsibilities. It analyses the incoming request and breaks it into pieces. It decides which specialised subagents the request actually needs. It supplies each subagent with the context that subagent requires, because of context isolation. It collects the results, judges whether they are complete, and synthesises a final answer. And when something goes wrong, it owns the recovery.
The exam tests this at the understand level, which means it wants you to recognise which duty a given task belongs to and to appreciate that these duties live at the hub, not the spokes. Anthropic's research-system write-up describes the lead agent doing precisely this work: it "analyzes" the query, "develops a strategy," "spawns subagents," and then "synthesizes these results and decides whether more research is needed."
- Coordinator responsibilities
- The duties owned by the hub agent in a multi-agent system: task decomposition, dynamic subagent selection, context passing, result aggregation and synthesis, and error routing.
Decomposition: breaking the goal into work
The first responsibility is turning a broad goal into concrete sub-tasks. Good decomposition partitions the work so that subagents cover the whole problem with minimal overlap, each spoke gets a clear, bounded slice. Poor decomposition is the root of a specific failure mode covered in narrow decomposition failure: if the coordinator carves the problem too narrowly, whole subtopics go uncovered and no downstream agent can rescue them.
This is why decomposition is the responsibility the exam scrutinises most. When a multi-agent system produces an answer that is coherent but incomplete, the instinct is to blame the subagents that did the visible work. The architect's discipline is to trace coverage gaps back to how the coordinator split the task in the first place. The spokes can only research what they were assigned.
Selection: not every subagent, every time
The second responsibility is choosing which subagents to invoke, and the key insight is that the coordinator should select dynamically. A naive design routes every request through the full set of subagents as if it were a fixed pipeline. A strong coordinator instead reads the request and invokes only the relevant subagents, skipping the ones a particular query does not need.
Dynamic selection matters for both quality and efficiency. Running irrelevant subagents wastes time and tokens and can inject noise into the synthesis. Choosing the right subset keeps the system focused. The exam often contrasts a rigid "always run everything" design against an adaptive coordinator and asks which is better; the adaptive one usually wins precisely because selection is a coordinator responsibility, not a hard-wired route.
Context passing, aggregation, and error routing
Three further responsibilities round out the role. Because subagents are isolated, the coordinator must pass context, embedding each subagent's needed inputs directly in its prompt. After the spokes report back, the coordinator must aggregate: combine the outputs, evaluate them for gaps or contradictions, and synthesise one answer. This is also where iterative refinement lives, since a thorough coordinator re-delegates targeted follow-ups when the first pass is thin.
Finally, the coordinator owns error routing. When a subagent fails in a way it cannot recover from locally, the failure surfaces to the coordinator, which decides whether to retry, reroute, or proceed with partial results, the subject of multi-agent error handling and routing. Routing everything through the hub is what makes the whole system observable: there is one node where decomposition, selection, context, synthesis, and recovery all happen and can be logged.
Why these duties cluster at the hub
A natural question is why all of this work lands on one agent rather than being spread out. The answer is that each duty requires a view of the whole task, and only the coordinator has it. Decomposition needs to see the entire goal to split it well. Selection needs to weigh the request against the full roster of subagents. Aggregation needs every subagent's output at once to synthesise and spot gaps. Error routing needs to know what else is in flight to decide whether to reroute. A spoke, confined to its isolated slice, simply lacks the vantage point to make any of these calls.
This is why the coordinator is sometimes described as the system's brain rather than its switchboard. A switchboard merely connects callers; the coordinator actively reasons about the task at every stage. When the exam asks "which component should make decision X," the test is whether you recognise that X requires whole-task awareness, and if it does, the answer is the coordinator, because awareness of the whole is its defining privilege and its defining burden.
Observability is a by-product of central control
A valuable side-effect of concentrating these responsibilities at the hub is that the system becomes observable almost for free. Because decomposition, selection, context passing, synthesis, and error routing all happen at one node, that node is the single place you instrument to understand what the system did and why. You can log which subagents were chosen for a request, what context each received, what each returned, and how the coordinator resolved any failures, a complete trace from one vantage point.
Compare that to a hypothetical design where subagents talked among themselves: the decision-making would be smeared across many private exchanges with no central record, and debugging would mean reconstructing a conversation that left no single log. The hub and spoke discipline, by funnelling every responsibility through the coordinator, turns observability from a hard distributed-systems problem into a matter of logging one node. For a production multi-agent system, that is not a minor convenience; it is what makes the system operable at all. The same central vantage point also makes cost and latency attributable: because the coordinator dispatches every subagent call, it can record the tokens and wall-clock each delegation consumed, so you can see exactly which part of the decomposition is expensive and tune the roster or the prompts accordingly. Without that hub, per-subagent cost accounting would be another distributed problem to solve from scratch.
Worked example: a research coordinator that adapts
Worked example
A research system answers varied questions. Some need market data, some need legal analysis, some need both.
A question arrives: "What are the financial risks of this acquisition?" A rigid coordinator would invoke every subagent it owns, market, legal, technical, regardless of fit. The adaptive coordinator instead reads the question, recognises it is primarily financial with a legal angle, and selects just the market and legal subagents, skipping the technical one entirely.
It decomposes the question into "quantify the financial exposure" and "identify regulatory hurdles," passes each subagent the acquisition details it needs, and waits for results. On aggregation it notices the financial subagent did not address currency risk, so it re-delegates a targeted follow-up rather than accepting the gap. Only once coverage is satisfactory does it synthesise the final risk assessment. Every one of those moves, selection, decomposition, context passing, gap-checking, re-delegation, is a coordinator responsibility, and none of them belongs to the spokes.
Trace the same scenario through a rigid coordinator and the contrast is sharp. It would have run the technical subagent needlessly, padding the answer with irrelevant detail and spending time the query did not warrant. It would have accepted the missing currency-risk angle because it never evaluated coverage. The two systems use identical subagents; the difference in output quality comes entirely from how well the coordinator discharged its responsibilities. That is the lesson the exam keeps returning to: in a multi-agent system, the coordinator's judgment, not the subagents' raw capability, is usually what determines whether the answer is good.
Misconceptions to retire
Misconception
A good coordinator runs all of its subagents on every request to be thorough.
What's actually true
Misconception
If the final answer misses a topic, the subagent that produced it is to blame.
What's actually true
The coordinator as the system's accountable owner
A helpful frame for the whole role is accountability. In a hub and spoke system, the coordinator is the one component answerable for the outcome, because it is the one component that touches every stage. If the answer is incomplete, the decomposition or selection is accountable. If a subagent worked on the wrong inputs, the context passing is accountable. If a failure vanished without trace, the error routing is accountable. Each of those is a coordinator responsibility, which is why so many post-mortems of multi-agent systems end at the hub.
That accountability is not a burden to resent but a design principle to lean on. Because one node owns the outcome, you have one place to strengthen when quality slips and one place to inspect when something goes wrong. The spokes can stay simple and specialised precisely because the coordinator carries the cross-cutting concerns. When you design or evaluate one of these systems, ask of any desired property, completeness, relevance, recovery, traceability, which coordinator responsibility delivers it, and you will almost always find the answer at the hub.
How this is tested on the exam
Task 1.2 leans heavily on coordinator responsibilities because so many multi-agent failures resolve to them. Expect questions that ask which component owns a duty (almost always the coordinator), that contrast a rigid full-pipeline design against an adaptive one (the adaptive coordinator that selects dynamically is usually correct), and that ask you to locate the root cause of an incomplete answer (trace it to decomposition or selection at the hub). This knowledge point unlocks several harder ones, decomposition failures, iterative refinement, and error routing, so understanding the coordinator's full remit is the lever that opens the rest of the task statement.
A multi-agent system always routes every query through all five of its subagents. The team finds responses are slow and sometimes cluttered with irrelevant detail. Which coordinator responsibility is being mishandled?
People also ask
What are the responsibilities of a coordinator agent?
Does the coordinator always run every subagent?
How does the coordinator combine subagent results?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Designing effective subagents
Why watch: Good subagent design starts with the coordinator decomposing and scoping work appropriately.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.