Multi-agent systems and orchestration

What a multi-agent system is, and what it costs

A multi-agent system is several agents — each a model using tools in a loop — working on one task. The usual shape, described in Anthropic’s account of its Research feature, is orchestrator-worker: a lead agent analyses the request, decides on a strategy and spawns subagents to explore different parts at the same time, then combines what they return. Each subagent has its own context window, instructions and tools.

The price is tokens. In that same account, agents used about four times the tokens of a chat interaction and multi-agent systems about fifteen times. Anthropic’s later guidance on when to use multi-agent systems puts the overhead at roughly three to ten times the tokens of a single agent doing the same task, coming from duplicated context, coordination messages and summaries at every handoff. The conclusion for an architect is blunt: the task has to be valuable enough to pay for it.

The payoff can be large where it fits. On Anthropic’s internal research evaluation, a lead agent on a larger model with subagents on a smaller one outperformed the larger model working alone by about 90%. Their analysis found that token usage explained most of the variance in performance on a browsing benchmark — which is the real reason multi-agent works: it lets a system spend more tokens in parallel, in separate context windows, than one agent could hold.

The same guidance names where multi-agent struggles: work where every agent needs the same shared context, work with heavy dependencies between agents, and much of coding, which has fewer truly parallel pieces than research. Its recommendation is to start with a single well-designed agent and add agents only when one of the three reasons above is a real, observed constraint.

Five coordination patterns

Once more than one agent is justified, the next decision is how they coordinate. Anthropic describes five patterns. Learn each by the situation that calls for it and the way it fails, because scenario items describe the symptom rather than the name.

Split by context, not by job title

The most common design mistake is to mirror a human org chart: a planner agent, a writer agent, a tester agent and a reviewer agent passing work down a line. Anthropic calls this problem-centric decomposition and warns that it becomes a game of telephone — every handoff loses detail the next agent needed. The better rule is context-centric: draw agent boundaries where the context genuinely separates. An agent that builds a feature should also write its tests, because it already holds the context the tests depend on. How to find those seams in a problem is the subject of 1.5.

One multi-agent pattern works reliably almost everywhere: the verification subagent. Checking a result against clear success criteria needs very little backstory, so the context-transfer problem mostly disappears. If a team insists on a second agent, a verifier is usually the one to add first.

Designing the handoff

A subagent knows only what it is told. In the Agent SDK, a subagent starts with a fresh context: its own system prompt, the tool definitions it is allowed, and the prompt string the parent writes when it delegates. It does not see the parent’s conversation or earlier tool results, so file paths, decisions and constraints must be in the brief. Only its final message comes back.

Anthropic learned this the hard way. Early versions of its research lead agent gave short instructions such as “research the semiconductor shortage”, and subagents duplicated each other’s work or misread the task. The fix was to teach the lead to write a proper brief: an objective, an output format, guidance on tools and sources, and clear boundaries. They also taught it to scale effort to the question — a simple fact-finding query needs one agent and a handful of tool calls; a complex one may justify ten or more subagents with divided responsibilities.

Research competitor pricing.

Objective: find list prices for the
3 rival products named below, EU only.
Scope: public price pages and filings
from the last 12 months. Skip blogs.
Not your job: US prices, discounts
(another agent covers those).
Tools: web_search, fetch only.
Return: a table of product, price,
currency, date, source URL, and one
line on anything you could not find.
Keep it under 300 words.

What comes back matters as much as what goes out. Anthropic’s context-engineering guidance describes subagents that may use tens of thousands of tokens exploring but return a condensed summary of roughly one to two thousand. For large artefacts — a long report, a dataset, generated code — the research-system account describes subagents writing their output to storage and passing back a lightweight reference, so the full result does not have to squeeze through the lead agent’s context.

from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition

options = ClaudeAgentOptions(
    allowed_tools=["Read", "Grep", "Agent"],   # Agent lets the lead delegate
    agents={
        "contract-reader": AgentDefinition(
            description="Extracts obligations from one contract. Use per contract.",
            prompt="List obligations as JSON with clause refs.",
            tools=["Read", "Grep"],            # read-only: cannot change anything
            model="haiku",                     # cheaper model for bounded work
        ),
        "checker": AgentDefinition(
            description="Verifies extracted obligations against the source clauses.",
            prompt="Flag any obligation not supported by its cited clause.",
            tools=["Read"],
        ),
    },
    env={"CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH": "1",   # no nested spawning
         "CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS": "5"},  # at most 5 at once
    max_budget_usd=10.0,                                # hard spend cap
)

Bounding and operating the system

An orchestrator decides for itself how many agents to spawn, so an architect has to set the limits. The Agent SDK exposes three: nesting depth, how many subagents run at once, and a spend cap for the whole query that counts every subagent’s requests. Subagents can be given restricted tool lists and a cheaper model. Anthropic’s hosted Managed Agents offers the same idea as a coordinator with a roster of agents, each in its own isolated thread but sharing one sandbox and filesystem; it is in beta, allows one level of delegation, and caps roster size and concurrent threads.

Operating the system brings problems a single call never has. Anthropic’s research agents ran synchronously — the lead waited for each batch of subagents — which is simple to coordinate but means one slow subagent holds up everything. Agents are stateful across many tool calls, so a failure midway should resume from a checkpoint rather than restart. Tracing every agent’s decisions is what makes failures diagnosable, and deployments have to avoid breaking agents that are mid-task. Evaluation starts small: Anthropic began with about twenty real queries, used an LLM judge with a rubric on the final result, and kept humans testing for the failures the rubric missed. (Metrics and observability are covered in Domain 4.)

Traps the wrong answers are built from

You should now be able to

• Decide whether a task justifies multiple agents using context protection, parallelization and specialization.
• Estimate and explain the token overhead of a multi-agent design against its benefit.
• Choose among generator-verifier, orchestrator-subagent, agent teams, message bus and shared state for a scenario.
• Draw agent boundaries by context rather than by role, and add a verifier where it helps.
• Write a delegation brief and a return contract that survive the handoff.
• Bound an orchestrator with tool restrictions, depth, concurrency and spend limits.