Responsabilidades del coordinador

In a multi-agent system, Claude orchestration follows a hub-and-spoke shape: one coordinator at the hub, several subagents on the spokes. The coordinator never does the deep work itself — it manages the work.

A coordinator has exactly five responsibilities you must master for the exam:

• Decompose — split a task into subtasks
• Delegate — hand each subtask to a subagent
• Aggregate — merge subagent results
• Route — send work to the right specialist
• Handle errors — recover or escalate failures

This lesson walks through each, with the patterns and anti-patterns that separate a passing answer from a plausible distractor.

The single most tested coordinator fact: subagents do NOT inherit the coordinator's conversation history. Each subagent is a fresh Claude context.

The model keeps no state between turns or across agents. Whatever a subagent needs to do its job — the user's goal, prior findings, constraints, IDs — must be passed explicitly inside that subagent's prompt.

Forgetting this is a classic failure: the coordinator 'knows' the customer ID or the research question, assumes the subagent does too, and the subagent fabricates or stalls. Context isolation is a feature (it keeps focus tight), but it puts the burden of context-passing squarely on the coordinator.

Because nothing is inherited, the coordinator builds each subagent prompt as a self-contained briefing. Notice how the goal, the constraints, and the specific slice of work are all spelled out — the subagent could run on a machine that never saw the conversation.

This is also why an AgentDefinition carries a system_prompt and least-privilege allowed_tools: each subagent is scoped to its role and given only what it needs.

Decomposition is choosing how to break the work apart. Two strategies, and the exam wants you to match strategy to situation:

• Fixed pipeline / prompt chaining — for a known, sequential set of steps (e.g. extract -> validate -> format). The structure is decided in advance.
• Adaptive decomposition — for open-ended investigations where you can't know the subtasks until you start (e.g. a research question that branches as you learn).

A second decomposition pattern worth knowing: multi-pass code review. Do a per-file local pass first, then a separate cross-file integration pass. A single-pass multi-file review dilutes the model's attention and misses both local bugs and integration issues.

The coordinator delegates by issuing Task calls. The key performance fact: multiple Task calls in a single response run in parallel.

For independent subtasks — three research questions, three files to scan — emit all the Task calls together rather than one per turn. You get concurrency for free.

Two prerequisites the exam tests: the coordinator's allowedTools must include "Task", and each subagent must receive its full context explicitly (Scene 2).

Routing means sending each subtask to the right subagent. Claude chooses based primarily on the agent and tool descriptions — not the names.

A good description states purpose, what it returns, input formats with examples, and applicability boundaries. Overlapping or ambiguous descriptions cause misrouting: if two subagents sound like they both handle 'data', the coordinator may pick wrong.

Scope each subagent narrowly. Keep 4-5 tools per agent as the sweet spot; 18+ tools degrades selection reliability. Least-privilege tooling isn't only about security — it sharpens routing.

Once subagents return, the coordinator aggregates their outputs into one coherent answer. This is more than concatenation.

• Keep provenance: every claim maps to its source (URL, doc name, quote, publication date).
• Annotate conflicts rather than silently picking one number — and remember dates often resolve apparent contradictions.
• Render by content type: tables for financials, prose for news, lists for technical findings.

Aggregation is also where you preserve partial results: if one subagent failed, the coordinator still merges what succeeded and clearly marks the gap.

The fifth responsibility is the one that breaks fragile systems. The rule:

• Recover transient faults locally inside the subagent (e.g. a timeout — retry there).
• Escalate non-recoverable failures upward with partial results, so the coordinator can route around them.

Two anti-patterns to avoid: silently suppressing an error (the coordinator never learns), and aborting the whole workflow because one subagent failed. One failed spoke should not collapse the hub.

Crucially, distinguish an access FAILURE (maybe retryable) from a valid EMPTY result (no matches — not an error at all).

The coordinator can only route around a failure if the failure tells it enough. A generic "Operation failed" blocks recovery. A structured error enables intelligent routing.

Structured error context includes the failure type / category, whether it is retryable, the attempted query, any partial results, and alternatives. With that, the coordinator decides: retry, try another tool, merge partials, or escalate.

The coordinator runs an agentic loop: send the request, inspect stop_reason, and if it is tool_use, run the tools (including Task delegations), append results to history, and repeat until end_turn.

Terminate on the stop_reason — never by parsing the model's text for words like 'done' or 'finished'. Decisions about when work is complete are model-driven. An iteration cap is a safety net, not the primary stop mechanism.

Reserve hard-coded control for guarantees you must enforce; let the model decide the flow otherwise.

Some failures aren't the coordinator's to solve — they belong to a human. Good escalation triggers:

• An explicit human request — escalate immediately.
• Policy gaps the agent has no rule for.
• No progress after reasonable attempts.
• Threshold violations (e.g. a refund above a limit).

Bad triggers the exam will offer as distractors: sentiment analysis, the model's own self-rated confidence (1-10), or untrained classifiers. And when a business rule has financial, legal, or safety consequences, enforce it with a deterministic hook, not prompt guidance — hooks are 100% deterministic, prompts only ~90% probabilistic.

A research coordinator delegates a sub-question to a researcher subagent. The coordinator already discussed the user's goal and gathered earlier findings in its own conversation. What MUST the coordinator do for the subagent to succeed?

You can now reason about a coordinator like an architect:

• Decompose — fixed pipelines for known sequences, adaptive for open-ended work; multi-pass (local then cross-file) for code review.
• Delegate — emit multiple Task calls in one response to run in parallel; include 'Task' in allowedTools.
• Route — sharp, non-overlapping descriptions pick the right specialist; 4-5 tools per agent.
• Aggregate — merge with provenance, annotate conflicts, preserve partial results.
• Handle errors — recover transient faults locally; escalate non-recoverable failures with structured context and partial results; never silently suppress or abort the whole workflow.

Above all: subagents inherit no history — pass context explicitly, and stop on stop_reason, never on parsed text. Enforce financial/legal/safety rules with deterministic hooks. Master these and the orchestration scenarios are yours.