Multi-Agent Orchestration: When One Agent Isn't Enough

The previous chapter built a single agent: a model in a loop with tools, deciding its own next step. That one agent will carry you a long way. But there’s a point where a single agent starts to struggle. The task is too big to hold in one context window, or it spans work that wants genuinely different tools and instructions. The answer is to stop making one agent do everything and instead coordinate several. That’s multi-agent orchestration, and it’s the second-largest chunk of Domain 1. This chapter teaches the idea before it drills into what the exam tests. The exam questions only make sense once you understand why these systems are shaped the way they are.

What multi-agent orchestration actually is

A multi-agent system is a set of agents, each with its own instructions and tools, coordinated to accomplish one larger task. The word that matters is coordinated. You don’t just run several agents side by side; you have some structure deciding who does what, in what order, and how their outputs come together.

The most common shape is a coordinator that owns the overall task and delegates pieces of it to subagents, each a specialist. (Also called a manager or supervisor.) It’s the shape the exam and the Agent SDK center on. A research assistant coordinator might delegate to a search subagent, an analysis subagent, and a synthesis subagent, then assemble their results into a report. The coordinator is the only agent that sees the whole picture; each subagent sees only its slice.

That’s the mental model to hold: one agent in charge, several specialists doing scoped work, and a structure connecting them. Everything below is a variation or a consequence of that.

Why reach for multiple agents — and when not to

Multi-agent systems are more complex, slower, and more expensive than a single agent. So be honest about the bar: reach for one only when a single agent genuinely can’t do the job well. The reasons it sometimes can’t:

• Context limits. A single agent accumulates everything — every tool result, every step — in one context window (chapter 1’s stateless loop, resent each turn). On a large task that window fills, and the agent’s focus degrades: it starts forgetting earlier findings and referencing “typical patterns” instead of the specifics it discovered. Splitting the work lets each agent keep a small, focused context.
• Specialization. A subtask often wants its own instructions and its own tools — a web researcher needs search tools and a “find sourced facts” prompt; a code reviewer needs file tools and a “flag correctness bugs” prompt. Cramming both roles into one agent with one giant prompt and every tool makes it worse at both. A focused agent with the right tools and a tight prompt does its one job better.
• Parallelism. Independent subtasks can run at the same time. Say you need to research five subtopics that don’t depend on each other. Five subagents working in parallel finish in roughly the time of one, where a single agent would grind through them in sequence.
• Isolation and reliability. When a subtask fails, a well-designed system contains the failure to that subagent and the coordinator decides how to recover, rather than the whole run collapsing.

And the counterweight, which the exam also cares about: a single agent is simpler, cheaper, faster to build, and easier to debug. Multi-agent coordination adds latency (delegation round-trips), token cost (each agent re-establishes its context), and failure modes (a coordinator that decomposes badly). Anthropic’s documented guidance is to start with the simplest thing that works. One well-crafted call, then a single agent, and only then a multi-agent system, when you’ve hit a real limit of the simpler design. Reaching for multiple agents because it sounds sophisticated is a classic over-engineering trap, and the exam will offer it as a tempting wrong answer.

The landscape of coordination patterns

“Multi-agent” isn’t one architecture; it’s a family. Knowing the landscape helps you recognize which pattern a scenario calls for:

• Manager / supervisor (hub-and-spoke). A central coordinator delegates to subagents and aggregates their results; subagents don’t talk to each other. This is the default, and for good reason (below) — it’s the pattern the SDK’s Agent tool implements and the one the exam centers on.
• Hierarchical. Supervisors of supervisors — a coordinator delegates to sub-coordinators that each manage their own subagents. Useful when a task decomposes into big chunks that themselves decompose. It’s the manager pattern applied recursively.
• Sequential / pipeline. Agents arranged in a chain, each one’s output feeding the next: extract → transform → validate. Good when the stages have a fixed order and each genuinely depends on the last.
• Parallel / map-reduce. Fan the same kind of work out across many subagents (map), then merge their results (reduce) — the parallelism case above. A coordinator usually orchestrates the fan-out and the merge.
• Network / mesh (peer-to-peer). Agents communicate directly with each other, any-to-any, with no central hub. Maximally flexible, and maximally hard to control: the interaction paths multiply, failures are hard to trace, and the system can loop or thrash. It’s usually the wrong choice, and worth knowing mainly so you can recognize and avoid it.

