A multi agent system is a design in which several AI agents, each a language model with its own instructions, tools and context, work on parts of one task and pass results between them, usually under a lead agent that plans the work and combines the answers. It earns its extra cost when a task splits into independent parts that can run in parallel, such as broad research across many sources, and it usually makes things worse when every step depends on the one before. The published evidence from Anthropic, OpenAI and academic research points the same way: start with one agent, and add more only when you can show the single agent is the bottleneck.
What is a multi agent system?
Anthropic's definition is the most compact: a multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together. Each agent is a full agent in its own right, with a prompt, a set of tools and its own context window. What makes it a system is the coordination: who decides what each agent does, how results flow back, and who owns the final answer.
Andrew Ng described the idea in 2024 as the fourth of his agentic design patterns. A complex task such as writing software is broken into subtasks for different roles, such as a software engineer, product manager, designer, QA (quality assurance) engineer, and each agent may ask the others for help. His argument for doing this even with a single underlying model was focus: a model prompted to do one thing at a time can perform better than one juggling a long, complex context. We cover the other three patterns in our guide to agentic workflows.
How does a multi agent architecture work?
There are four common shapes. The first two are the ones OpenAI describes as broadly applicable in its guide: a manager that coordinates specialized agents via tool calls, and a decentralized pattern where agents hand off tasks to one another.
| Pattern | Who is in control | How work moves | Documented example |
|---|---|---|---|
| Orchestrator-worker (manager) | A lead agent | The lead calls workers like tools and merges their outputs | Anthropic's Research feature; OpenAI's agents as tools |
| Handoff (decentralized) | Whichever agent is active | One agent transfers the conversation to a specialist | OpenAI Agents SDK handoffs |
| Code-orchestrated pipeline | Your code | Agents run in a fixed order or in parallel, decided by code | OpenAI Agents SDK, orchestrating via code |
| Subagents for context isolation | The main agent | A side task runs in its own context and returns only a summary | Claude Code subagents |
Orchestrator-worker. Anthropic's Research feature uses an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel. The lead analyzes the question, plans, and spins up workers; Anthropic reports the lead typically starts 3 to 5 subagents in parallel, each using 3 or more tools in parallel, which cut research time by up to 90% for complex queries.
Handoffs. In OpenAI's Agents SDK, a handoff lets one agent delegate to another, and handoffs are represented as tools to the LLM, so a handoff to a refund agent appears to the model as a tool named transfer_to_refund_agent. The SDK documentation gives a clear rule for choosing: use agents as tools when a specialist should help with a bounded subtask but should not take over the user-facing conversation, and use handoffs when routing itself is part of the workflow.
Code orchestration. The same documentation describes a second approach, orchestrating via code, where your program decides which agent runs when. This is less flexible and far more predictable.
Subagents. Claude Code uses subagents to keep the main conversation clean: each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions, and returns a summary rather than everything it read.
What did Anthropic learn from its multi-agent research system?
Anthropic's write-up, published on June 13, 2025, is one of the few detailed public accounts of a multi-agent system in production, and its numbers explain both the appeal and the cost.
The headline result: a system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on Anthropic's internal research eval. The reason is less mysterious than it sounds. On the BrowseComp benchmark, Anthropic found that token usage by itself explains 80% of the variance in performance, with the number of tool calls and the model choice as the other factors. Multiple agents work largely because they let the system spend more tokens, in parallel, across separate context windows.
That is also the bill. In Anthropic's data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats. Anthropic's conclusion is that the task has to be valuable enough to pay for the performance.
Three lessons from the write-up apply to any build:
- Delegation must be explicit. Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries; without them, agents duplicated work and left gaps.
- Effort must be budgeted. Early versions made errors like spawning 50 subagents for simple queries. The fix was written scaling rules: simple fact-finding gets one agent with 3 to 10 tool calls, while complex research may use more than 10 subagents.
- Tool descriptions matter more than expected. A tool-testing agent that rewrote poor tool descriptions produced a 40% decrease in task completion time for later agents using them.
When do multiple agents beat a single agent?
Anthropic names three conditions: multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools. Its example was finding all the board members of the companies in the Information Technology S&P 500, which the multi-agent system solved by splitting the work and the single agent failed with slow, sequential searches.
OpenAI gives the trigger from the other direction. Its general recommendation is to maximize a single agent's capabilities first, and to split only when your agents fail to follow complicated instructions or consistently select incorrect tools. It notes that the number of tools is not the problem on its own: some implementations manage more than 15 distinct tools, while others struggle with fewer than 10 that overlap.
When do multi-agent systems make things worse?
When the work is tightly coupled. Anthropic says domains that require all agents to share the same context or involve many dependencies between agents are not a good fit, and that most coding tasks involve fewer truly parallelizable tasks than research.
Academic work backs this up. The paper "Why Do Multi-Agent LLM Systems Fail?" opens with the observation that for multi-agent systems, performance gains on popular benchmarks are often minimal. Its authors annotated more than 1,600 traces across 7 popular frameworks and built a taxonomy of 14 unique modes, clustered into 3 categories: (i) system design issues, (ii) inter-agent misalignment, and (iii) task verification, with inter-annotator agreement of kappa 0.88.
Cognition, the company that makes Devin, made the practical version of the argument in a post titled Don't Build Multi-Agents in June 2025. Its example: split "build a Flappy Bird clone" into a background subtask and a bird subtask, and one subagent may build a background that looks like Super Mario Bros while the other builds a bird that does not look like a game asset, leaving a final agent to combine two miscommunications. Its two principles are to share full context between agents, and to recognize that actions carry implicit decisions, so conflicting decisions produce bad results.
Cost is the other risk. If a single agent already handles the task, a multi-agent version mostly multiplies the token bill. Our guide to AI agent cost shows how to estimate that before you build.
Where do MCP and A2A fit?
They are plumbing, and they solve different problems. The A2A project's own documentation puts it simply: MCP is for agent-to-tool communication, standardizing how an agent connects to its tools, APIs and resources, while A2A is for agent-to-agent communication, letting independent agents discover each other, delegate tasks and share results.
The Model Context Protocol is an open-source standard for connecting AI applications to external systems; if you want the details, read our explainer on what an MCP server is. A2A was originally developed by Google, and on June 23, 2025 the Linux Foundation announced the launch of the Agent2Agent (A2A) project. It is maintained by a technical steering committee that, according to the project, includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow.
One boundary is worth knowing before you design around it. The A2A documentation states that it is not a sub-agent protocol: A2A does not specify how an agent talks to its own sub-agents or how it invokes tools. Inside your own system, the orchestrator and its workers talk through your framework. A2A matters when your agent needs to work with an agent someone else built and runs.
How do you design a multi agent system that holds up?
- Prove the single agent is the bottleneck. Run your test cases on one well-equipped agent first, as OpenAI recommends, and split only where it fails.
- Split by independence, not by job title. Parallel research directions split well. Steps that each depend on the previous one do not.
- Write a brief for every worker. Objective, output format, tools and boundaries, the four elements Anthropic found necessary.
- Keep writes in one place. Let workers gather and analyze; let one agent, or your code, make the changes to real systems, so decisions cannot conflict.
- Budget effort. Cap the number of subagents, tool calls and tokens per run, scaled to the difficulty of the request.
- Evaluate the end result. Anthropic started with a set of about 20 queries representing real usage patterns; a small set run often beats a large set run rarely.
- Put a person in front of irreversible actions. The OpenAI Agents SDK supports this directly, letting you pause agent execution until a person approves or rejects a tool call.
If you want this designed around your own processes rather than a demo, Qubba builds AI agent systems scoped per process, with a fixed written quote after a 30 minute call.
Frequently asked questions
What is an example of a multi agent system?
Anthropic's Research feature in Claude is a documented one: a lead agent plans the research, starts subagents that search in parallel, and a citation step attributes claims to sources before the answer returns to the user.
A common business example is a support setup where a triage agent hands the conversation to a billing or refunds specialist.
Is a multi agent system better than a single agent?
Only for some tasks.
On broad, parallel research Anthropic measured a large gain.
On tightly connected work, such as most coding, the published evidence and practitioner reports point the other way.
Test both on your own cases before deciding.
Which frameworks are used to build multi-agent systems?
OpenAI's Agents SDK supports both agents as tools and handoffs.
Andrew Ng pointed to AutoGen, CrewAI and LangGraph in 2024, and AutoGen's paper describes it as an open-source framework that allows developers to build LLM applications via multiple agents that can converse with each other.
You can also orchestrate agents in plain code, which is often easier to debug.
How much more does a multi-agent system cost to run?
Expect a large multiple of a single chat.
Anthropic measured about 15 times the tokens of a chat interaction for its multi-agent system and about 4 times for a single agent, so the same task can cost several times more as a multi-agent run than with one agent.
Set token and subagent caps from the first day.