Multi-Agent Orchestration

Multi-agent orchestration is a way of running an AI system in which one agent, the lead, splits a task into pieces, gives each piece to a separate agent with its own context window and tools, and merges what comes back. The lead plans and synthesises. The specialists each do one slice without seeing the others' work.

It is worth the extra machinery in one situation: the task is broad, the slices can be worked without reading each other, and the evidence for all of them would bury a single agent's context. Everywhere else, one AI agent with a good loop is easier to build, less expensive to run and easier to debug.

When several agents beat one#

Two things justify the split. The first is context isolation. A single agent doing broad research fills its window with search results, page dumps and dead ends, and well before the window is full the useful evidence is hard for the model to find in it. A specialist explores its slice in a fresh window and returns a short summary, so the lead's context holds conclusions rather than raw pages. The second is focus: each specialist gets one job, a prompt written for it and only the tools it needs.

The strongest published result is Anthropic's research system, where a lead running Claude Opus 4 with Claude Sonnet 4 subagents beat a single Opus 4 agent by 90.2 percent on Anthropic's internal research eval. The gain sat on breadth-first queries, such as finding the board members of every Information Technology company in the S&P 500, where a single agent searching one company after another failed. Read the analysis before the headline, though. On the BrowseComp benchmark, token usage alone explained 80 percent of the variance in performance. Much of the multi-agent win is that the system spends more tokens than one window can hold.

That gives the first test we recommend, before writing any orchestration code: give one agent the same token budget and see whether the gap closes. If it does, the split was buying tokens, and a larger budget for one agent is the simpler fix.

The lead-and-workers pattern#

The common structure has one lead, also called a supervisor or orchestrator. The lead reads the goal, breaks it into slices, starts a subagent for each, waits for the results and writes the final answer. Subagents never talk to each other, and everything flows through the lead. LangChain's documentation calls this subagents as tools: each specialist is exposed to the lead through tool calling, so delegating is one more tool call the model decides to make.

The task description decides whether it works. Anthropic found that a vague instruction such as "research the semiconductor shortage" led one subagent to the 2021 automotive chip crisis while two others duplicated each other on 2025 supply chains. Write each slice the way you would write a ticket for a contractor: the objective, the shape of the result, the tools to use, and where the slice stops. A competitive analysis of eight vendors becomes eight calls, each told to profile one vendor's pricing and enterprise features in a fixed format, return sources, and leave the other seven alone, followed by one synthesis pass over eight structured results.

Handoffs move the conversation instead#

The lead-and-workers pattern keeps one agent in charge for the whole run. A handoff moves control itself to a peer. In the OpenAI Agents SDK a handoff is a tool: an agent called Refund Agent appears to the model as a tool named transfer_to_refund_agent, and calling it gives the conversation to that agent, which takes over from there. That shape fits triage, where a front door classifies a support request and passes the whole session to billing, orders or refunds rather than relaying messages for them. We prefer a lead for anything that has to be checked before it counts, because a lead that keeps the merge gives the application one place to check each return.

What crosses the boundary#

The hard design question is how much one agent passes to the next. Pass the full conversation and you lose the isolation you split for. Pass a one-line summary and the specialist re-derives or contradicts decisions already made. Pass structured artifacts instead: a plan the lead keeps current, files the specialists write to (a form of agent memory), and a fixed result format so the merge is mechanical rather than interpretive. Anthropic recommends that subagents store large outputs in external systems and pass lightweight references back, which keeps bulk out of the lead's window.

What it costs#

Anthropic measured single agents at about 4 times the tokens of a chat interaction and multi-agent systems at about 15 times. A question that costs a cent as a plain completion can cost dollars as an orchestrated run, so the split only makes sense when the answer is worth that: research that saves a person a day, due diligence, a large code audit. Latency is the better side of the ledger, because subagents run in parallel and a ten-direction task finishes close to the time of its slowest branch. Putting the lead on a frontier model and the subagents on a smaller one also follows from the shape of the work, since a scoped slice needs less judgment than planning and synthesis.

Count every agent against one cap. A subagent that starts its own counter can pass its limit while the run as a whole is already over budget, and our guide to multi-agent systems puts the lead, every worker and every retry on a single budget in the request path.

Where multi-agent runs break#

More agents give more places to fail. The MAST study, built from more than 1,600 annotated execution traces across 7 multi-agent frameworks, sorts the failures into three groups: system design (bad specifications, missing stop conditions), misalignment between agents (one agent ignoring or contradicting another), and task verification (nobody checks the merged result). Errors also travel upward. A wrong claim from one subagent flows into the synthesis unchallenged unless something checks it, so a small error rate per specialist becomes a larger one per final answer.

Cognition's essay "Don't Build Multi-Agents" makes the case against: actions carry implicit decisions, and parallel agents that cannot see each other's work make conflicting ones that no merge can reconcile. We agree for sequential, tightly coupled work, which includes most coding. Those tasks belong in one agent with continuous context. A team running many coding agents at once should split by task instead, one change per agent, which is how an AI software factory runs in parallel.

Check every return before the merge#

The check we recommend for each worker's return is the one our single agents already run. On Solarpunk, our executive operations desktop agent, a critic decides after every step whether to continue, retry or escalate, and the run compares the agent's claimed completion against the actual state of the application it changed. That comparison catches an agent reporting success on work that did not land. Apply it to each worker before its slice is merged: a worker's account of its own slice is not evidence, and a separate read of the expected state is. Then evaluate the whole system end to end with evals, because per-agent quality says little about the merged answer.