A single-agent system is one AI agent that owns a task from start to finish. It runs a single reasoning loop: read the goal, pick a tool, run it, read the result, decide whether to continue or stop. Everything it knows sits in one context window, and everything it did sits in one trace.
A multi-agent system is two or more AI agents that split a task between them and exchange messages to coordinate it. Each agent usually has its own context window, its own tool access and its own instructions, so no single agent holds the whole task and coordination becomes part of the architecture rather than an implementation detail.
The single-agent vs multi-agent debate is one of the more confused conversations in AI agent design, partly because both sides frame the question as architectural when it is really economic. The technical question is "what can multiple agents do that one cannot?" The practical question is "is the coordination cost worth what you gain?" The honest answer for most operator tasks is no.
Multi-agent research has real momentum: Anthropic's published guidance on building agents (Anthropic engineering, "Building Effective Agents") explicitly recommends starting with a single agent and only graduating to multi-agent when one cannot meet the requirement. That framing matches what shows up in production: multi-agent systems are powerful but expensive to operate reliably, and the failure modes are harder to debug than single-agent failures.
The definitions, sharpened
A single-agent system uses one AI agent loop. The agent sees the goal, picks tools, executes, observes results, and either continues or stops. It owns the full task end-to-end. The internal complexity is in the agent's reasoning loop, the tool list, and the memory layer, but the architecture is one process. The loop itself is the same one described in how AI agents work, no matter how many agents you eventually run.
A multi-agent system uses two or more agents that exchange messages. The shapes vary: a planner-worker split (one agent decomposes, another executes), a critic loop (one agent generates, another reviews), a specialist team (researcher, writer, fact-checker), or a hierarchy (orchestrator at the top, sub-agents below). Those shapes and their trade-offs are catalogued in AI agent architecture patterns explained. What unites them is that no single agent owns the task; coordination is part of the architecture.
The framing matters because it changes what failure looks like. In a single-agent system, the agent either succeeds or fails visibly. In a multi-agent system, the failure can be a silent disagreement: two agents continue to act on incompatible assumptions, and the failure surfaces only when the result lands.
Side by side, the differences that actually change a buying or design decision:
| Dimension | Single-agent | Multi-agent |
|---|---|---|
| Task ownership | One loop owns the task end to end | No agent owns the whole task; coordination is part of the design |
| Context | Everything shares one window, so it degrades once the task outgrows it | Each agent carries its own window, which is the main reason to split |
| Token cost | Roughly one pass over the task | Higher: every handoff re-sends context, and critic loops pay for the same work twice |
| Latency | Sequential, but no negotiation overhead | Parallel steps can be faster; message round trips can make it slower |
| Failure mode | Visible: the agent succeeds or it does not | Silent disagreement: agents act on incompatible assumptions until the result lands |
| Debugging | One trace to read | Multiple interleaved traces, and the bug is often in the handoff |
| Setup cost | One prompt, one tool list, one permission boundary | Per-agent prompts and tool scopes, plus a routing protocol and loop limits on top |
| Governance and audit | One permission boundary and one log to review | Separate boundaries per agent, which is sometimes the reason to split and always more to audit |
| Team skill required | Prompt design and tool design | The same, plus distributed-systems instincts for routing, retries and termination |
| Best fit | Most operator tasks: a defined job with a clear finish line | Genuine parallel decomposition, or roles needing real specialisation |
When multi-agent helps
Three conditions make multi-agent worth the operational cost. Each one is a requirement you can state out loud rather than a preference, and the wider family of designs sits in multi-agent systems explained.
Context exceeds one window
If the task involves more context than fits in a single agent's window, splitting becomes necessary. Code reasoning across a large repository, document review across hundreds of pages, or research synthesis across many sources can overflow even modern context limits. A planner agent that decides what each sub-agent reads, plus sub-agents that work on their slice, can solve problems that one agent cannot fit into a single window. The mechanics of splitting the work and passing state along are covered in how to chain agents for complex tasks.
Role specialisation produces measurably better outputs
Some tasks benefit from a critic in the loop. A writer agent that drafts and a critic agent that scores against an explicit rubric can outperform a single agent told to "draft and self-review", because the critic operates without the writer's context and catches what the writer cannot. The same pattern applies to code generation with a separate test-runner agent. The key word is measurably: if the critic loop does not produce higher pass rates on a real test set, it is not worth the coordination cost.
Parallel decomposition is clean
Some tasks split naturally. Enriching 500 leads in parallel does not require coordination beyond a queue; that is "many instances of one agent", not multi-agent in the meaningful sense. But a research task where one agent finds candidates and three sub-agents in parallel investigate each candidate can finish faster than one agent serially. The decomposition has to be clean for parallelism to help; if the sub-agents need to know about each other's findings, you are back to coordination.
When single-agent wins
For most operator tasks, single-agent is the right architecture. Sending follow-ups to leads, enriching contact data from public sources, scheduling, extracting structured data from documents, monitoring an inbox and routing items: all of these decompose poorly across multiple agents and benefit from one agent that holds the full context. That list covers most of what an AI agent can actually do in production today.
Single-agent wins on three properties that matter in production. First, debuggability: when something goes wrong, the trace is one sequence, not a graph of messages. Second, reliability under the 80-test methodology described in how we test AI agents: the failure surface is bounded by the agent's tool list, not by an unbounded coordination protocol. Third, cost: single-agent runs cost less per task because there are no inter-agent message tokens, and the cost model (covered in AI agent cost models explained) is more predictable.
The honest assessment from running three startups, captured in three startups, three shutdowns, is that buyers reward "this works reliably for what I asked" much more than "this has an impressive multi-agent architecture". Multi-agent is a means, not a feature.
Examples of each in the wild
The most instructive example in this debate is not a system. It is a reversal: one company, one product, three dated posts published just over a year apart.
Cognition argued against multi-agent systems, then shipped one
In June 2025, Walden Yan of Cognition published "Don't Build Multi-Agents". On the parallel-subagent architecture, the verdict was: "This is a tempting architecture, especially if you work in a domain of tasks with several parallel components to it. However, it is very fragile." The recommendation followed directly: "The simplest way to follow the principles is to just use a single-threaded linear agent". The worked example is a Flappy Bird clone split into two subtasks, where "subagent 1 actually mistook your subtask and started building a background that looks like Super Mario Bros", because "The actions subagent 1 took and the actions subagent 2 took were based on conflicting assumptions not prescribed upfront."
In April 2026, the same author published "Multi-Agents: What's Actually Working", which opens by conceding the change: "10 months ago I argued against building multi-agent systems. Today, a narrower class works, where agents contribute intelligence while writes stay single-threaded." The revised rule is that "multi-agent systems work best today when writes stay single-threaded and the additional agents contribute intelligence rather than actions". What he still rejects is the free-for-all: "we think the unstructured-swarm approach, arbitrary networks of agents negotiating with each other, is mostly a distraction", a verdict worth reading next to what an AI agent swarm actually is.
In June 2026, Cognition shipped Devin Fusion, which runs "two parallel agents: one with a frontier model, the other with a more cost-effective 'sidekick' model", each with its own toolset and cached context, with the main agent keeping planning, ambiguity and final review.
The useful conclusion is not that one side won the argument. It is the rule all three posts converge on: parallelise reading and thinking, serialise writing. Extra agents earn their place when they gather context and supply judgement. They start costing you the moment two of them write to the same artefact.
Multi-agent systems, by name
Anthropic's research system is the best-documented case, and the description is the builder's own. Published in June 2025, it is an orchestrator-worker design in which "a lead agent coordinates the process while delegating to specialized subagents that operate in parallel", spinning up "3-5 subagents in parallel rather than serially". Anthropic also states its own scope limit: "most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time". Claude Code subagents make the split concrete in a shipping product, where each subagent "runs in its own context window with a custom system prompt, specific tool access, and independent permissions", starts with no sight of your conversation history, and hits a documented ceiling once 20 subagents are running in a session.
Microsoft's Magentic-One (arXiv:2411.04468) puts an Orchestrator on top that "plans, tracks progress, and re-plans to recover from errors". Its authors claim "statistically competitive performance to the state-of-the-art" on the GAIA, AssistantBench and WebArena benchmarks, which is competitiveness with a leaderboard, not a controlled single-versus-multi comparison. On the framework side, OpenAI's Agents SDK implements handoffs that "allow an agent to delegate tasks to another agent", Microsoft AutoGen describes itself as "an event-driven programming framework for building scalable multi-agent AI systems", CrewAI says crews are "the 'teams' that do the heavy lifting", MetaGPT (arXiv:2308.00352) "utilizes an assembly line paradigm to assign diverse roles to various agents", and Google's A2A protocol targets agents that "don't share memory, tools and context". Every one of those descriptions is the builder's, not an independent assessment.
Single-agent systems, by name
GitHub's Copilot coding agent, announced in a May 2025 changelog, takes work the way a colleague does: "Simply assign an issue (or multiple issues) to Copilot just as you would another developer", after which it "works in the background, using its own secure cloud-based development environment powered by GitHub Actions". GitHub does not use the phrase "single agent" for it; reading it as one is our inference from the description, not the vendor's claim.
OpenAI's ChatGPT agent is presented in its system card of July 2025 as "a new agentic model in the same family as OpenAI o3", carrying a toolset rather than a team: deep research's multi-step research, Operator's remote visual browser, a "Terminal tool with limited network access", and connectors to external data sources. One model, many tools. Even the frameworks built for coordination concede the point. LangChain's own documentation notes that "Not every complex task requires this approach, a single agent with the right (sometimes dynamic) tools and prompt can often achieve similar results."
Multi-agent AI vs agentic AI
The two terms get used as synonyms, and they are not, because authoritative publishers do not agree on what "agentic AI" means.
One camp defines agentic AI by multi-agency. Sapkota, Roumeliotis and Karkee (arXiv:2505.10468, submitted May 2025, revised September 2025) draw the taxonomy so that a single tool-using LLM is an "AI Agent", while "Agentic AI" is the tier above it, marked by "multi-agent collaboration, dynamic task decomposition, persistent memory, and coordinated autonomy". On that definition, a single-agent system is by construction not agentic AI.
The other camp defines agentic AI by autonomy and treats multi-agency as an optional shape. AWS is the most explicit: it defines agentic AI as autonomy toward a goal and then subdivides it, since "In a single-agentic AI system, one AI agent handles all tasks sequentially" while "Multi-agentic AI, on the other hand, involves multiple AI agents collaborating". IBM's agentic-AI page takes the same line and Microsoft's ladder has the same shape. On that definition, most agentic AI in production is single-agent.
The disagreement is load-bearing, because the two definitions give opposite answers to "do I need multiple agents to be doing agentic AI?" A vendor quoting the first definition at a buyer is defining that buyer into a more expensive architecture. The operational answer: "agentic" describes how autonomously a system pursues a goal, and "multi-agent" describes how many separate contexts it uses to get there. Orthogonal axes, not two points on one line.
One red flag to carry out of this section. IBM's multi-agent systems page asserts that "Multi-agent systems tend to outperform single-agent systems due to the larger pool of shared resources, optimization and automation", and attaches no study, no benchmark and no date. Independent academic work contradicts it directly, and so does Microsoft's guidance that a single agent with tools is "often the right default for enterprise use cases". An unsourced superiority claim is a marketing position, not a finding.
The coordination cost, quantified
The coordination cost has four components, and each gets bigger faster than agent count. The protocols built to contain it are covered in AI agent multi-agent coordination; this section is about what they charge you.
Token cost
Inter-agent messages are model tokens. Every handoff carries context, intent, and partial results. A 3-agent pipeline routinely uses 3-5x the tokens of a single agent on the same task, even when the work itself is no bigger.
The published figures behind that range are thinner than the confidence around them suggests. Anthropic reports from its own production that "agents typically use about 4x more tokens than chat interactions, and multi-agent systems use about 15x more tokens than chats". The baseline there is chat, not a single agent, so the roughly 3.75x multi-over-single ratio people quote from it is a derivation rather than a measurement. One independent measurement exists on a narrow task: in arXiv:2508.07667 (v3, February 2026), a single-agent baseline averaged 166 tokens per sample, a two-agent pipeline 552, and a three-agent system 896. The result buried in that table is that the two-agent pipeline cost less than the same single agent running chain-of-thought reasoning, which used 641. That is one task, contextual privacy, and it does not generalise.
Latency
Sequential agents add their latencies. Even when the agents run in parallel, the synchronisation point waits for the slowest. The end-user experience is dominated by the worst path through the agent graph.
Failure-mode multiplication
Each agent has its own failure modes (the eight categories in the 80-test methodology). A multi-agent system has those failures plus handoff failures: lost context, duplicated work, infinite loops between critic and writer, agents that disagree silently. Failure modes do not add; they multiply.
Test surface growth
The test surface grows combinatorially. Two agents with eight failure categories each is not 16 categories; it is 8 + 8 plus the cross-product of handoff failures. Reliability targets that are achievable for a single agent become much harder for a multi-agent pipeline.
The best-known multi-agent number, read carefully
Anthropic reports that "a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval". It is the most quoted figure in this debate, and three caveats travel with it. The eval is internal and non-public, so nobody outside Anthropic can reproduce it. The 90.2% is a relative improvement, not an accuracy score. And the comparison is not compute-matched, because one lead model plus several subagents is being measured against one model.
The fourth caveat is the interesting one, and Anthropic publishes it in the same post. Three factors explained 95% of the performance variance on the BrowseComp evaluation, and "token usage by itself explains 80% of the variance", with the number of tool calls and the model choice as the other two. Read plainly, most of the measured gain tracks spend rather than architecture. That does not make multi-agent useless. It does mean the fair question is whether the same budget spent on one agent, with more tool calls and a stronger model, would have closed most of the gap, and that experiment has not been published. It is worth knowing how agent benchmarks are constructed before any of these numbers change a design.
What nobody has measured
There is no published, independent, compute-matched measurement of multi-agent coordination overhead against a single agent on a general task. The best available figures are one vendor's production token ratios and one academic table on one narrow problem. Every clean-looking multiplier in circulation, including the indicative bars above, is a planning figure rather than a benchmark result, and it deserves to be labelled that way in a design review.
One specific misreading is worth naming because it travels. Anthropic's "cut research time by up to 90% for complex queries" is not a multi-agent versus single-agent result. It compares Anthropic's parallelised multi-agent system with its own earlier serial multi-agent system. Several downstream write-ups report it as a single-versus-multi speedup. It is not one.
A buyer-side rule of thumb
The rule that holds up in practice: start single-agent. Promote to multi-agent only when you can name the specific reason. "It feels more powerful" is not a reason. "The context exceeds one window" is. "The critic loop produces measurably higher pass rates on our test set" is. "The decomposition is clean and parallelism is the bottleneck" is.
This is the same discipline as the 10x check in the three checks I missed: complexity needs to clear a bar, not just exist. Multi-agent architectures that look impressive on a slide often underperform single-agent versions in production because the coordination cost was not in the slide. The same test applies when you are choosing AI agents for a SaaS stack: name the requirement first, then pick the architecture that meets it.
For Gravity, the architecture is single-agent for the operator tasks the platform serves. The agent has access to a substantial tool set; the loop is one process; the test methodology is the eight-category gate. When a task class genuinely needs multi-agent (large-codebase reasoning, multi-document research synthesis), Gravity will graduate that capability rather than retrofit multi-agent into the default path. The principle is the same as in describe outcome, not workflow: keep the buyer's mental model simple; absorb complexity inside the agent only when it earns its keep.
Frequently asked questions
What is the difference between a single-agent and a multi-agent system?
A single-agent system uses one AI agent that owns the full task end-to-end, calling whatever tools it needs along the way. A multi-agent system uses two or more agents that pass work between each other, often with role specialisation. Multi-agent adds capability ceilings but multiplies coordination cost and failure modes.
When do you actually need a multi-agent system?
Multi-agent makes sense when one agent's context window cannot hold the full task, when role specialisation produces materially better outcomes, or when parallel work decomposes cleanly. For most operator tasks (sales follow-ups, lead enrichment, data extraction, scheduling) a single agent with the right tools is enough and more reliable.
What is the coordination cost in multi-agent systems?
Coordination cost includes the model tokens spent on inter-agent messages, the latency added by sequential handoffs, the failure modes that emerge at handoff boundaries (lost context, duplicated work, infinite loops), and the test surface that grows combinatorially with agent count. The cost compounds; two agents are not twice as expensive but five times as expensive to run reliably.
Do multi-agent systems perform better on benchmarks?
Mixed. On benchmarks like GAIA where tasks decompose into clear sub-skills, multi-agent systems can outperform single agents at the top of the leaderboard. On benchmarks like SWE-bench where context coherence matters more than parallelism, single-agent solutions often beat multi-agent. The benchmark-to-production gap is real; coordination failures show up in production faster than benchmarks.
How do multi-agent failures differ from single-agent failures?
Single-agent failures are usually visible: the agent stopped, took a wrong action, or refused. Multi-agent failures are often invisible until late: agents disagree silently, one drops context the other expected, or two agents both think the other is handling the next step. Debugging requires tracing the message flow, not just the final output.
What is a multi-agent system?
In Anthropic's production shape, documented in June 2025, a lead agent coordinates the process while delegating to specialised subagents that operate in parallel. More generally, IBM defines a multi-agent system as multiple AI agents working collectively to perform tasks on behalf of a user or another system. The dividing line worth knowing is that calling another agent as a tool makes the second agent part of the first agent's environment, while a true multi-agent system has all the agents modelling each other's goals, memory and plan of action.
When should you use a multi-agent system?
Use one when the work genuinely parallelises, when the information exceeds a single context window, or when separate security boundaries are required. Anthropic says multi-agent systems excel at tasks involving heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools. Microsoft's guidance is to use the lowest level of complexity that reliably meets your requirements. The disqualifying condition is shared state: if every agent needs the same context, splitting them costs more than it buys.
Is ChatGPT an agent or an LLM?
Both, depending on the mode. A plain ChatGPT conversation is a large language model answering in one pass. ChatGPT agent, documented in its system card of 2025-07-17, is the agentic mode: the same model family given a remote visual browser, a terminal with limited network access, and connectors to external data sources. Anthropic's test is the cleanest one to apply, since it defines agents as systems where LLMs dynamically direct their own processes and tool usage.
Do multi-agent systems actually outperform single agents on benchmarks?
The pattern in the evidence matters more than any single number: the strongest pro-multi-agent results come from vendors measuring themselves, and the strongest anti-multi-agent results come from independent academics measuring everyone. Anthropic reports a 90.2% relative improvement over single-agent Claude Opus 4 on an internal, non-public eval that was not compute-matched, and reports in the same post that token usage alone explains 80% of performance variance. The MAST study of multi-agent failures (arXiv:2503.13657, v3 2025-10-26) finds that performance gains on popular benchmarks are often minimal. A study of multi-agent debate (arXiv:2311.17371, v3 2024-07-18) finds those systems do not reliably outperform simpler strategies such as self-consistency, although it also finds that with hyperparameter tuning several debate systems perform better and can surpass every non-debate protocol it evaluated.
Three takeaways before you close this tab
- Default to single-agent. Multi-agent is a tool with a real cost.
- Multi-agent helps when context overflows, role specialisation pays, or parallel decomposition is clean. Otherwise it loses.
- Coordination cost compounds across tokens, latency, failure modes, and test surface. Plan for 3-5x.
Sources
- Anthropic, "Building Effective Agents", retrieved 2026-05-07, anthropic.com/engineering/building-effective-agents
- Mialon et al., "GAIA: A Benchmark for General AI Assistants", arXiv:2311.12983, 2023, retrieved 2026-05-07, arxiv.org/abs/2311.12983
- SWE-bench, "Leaderboard", retrieved 2026-05-07, swebench.com
- Walden Yan, Cognition, "Don't Build Multi-Agents", 2025-06-12, retrieved 2026-09-19, cognition.com/blog/dont-build-multi-agents
- Walden Yan, Cognition, "Multi-Agents: What's Actually Working", 2026-04-22, retrieved 2026-09-19, cognition.com/blog/multi-agents-working
- The Cognition Team, "Devin Fusion", 2026-06-29, retrieved 2026-09-19, cognition.com/blog/devin-fusion
- Anthropic, "How we built our multi-agent research system", 2025-06-13, retrieved 2026-09-19, anthropic.com/engineering/multi-agent-research-system
- Anthropic, "Subagents", Claude Code documentation, retrieved 2026-09-19, code.claude.com/docs/en/sub-agents
- Microsoft, Azure Architecture Center, "AI Agent Orchestration Patterns", updated 2026-05-12, retrieved 2026-09-19
- Microsoft, "Magentic-One", arXiv:2411.04468, submitted 2024-11-07, arxiv.org/abs/2411.04468
- "Why Do Multi-Agent LLM Systems Fail?", arXiv:2503.13657, submitted 2025-03-17, v3 2025-10-26, arxiv.org/abs/2503.13657
- "Should we be going MAD?", arXiv:2311.17371, submitted 2023-11-29, v3 2024-07-18, arxiv.org/abs/2311.17371
- Sapkota, Roumeliotis and Karkee, arXiv:2505.10468, submitted 2025-05-15, revised 2025-09-30, arxiv.org/abs/2505.10468
- "1-2-3 Check", arXiv:2508.07667, submitted 2025-08-11, v3 2026-02-25, Appendix E, Table 4, arxiv.org/abs/2508.07667
- MetaGPT, arXiv:2308.00352, submitted 2023-08-01, v7 2024-11-01, arxiv.org/abs/2308.00352
- OpenAI, "ChatGPT Agent System Card", 2025-07-17, retrieved 2026-09-19
- OpenAI, "Handoffs", Agents SDK documentation, retrieved 2026-09-19, openai.github.io/openai-agents-python/handoffs
- GitHub, "GitHub Copilot coding agent" changelog, 2025-05-19, retrieved 2026-09-19
- Google, "A2A: a new era of agent interoperability", 2025-04-09, retrieved 2026-09-19, developers.googleblog.com
- Microsoft AutoGen documentation, CrewAI documentation, LangChain documentation, AWS "What is agentic AI", IBM "AI agents", "Agentic AI" and "Multi-agent systems", all retrieved 2026-09-19
- Gravity team, "Gravity multi-agent decision spec", internal v1, May 2026, About