Multi-Agent Orchestration: Coordinators and What Subagents Can See

Once one agent works, the natural next move is several — a coordinator that delegates to specialists, exactly the Multi-Agent Research System scenario (a coordinator managing search, analyze, synthesize, and report subagents). Three of Domain 1’s task statements live here: orchestrating coordinator–subagent systems (1.2), configuring subagent invocation and context passing (1.3), and designing task-decomposition strategies (1.6). The exam tests two things hardest — what a subagent can see and how the coordinator divides the work: so those get the most attention below. Built against claude-agent-sdk 0.2.128.

Hub-and-spoke: the coordinator owns the wiring

The standard multi-agent shape is hub-and-spoke: a single coordinator agent sits at the center, and all inter-subagent communication, error handling, and information routing flows through it. Subagents don’t talk to each other; they report back to the coordinator, which decides what happens next. This is the same reason the supervisor topology is the default in other agent frameworks — one hub is easy to reason about, easy to debug (every routing decision is in one place), and structurally free of the peer-to-peer loops a mesh invites.

The coordinator’s job is four verbs: decompose the task, delegate to the right subagents, aggregate their results, and decide what to do with them — including whether to invoke more subagents. Everything the exam asks about multi-agent design is a question about how well the coordinator does one of those four.

Defining a subagent

In the Agent SDK, subagents are declared on the options object and invoked through the built-in Agent tool. A subagent is an AgentDefinition, and its fields are the knobs you’ll be asked about. Verified — claude-agent-sdk 0.2.128’s AgentDefinition fields are:

from claude_agent_sdk import ClaudeAgentOptions, AgentDefinition

options = ClaudeAgentOptions(
    agents={
        "researcher": AgentDefinition(
            description="Searches the web and returns sourced findings.",
            prompt="You research one topic thoroughly and return cited findings.",
            tools=["WebSearch", "WebFetch"],   # the subagent's own tool set
            model="claude-haiku-4-5",
            # also available: disallowedTools, skills, memory, mcpServers,
            # maxTurns, background, effort, permissionMode, initialPrompt
        ),
    },
    allowed_tools=["Agent"],   # the coordinator must be allowed to call Agent
)

Two of those fields decide the whole design. tools scopes what the subagent can do — a researcher gets WebSearch/WebFetch and nothing else, which is the same tool-scoping discipline that keeps an agent focused. And the coordinator can only spawn a subagent if Agent is in its allowed_tools; otherwise the invocation is blocked. (⚠️ The runtime — the coordinator actually delegating and a subagent running — is pending the live execution pass; the AgentDefinition fields and the allowed_tools requirement are introspection-verified.)

The context-isolation rule

Here is the fact the exam tests more than any other in this area, and it’s counterintuitive until you internalize it: a subagent does not inherit the coordinator’s conversation history. A spawned subagent starts with its own system prompt, the project’s CLAUDE.md, and its own tool definitions — and nothing else. It cannot see what the coordinator discussed, what other subagents found, or the user’s original phrasing, unless the coordinator explicitly passes that context in the invocation.

This is a feature, not a limitation, and knowing why is the exam-ready understanding:

• It keeps each subagent’s context small and focused, which improves its reasoning and cuts its token cost — a research subagent flooded with the coordinator’s entire transcript would reason worse, not better.
• It forces deliberate information flow. Because nothing is shared automatically, you have to decide what each subagent needs and pass exactly that. Sloppy designs that “assume the subagent knows what we’re doing” fail, and the exam rewards designs that pass context explicitly.

The practical consequence: the coordinator must package the relevant context into each subagent’s prompt. Assigning the researcher a topic means handing it the topic and any constraints in its invocation, not trusting it to have overheard them. If an exam item describes a subagent “using information from an earlier step” that was never passed to it, that’s a bug — the subagent couldn’t have seen it.

Decomposition: dynamic delegation, not a fixed pipeline

Domain 1.6 is about how the coordinator divides the work, and the blueprint is opinionated. The strong pattern is a coordinator that analyzes the query and dynamically selects which subagents to invoke, rather than always routing every request through the full pipeline. A simple factual question might need only the search subagent; a complex one needs search, analysis, and synthesis. A coordinator that always runs all four wastes turns and budget on the easy cases and — worse — invites subagents to pad or fabricate when they have nothing to do.

Two decomposition risks the blueprint calls out, which is to say two wrong answers the exam will offer:

• Overly narrow decomposition, where the coordinator splits a broad research topic too finely and each subagent covers a sliver, leaving gaps in coverage: the union of the pieces doesn’t cover the whole question. The fix is decomposition that partitions the scope completely, not just conveniently.
• Duplicated work, where subagents overlap because their scopes weren’t partitioned cleanly — two researchers chasing the same sources. The fix is assigning distinct, non-overlapping scopes so the coordinator isn’t paying twice for the same findings and then reconciling conflicts.

The through-line: good decomposition is complete and disjoint — every part of the task is covered by exactly one subagent. That’s the property to check an exam item’s proposed decomposition against.

Delegation is model-driven too

The coordinator deciding which subagents to invoke is the same model-driven control from the loop chapter, one level up. The coordinator reads the query, reasons about what it requires, and calls the Agent tool for the subagents it judges necessary — it is not a hard-coded switch statement. This is why the dynamic-selection pattern is the strong one: it is the agentic loop, with subagents as the tools. A coordinator that always invokes the full pipeline has replaced the model’s judgment with a fixed sequence, which is the pre-configured-decision-tree anti-pattern wearing a multi-agent costume.

Final thoughts

Multi-agent orchestration is hub-and-spoke: a coordinator that decomposes, delegates, aggregates, and decides, with subagents defined by AgentDefinition and invoked through the Agent tool. The two facts the exam presses hardest are that subagents inherit no conversation history — so the coordinator must pass context explicitly — and that decomposition should be complete and disjoint, dynamically selected rather than a fixed full-pipeline run. Both come back to the same principle from the loop chapter: let the model’s judgment drive control, and be deliberate about what information crosses each boundary.

Next: workflows, hooks, and sessions — enforcing multi-step workflows, intercepting tool calls with hooks, and managing session state, resumption, and forking.