A multi-agent system (MAS) is a setup in which several AI agents split up the roles and work in parallel to finish one job. A coordinating agent divides the work, worker agents (subagents) each research or write in their own separate context, and the coordinator combines the results.
But adding agents does not automatically make the system smarter. In an experiment by Google Research and others across six kinds of tasks, multi-agent setups did up to about 81% better than a single agent on work that could be split up, and up to 70% worse on work that has to proceed step by step. This article covers the definition and the five patterns, then uses that experiment and published material from Anthropic, Cognition and others to get you to the point where you can judge which jobs it helps with and which jobs it makes worse.
Multi-agent = a team of specialists running in parallel
— instead of asking one AI to do everything, a small expert team divides the work
Each one has its own context window and runs in parallel.
The coordinator checks the results before combining them — in experiments, whether such a checking coordinator exists made a large difference to how far errors spread.
Table of contents
- 1. What is a multi-agent system?
- 2. Why orchestrate multiple AIs at all?
- 3. The five patterns
- 4. What experiments show: where it helps and where it hurts
- 5. How real products use it
- 6. Cost — about 15x the tokens of a chat
- 7. A decision table: should you use it?
- 8. Design essentials and common failure types
- 9. How each pattern is written in the main SDKs
- Summary
- FAQ
1. What is a multi-agent system?
A multi-agent system (MAS) is a setup in which several AI agents cooperate to solve one task. Each agent has its own instructions (prompt), its own tools and its own context, and together they reach the overall goal by passing results back and forth.
The building block, a single agent, runs a loop of "think → use a tool → look at the result" on its own, as explained in What is an AI agent. The closest way to think of a multi-agent system is that loop plus division of roles and parallelism.
How it differs from a single agent
| Aspect | Single agent | Multi-agent |
|---|---|---|
| Structure | One AI runs the loop | Several AIs work together |
| Context | Everything goes into one window | Split by role (unrelated information doesn't mix) |
| Parallelism | Mostly one step after another | Workers can proceed at the same time |
| How errors spread | Its own mistakes pile up | Without a checker, a worker's mistake goes straight into the final result |
| Cost | Lower (about 4x a chat) | Higher (about 15x a chat) |
| Good at | Step-by-step work where each step depends on the previous one | Research, comparison and checking that can be split into independent parts |
The token multipliers are the figures Anthropic published for its own research feature (How we built our multi-agent research system, June 13, 2025). More in section 6.
2. Why orchestrate multiple AIs at all?
The starting point is "if one agent can do it all, use one." You need a multi-agent system when you hit three walls that a single agent structurally struggles to get past.
Three walls a single agent struggles with
As an example of the effect, Anthropic reported that for Claude's Research feature, a setup with Claude Opus 4 as the coordinator and Claude Sonnet 4 as workers scored 90.2% better on its internal research evaluation than Opus 4 working alone (same source). The same post says that the amount of tokens used explained 80% of the variance in performance by itself (on BrowseComp, a research evaluation). In other words, most of the strength of a multi-agent system comes from running separate contexts side by side so it can read more than fits into one agent.
3. The five patterns
Multi-agent systems come in a handful of shapes. Each product names them differently, but they mostly fall into the following five. Where it applies, the matching category from the experiment in section 4 (independent, centralized, decentralized, hybrid) is noted too.
3-1. Orchestrator–worker (the most widely used)
One coordinator (orchestrator) splits the work and hands it to several workers (subagents). Each worker runs in a separate context and returns its result to the coordinator. In the experiment's terms this is centralized. Anthropic's research feature, Claude Code subagents and the "call an agent as a tool" style in the OpenAI Agents SDK (Agent.as_tool()) follow this pattern.
3-2. Handoff (a relay of owners)
Agents pass control of the conversation by saying, in effect, "you take it from here." In the OpenAI Agents SDK docs, the specialist that receives a handoff becomes the active agent for the rest of the turn. It suits front-desk work, such as routing an inquiry from intake to billing or technical support. Swarm, the experimental predecessor of this SDK, now says in its repository that it has been replaced by the Agents SDK, so new projects should use the Agents SDK.
3-3. Hierarchy (a team of teams)
A tree in which middle coordinators sit under the top coordinator, with workers under them. In Claude Code, subagents can spawn their own subagents up to three layers deep by default (official docs), and Cursor 2.5 in February 2026 also let workers spawn workers. Every extra layer adds tokens and waiting time, so set a depth limit.
3-4. Peer-to-peer (debate and consensus)
No coordinator: several agents put forward views as equals and repeat until they agree. In the experiment's terms this is decentralized. Research on Multi-Agent Debate reports better factuality and reasoning. It tends to do well on jobs that require weighing several viewpoints against each other, such as web research (section 4).
3-5. Pipeline (a fixed order)
Each agent is run in a fixed order, such as "research → structure → verify → output." Because a program, not the AI, decides which agent runs next, results are stable and it is easy to see where something failed. The OpenAI Agents SDK presents "chaining" (passing one output as the next input) and "evaluator loops" (cycling a maker and an evaluator) as patterns you build in code.
The five patterns at a glance
4. What experiments show: where it helps and where it hurts
Which pattern wins flips depending on the nature of the job. The paper that put numbers on this is Towards a Science of Scaling Agent Systems by researchers from Google Research, Google DeepMind and elsewhere (latest version April 2026). Using three model families — GPT, Gemini and Claude — it compares five setups (a single agent and four multi-agent setups) across six kinds of tasks and 260 combinations (introduced on the Google Research blog in January 2026; the blog's figure of 180 configurations reflects the first version).
Source: section 4.2 of the paper. For fixing code and for planning, every multi-agent setup tested did worse than a single agent; the chart shows the one that lost the least (fixing code −2.1% to −14.9%, planning −39.1% to −70.0%).
Three things stand out.
- It pays off strongly only on work that can be split: in financial analysis, revenue, costs and markets can be researched separately and combined at the end, so the centralized setup beat a single agent by about 81%.
- It backfires on work that depends on order: on the planning task, where each move determines the next, every setup did worse than a single agent. Splitting the work lets assumptions drift between workers and spends effort on coordination.
- Fixing code did not improve either: Anthropic also writes that "most coding tasks involve fewer truly parallelizable tasks than research" (its post), which is consistent with this result.
A checking coordinator keeps errors from spreading
The same paper measured how much worker errors spread into the final result for each setup (as a multiple, with a single agent = 1).
Independent (no discussion, no checks)
17.2x
Worker results are simply put side by side, so errors stay in
Decentralized (debate among equals)
7.8x
Discussion fixes some errors, but nobody is responsible for checking
Hybrid
5.1x
Coordinator plus some discussion between workers
Centralized (coordinator checks)
4.4x
The coordinator checks worker results before combining them
Source: Table 5 of the paper (Error Amp). In the same table, the number of turns per task averaged 7.2 for a single agent, versus 27.7 for centralized and 44.3 for hybrid.
"If one agent already solves 45% or more, adding agents tends to backfire." The paper reports that on tasks where a single agent's accuracy already exceeds about 45%, adding agents tends to lower the score. The experiment supports this order of work: measure with one agent first, and decide whether to add more only after you see that number.
5. How real products use it
Anthropic's research feature: scaling the number of workers with difficulty
Claude's Research is a classic orchestrator–worker setup: the coordinator splits the question, workers research in parallel and the coordinator combines the results. The most useful part of the published design is that the prompt states how many workers to use depending on how hard the question is (its post).
| Type of question | Number of workers | Tool calls |
|---|---|---|
| Simple fact-finding | 1 (just the coordinator) | 3–10 |
| Direct comparison | 2–4 | 10–15 each |
| Complex research | Sometimes more than 10 | Each worker gets a clearly divided responsibility |
Anthropic writes that before these guidelines, early versions made mistakes such as spawning 50 workers for a simple question. When you build your own, the quickest move is to put this table straight into your prompt as the rule for sizing the job. Switching to calling search and other tools in parallel also cut research time for complex questions by up to 90%.
Subagents in Claude Code and Codex
In Claude Code you can hand research, reviews and similar work to subagents. Each subagent runs in its own context and returns only a summary to the parent, so the parent's context does not fill up. By default up to 20 can run at once, nested up to three layers deep. The difference from "agent teams," where workers talk to each other as they go, is covered in Claude Code subagents vs agent teams, and how to ask for parallel work side by side with Codex is in Parallel subagents in Codex and Claude Code.
Devin (Cognition): from "don't build" to "coordinate"
In June 2025 Cognition published "Don't Build Multi-Agents," arguing that parallel workers who don't know each other's decisions produce results that conflict. Its two principles are "share context, and share full agent traces, not just individual messages" and "actions carry implicit decisions, and conflicting decisions carry bad results."
In March 2026 the same company shipped a feature in which Devin breaks down a large task and delegates it to several Devins working in parallel, each in its own virtual machine. The parent Devin monitors progress, resolves conflicts and compiles the results. Rather than abandoning parallelism, it settled on a design where the parent takes responsibility for conflicts between workers — which matches section 4's finding that a checking coordinator keeps errors from spreading.
Cursor: carrying on without waiting for workers
In version 2.5 (February 17, 2026), Cursor made subagents run asynchronously so the parent can keep working without waiting. Workers can also spawn workers of their own. Anthropic likewise writes that synchronous execution, where the coordinator waits for workers to finish, "creates bottlenecks," so not making the parent wait has become a shared problem across vendors.
6. Cost — about 15x the tokens of a chat
Anthropic writes that agents use about 4x more tokens than chat, and multi-agent systems about 15x (its post). Applied to your own use case, the estimate looks like this.
Sample estimate (multipliers from Anthropic's research feature; they vary by job)
A question that costs 10,000 tokens as a chat → about 40,000 with one agent, and about 150,000 tokens with a multi-agent system.
At 100 requests a day: chat 1 million, one agent 4 million, multi-agent 15 million tokens. Multiply by the per-token price in the official price list of the model you use.
Tokens are not the only thing that grows
Set hard limits and soft targets separately
Once workers spawn workers and something falls into a loop, costs balloon fast. When you build with Claude, there are two kinds of limits that work differently.
| Limit | Where to set it | Does it stop the run? |
|---|---|---|
| Spending cap | max_budget_usd in the Claude Agent SDK (maxBudgetUsd in TypeScript) | Yes (no new workers are spawned and the query ends) |
| Nesting depth | Environment variable CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (default 3, 1 turns nesting off) | Yes (workers on the bottom layer do the work themselves) |
| Concurrent workers | Environment variable CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS (default 20) | Yes (no workers beyond the limit are spawned) |
| Task budget | task_budget in the Claude API (beta, minimum 20,000 tokens) | No (a target the model uses to pace itself) |
Sources: Subagents in the Agent SDK and Task budgets (checked November 12, 2026). The three hard limits above apply to TypeScript SDK v0.3.219 and Python SDK v0.2.127 or later; on earlier versions some are missing or have different defaults. The docs describe task budgets as advisory rather than enforced, so combine them with a spending cap or max_tokens when you need a run to stop for certain.
7. A decision table: should you use it?
Putting the material above together, five questions settle most decisions. Answer them from the top; if any one lands on the "single agent" side, build with one agent first.
| Question | Favors multi-agent | Favors a single agent | Basis |
|---|---|---|---|
| Can the job be split into independent parts? | Yes (per company, per document, per angle) | Each step depends on the previous result | Financial analysis +80.8%, planning −39.1% to −70.0% |
| How well does one agent already do? | Low accuracy with one agent | One agent already solves about 45% or more | The Google Research et al. paper |
| Do workers need to share the same context? | Each worker's own information is enough | Results conflict unless everyone sees the same context (most coding) | Anthropic, Cognition |
| Does it fit in one context? | Too much material; one agent's context overflows | Fits in one agent's context | Token usage explained 80% of the variance in performance |
| Is the result worth 15x the tokens? | High value per request (research, audit and comparison reports) | High-volume routine processing, front desks needing instant answers | Anthropic's ~15x |
Anthropic, too, advises in its guide to building agents to find the simplest solution possible and add complexity only when needed. The steps to get started and minimal code samples are in How to build a multi-agent system, and how to build your first single agent is in How to build an AI agent.
8. Design essentials and common failure types
① Give every worker its objective, output format, tools and boundaries
Anthropic writes that with vague instructions, workers misread the task, repeat the same searches as other workers, or miss information they needed. Spell out for every worker (1) the objective, (2) the format to return, (3) the tools and sources it may use and (4) the boundaries of the task. A Claude Agent SDK subagent does not receive the parent's conversation; the only thing passed to it is the prompt you give when calling it (official docs), so write file paths and decisions already made into that prompt.
② Say how deep to dig
Workers are bad at deciding for themselves how far to research. Write sizing guidelines like the table in section 5, and set the reasoning depth as well. Claude's effort can be set per worker, and agent definitions in the Agent SDK accept anything from low to max. Keeping simple workers light and verification workers deep holds costs down.
③ Make checking part of the coordinator's job
As section 4 showed, the centralized setup — where the coordinator checks worker results before combining them — spread errors far less than the unchecked independent setup (4.4x vs 17.2x). Include in the coordinator's instructions a step to look for contradictions between worker results and verify the evidence before accepting them.
④ Know the failure types
Researchers from UC Berkeley and elsewhere sorted failures into 3 categories and 14 types using more than 1,600 execution traces from seven multi-agent systems (Why Do Multi-Agent LLM Systems Fail?). It works as a checklist when you review a design.
| Category | What happens | Remedy |
|---|---|---|
| System design issues | Agents ignore role or task instructions, repeat the same steps, or don't know when to stop | Write roles, scope and stop conditions into the prompts |
| Misalignment between agents | Assumptions conflict, needed information isn't passed on, other agents' input is ignored | Share the full trace; have the coordinator resolve conflicts |
| Missing verification | Stopping too early, not checking, or checking only superficially | Assign a checker (the coordinator or a verification worker) |
⑤ Build logging first
If you can't see what a multi-agent system is doing, you can't fix it. Record each worker's inputs and outputs, time taken, tokens and tool calls from day one. On evaluation, Anthropic writes that it started with about 20 queries that reflected real usage and had an AI grade them against a rubric. Watching how a small set of queries changes, rather than waiting for a large evaluation system, is the practical way to go.
9. How each pattern is written in the main SDKs
The same pattern goes by different names in each SDK. For choosing between them (speed of prototyping, production maturity, token usage), see AI agent frameworks compared; here we only show which building block corresponds to each pattern in section 3.
| SDK | Orchestrator–worker | Handoff / pipeline |
|---|---|---|
| Claude Agent SDK | Define workers with agents and call them with the Agent tool (formerly Task) | No dedicated building block; run a pipeline by calling agents in order from your own code |
| OpenAI Agents SDK | Call workers as tools with Agent.as_tool() | Pass control with handoffs; build chaining and parallel runs in code |
| LangGraph | Branch from a coordinator node to worker nodes | Write order, branching and loops as a graph of nodes and edges |
| Strands Agents (AWS) | Call workers as tools with Agents as Tools | Let workers hand off to each other with Swarm; set the order with Graph or Workflow |
| Microsoft Agent Framework | Includes multi-agent orchestration patterns as building blocks | Set the order as a workflow |
Microsoft has archived the AutoGen repository and no longer provides bug fixes or security fixes for it (checked November 12, 2026). For new projects, it recommends the successor, Microsoft Agent Framework. Minimal code samples for each SDK are in How to build a multi-agent system.
Summary
- A multi-agent system splits up roles among several AIs that work in parallel to finish one job. It gets past a single agent's walls: overflowing context, no parallelism, and the maker being its own checker.
- The five patterns are orchestrator–worker, handoff, hierarchy, peer-to-peer and pipeline. Orchestrator–worker is the most widely used.
- Whether it helps depends on the job. On financial analysis that can be split it beat a single agent by +80.8%; on order-dependent planning it lost 39.1% to 70.0%; fixing code did not improve either.
- With a checking coordinator, error spread fell from 17.2x (independent) to 4.4x.
- Tokens run about 15x a chat (about 4x for one agent). Set spending, depth and concurrency as hard limits that actually stop the run.
- Order of decisions: build and measure with one agent first. Split off workers only for the parts that can be divided and where one agent proved not to be enough.
FAQ
Q1. Is a multi-agent system always better than a smart single agent?
No. Anthropic's research feature scored 90.2% better than a single agent, but that was on research that could be split into independent parts. In the Google Research et al. experiment, every multi-agent setup did worse than a single agent on the order-dependent planning task. It comes down to whether the job can be split.
Q2. Does multi-agent help with coding?
Having several workers write parts of a single fix tends not to help. In the experiment, every multi-agent setup scored below a single agent on fixing code (SWE-bench Verified), by −2.1% to −14.9%. On the other hand, handing independent work such as research, reviews and running tests to workers so the parent's context stays free is a typical use of Claude Code subagents.
Q3. Can you move from a single agent to multi-agent step by step?
Yes. Build with one agent first and measure accuracy, tokens and time; when you can see where the context overflows or where work could run in parallel, split off only those parts into workers. If you design everything as multi-agent from the start, you can't measure what is actually helping.
Q4. Is there a standard communication protocol between agents?
For connecting agents to tools and data, MCP (Model Context Protocol) has become the de facto standard. It originated at Anthropic, was donated to the Linux Foundation's Agentic AI Foundation in December 2025, and is adopted by OpenAI, Microsoft, AWS, and others. For agent-to-agent communication there is Google-originated A2A (Agent2Agent), which has also moved to the Linux Foundation. IBM's ACP (Agent Communication Protocol) merged into A2A in August 2025.
Q5. Will a task budget prevent runaway costs?
Not on its own. A task budget in the Claude API is a target the model uses to pace itself, and the docs say it is not enforced. To stop a run for certain, set the Agent SDK's spending cap (max_budget_usd) and limits on nesting depth and concurrent workers (table in section 6).
Q6. Are "subagents" and "multi-agent" different things?
Subagents are the workers used in the orchestrator–worker pattern of a multi-agent system. In the Claude Agent SDK, the main agent stays single and calls workers with the Agent tool only when needed. Setups where workers talk to each other directly as they go (such as agent teams in Claude Code) are closer to the peer-to-peer or hybrid pattern.