Why does hub-and-spoke win as the default? Because a single coordinator is easy to reason about and easy to debug — every routing and error-handling decision lives in one place. It’s also structurally free of the peer-to-peer loops a mesh invites. When you centralize coordination, there’s exactly one agent to look at when something goes wrong. This is the same reason the supervisor topology is the default in other agent frameworks too.

The coordinator and its subagents

With the why in place, here’s the mechanism the exam tests, and now it should feel motivated rather than arbitrary. In the hub-and-spoke pattern the coordinator has four jobs — decompose the task into subtasks, delegate each to the right subagent, aggregate the results, and decide what to do next (including whether to spawn more subagents). Nearly every multi-agent exam item is really a question about one of those four.

In the Agent SDK, you declare subagents on the options object, and the coordinator invokes them through a built-in Agent tool. A subagent is an AgentDefinition:

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 are the whole design in miniature. tools is where specialization lives — the researcher gets WebSearch/WebFetch and nothing else, the same tool-scoping discipline that keeps any agent focused. And the coordinator can only delegate at all if Agent is in its allowed_tools; without it, the invocation is simply blocked. (A coordinator given an AgentDefinition subagent delegates to it through the Agent tool with subagent_type set, and the subagent’s output comes back to the coordinator.)

What a subagent can see: the isolation rule

This is the single fact the exam tests most in this area, and it trips people up because it’s counterintuitive: 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 tools — and nothing else. It cannot see what the coordinator discussed, what other subagents found, or even the user’s original wording. Not unless the coordinator explicitly passes that context into the invocation.

Once you understand why multi-agent systems exist, this stops being surprising and becomes the point. Isolation is exactly what delivers two of the benefits from earlier:

• It keeps each subagent’s context small and focused. A researcher flooded with the coordinator’s entire transcript would reason worse — the isolation is what preserves the focused-context advantage that motivated splitting the work in the first place.
• It forces deliberate information flow. Because nothing is shared by default, you must decide what each subagent needs and hand it exactly that. Designs that “assume the subagent just knows what we’re doing” fail, and the exam rewards designs that pass context explicitly.

The practical rule: the coordinator must package the relevant context into each subagent’s prompt. Assigning the researcher a topic means handing it the topic and its constraints in the 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 on its face — the subagent could not have seen it.

Dividing the work well

The coordinator’s hardest job is the first one, decomposition — cutting the task into subtasks — and it’s where the exam sets its traps. The strong pattern is a coordinator that analyzes the request and dynamically chooses which subagents to invoke, not one that shoves every request through the full pipeline. A simple factual question might need only the search subagent; a hard one needs search, analysis, and synthesis. A coordinator that always runs all of them wastes turns and budget on easy cases and, worse, invites idle subagents to pad or fabricate.

Two decomposition failures — the wrong answers the exam offers:

• Too narrow, leaving gaps. Split a topic so finely that each subagent covers a sliver and the union of the slivers doesn’t cover the whole question. Coverage has holes no single subagent was responsible for.
• Overlapping, duplicating work. Scopes that weren’t cleanly partitioned, so two subagents chase the same sources — you pay twice and then have to reconcile their (possibly conflicting) findings.

The property that avoids both is worth memorizing: good decomposition is complete and disjoint — every part of the task is covered by exactly one subagent, no gaps and no overlap. That’s the test to hold any proposed decomposition against.

And notice that the coordinator choosing its subagents is just model-driven control from the loop chapter, one level up. The coordinator reads the request, reasons about what it needs, and calls the Agent tool for the subagents it judges necessary. It is the agentic loop again, with subagents as the tools. A coordinator hard-wired to always run the same fixed sequence has thrown that judgment away — the pre-configured pipeline anti-pattern in a multi-agent costume.

Final thoughts

Multi-agent orchestration is what you reach for when one agent’s context, focus, or specialization gives out — not before, because coordination has real costs. The dominant shape is hub-and-spoke: a coordinator that decomposes, delegates, aggregates, and decides, over subagents that are deliberately isolated so each keeps a small, focused context. Among the coordination patterns — supervisor, hierarchical, pipeline, parallel, mesh — the centralized supervisor wins by being debuggable, and the mesh loses by not being. The two facts the exam presses hardest both fall out of the design’s purpose. Subagents inherit no history, so context is passed explicitly, which is what keeps them focused. And decomposition should be complete and disjoint, so coverage has no gaps and no duplication. Understand why the system is built this way and the exam items stop being trivia and become obvious.

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