Multi-Agent Systems: Orchestration Patterns That Actually Work

When multiple agents beat one

Start from a position of skepticism. A single well-built agent, given good tools and a clear objective, solves most problems that teams reach for multi-agent designs to solve. Every additional agent adds a coordination surface: a place where instructions get garbled, context is lost in translation, and two workers duplicate or contradict each other. That overhead is real, it is paid on every run, and it does not show up in the architecture diagram. The question is never "would more agents help?" It is "does the shape of this work justify the coordination tax?"

Three shapes justify it. The first is parallel breadth: the task splits into many independent subtasks that do not depend on each other's intermediate results. Researching twelve competitors, checking a codebase against forty rules, or gathering evidence from a dozen sources are all embarrassingly parallel, and wall-clock latency drops when workers run at once. The second is specialist separation: subtasks need genuinely different tools, system prompts, or permission scopes, and cramming them into one agent produces a bloated prompt that does every job poorly. The third is context isolation: each subtask needs a large, focused working context, and keeping them separate prevents one agent's window from filling with another's irrelevant detail.

Notice what is absent from that list: "the problem is complicated." Complexity alone is an argument for a better single agent, more explicit planning, or stronger tools, covered in Planning & Decomposition. Multi-agent is an answer to width and separation, not to difficulty. Confusing the two is the most common way teams talk themselves into an architecture that costs five times as much to run the same job slightly worse.

The orchestrator-worker pattern

When multi-agent is warranted, one pattern dominates production systems. A lead agent, the orchestrator, receives the objective, decomposes it into subtasks, spawns worker subagents to execute them (often in parallel), and synthesizes their outputs into a final result. The workers do not talk to each other; they report to the orchestrator, which owns the plan and the assembly. Anthropic described a multi-agent research system built exactly this way in 2025, with a lead agent coordinating parallel subagents that each explored a slice of a research question.

              +---------------+
              | ORCHESTRATOR  |
              | plan & assign |
              +------+--------+
             /       |        \
            v        v         v
       +-------+ +-------+ +-------+
       |WORKER1| |WORKER2| |WORKER3|   run in parallel
       +---+---+ +---+---+ +---+---+
            \        |        /
             v       v       v
              +---------------+
              | ORCHESTRATOR  |
              |  synthesize   |
              +---------------+

The pattern works because it maps cleanly to parallel breadth: the orchestrator's decomposition creates the independent subtasks, and the workers exploit them for latency. It also isolates context by construction, since each worker gets only the slice of the problem it needs. The hard part is not the fan-out; it is the two ends. Decomposition has to produce subtasks that are genuinely independent and clearly scoped, or workers duplicate effort and step on each other. Synthesis has to reconcile outputs that may disagree, which is real reasoning work, not string concatenation.

Two engineering disciplines make it hold up in production. First, give the orchestrator an explicit budget: how many workers it may spawn and how deep the delegation may go, so a vague objective cannot metastasize into forty subagents. Second, make worker instructions self-contained and task-shaped, because a worker only sees what the orchestrator hands it. A worker told "look into pricing" will wander; one told "find list prices for these five SKUs from the vendor's public pricing page and return them as a table" will not.

Handoffs and specialist routing

Orchestrator-worker is the pattern for parallel breadth. Two other patterns handle sequential and routing-shaped work, and it is worth keeping them distinct because they fail differently. In a sequential handoff, control passes from one specialist to the next along a pipeline: an intake agent structures a request, a drafting agent produces a response, a review agent checks it. Each agent finishes its stage and hands the working state forward. This suits work with genuine stages, where each step depends on the last, and it is closer to a workflow than to a swarm.

A router does something narrower: it classifies each incoming request and directs it to the single right specialist, then gets out of the way. A support system might route billing questions to a billing agent, technical questions to a diagnostic agent, and account changes to a permissioned agent that can actually make them. The router itself does no domain work; its whole job is a good routing decision, and its whole failure mode is a bad one. Keep it small, cheap, and evaluated on classification accuracy alone.

Peer handoff, sometimes called a swarm, lets agents pass control directly to one another without a central coordinator. It is the most flexible arrangement and the hardest to reason about, because no single agent owns the outcome and control can loop. Treat it as an advanced option for genuinely open-ended problems, not a starting point. Across all three, the design rule is the same: keep the interface between agents task-shaped and explicit. Whatever crosses a handoff is a contract, and vague contracts are where multi-agent systems quietly lose information.

Coordinating state

Every multi-agent system has to answer one question: how do agents share what they learn without corrupting each other's work? There are two dominant answers, and the choice shapes everything downstream. The first is a shared blackboard: a common memory or workspace that all agents read from and write to. It is simple, keeps everyone current, and suits tightly coupled work. Its weakness is contention: when two agents write overlapping conclusions, the blackboard accumulates conflicts, and without a resolution rule the next reader inherits the mess.

The second answer is explicit message passing: agents exchange scoped, structured messages and keep their own working context private. This is the model orchestrator-worker uses, and it isolates context by default, which is exactly why that pattern scales to many parallel workers. Its cost is that information the orchestrator does not explicitly forward simply does not reach the workers, so the decomposition has to carry the right context into each message. Neither model is universally correct; the coupling of the work decides.

The failure this discipline prevents is duplicated and conflicting work. If two workers can independently decide to research the same subtopic, you pay twice and then have to reconcile two versions. The fix is upstream, in decomposition: subtasks should partition the problem, not overlap. When overlap is unavoidable, the owner-of-truth resolves it at synthesis time rather than letting conflicting writes pile up in shared memory. Memory design compounds this, and the tradeoffs live in Memory & State.

The cost problem

Multi-agent systems are expensive in a way that is easy to underestimate at design time and impossible to ignore on the invoice. The mechanism is simple: every agent is a full model context that consumes tokens on its own system prompt, its slice of the task, its tool results, and its reasoning. Run several in parallel and you multiply that spend. Anthropic's engineering writing on multi-agent systems noted that they can burn far more tokens than a single-agent chat: illustratively on the order of several times, and in heavier configurations reaching roughly fifteen times a normal chat. Treat those figures as illustrative orders of magnitude, not a quote, but plan as if they are directionally right.

Cost is not only tokens. Coordination adds latency even when workers run in parallel, because the orchestrator has to decompose before fan-out and synthesize after fan-in, and both are sequential bottlenecks. It adds engineering overhead: state management, retry logic, and stopping conditions that a single agent never needs. And it adds a variance tax, since a slow or failing worker can stall the whole run while the orchestrator waits. The right mental model is that multi-agent is a premium architecture you buy deliberately, the way you would provision a high-availability database rather than a single instance.

• Match spend to value. A parallel research agent that saves an analyst two hours can justify many times the token cost of a chat. A parallel agent answering a routine question cannot.
• Right-size the workers. Simple worker subtasks often run well on a smaller, cheaper model, reserving the frontier model for the orchestrator's decomposition and synthesis.
• Cap the fan-out. Bound worker count and delegation depth so cost scales with the task, not with the model's enthusiasm.
• Measure cost per resolved task, not cost per call. The only honest denominator is a job actually completed.

Failure modes to design against

Multi-agent systems fail in characteristic ways, and the good news is that the failure modes are predictable enough to design against before they appear in production. The most damaging is the cascading error: one worker returns a subtly wrong finding, the orchestrator treats it as ground truth, and the mistake propagates into the synthesis and every downstream decision. Because no human sees the intermediate step, a single early error can poison a confident final answer. The defense is validation at the seams: the owner-of-truth should sanity-check worker outputs rather than trusting them wholesale.

Three more failure modes recur. Duplicated or conflicting work comes from weak decomposition, as covered above, and is fixed upstream in how subtasks partition the problem. Lost-in-coordination is the slow leak: context that mattered never crossed a handoff, so a worker solves a slightly wrong problem and no one notices until the answer is assembled. Runaway loops are the scary one: an agent spawns subagents that spawn subagents, or a swarm hands control in a cycle, and cost climbs without termination. Each has a concrete guardrail.

Two mechanisms cut across all of these. Stopping conditions are non-negotiable: a maximum number of steps, a maximum delegation depth, and a hard token or time budget, so any run terminates whether or not it succeeded. And for consequential actions, human checkpoints belong in the loop. An agent system that can send emails, move money, or change production configuration should require approval at those points, not because the model is untrustworthy but because untrusted content can reach it through tool outputs. That threat, and the defense-in-depth it demands, is the subject of Guardrails & Sandboxing and the deep-dive on prompt injection.

Evaluating multi-agent systems

You cannot manage a multi-agent system on end-to-end task success alone, though that is the headline number and the one that pays the bills: given a realistic objective, did the system finish the job correctly? The problem is that a single pass-or-fail tells you the failure rate, not the failure location, and in a system with an orchestrator and five workers the location is the whole question. Add trajectory evals: did each agent actually do its assigned job? Did the orchestrator decompose the task into sensible, independent subtasks? Did each worker stay in scope and return what it was asked for? Did synthesis reconcile the workers correctly rather than averaging their mistakes?

The third axis is cost per resolved task, and it is the one that most often changes an architecture decision. A multi-agent system that resolves tasks at five times the token cost of a single agent for a two-point gain in success rate is not a better system; it is a more expensive one. Tracking cost per resolved task alongside quality is what keeps the premium architecture honest, and it is the number a skeptical CTO should ask for first. The full method for trajectory and tool-call scoring lives in the deep-dive on evals.

Build the evaluation harness before the system is in production, not after the first incident. Multi-agent systems have more moving parts and more silent failure surfaces than single agents, which means the gap between "looks like it works" and "measurably works" is wider. The teams that run these architectures successfully are not the ones with the cleverest orchestration; they are the ones who can prove, run over run, that the coordination is buying something worth what it costs. You can prototype these patterns and watch their trajectories in Agent Studio.