Single agent vs multi-agent comes down to the shape of the task. In Kim et al.'s controlled study of 260 configurations (April 2026), splitting work across agents raised mean success by up to 80.8% relative to one agent on a financial analysis benchmark whose parts could be worked separately. On a planning benchmark where each step depended on the last, it cut mean success by up to 70.0%. Averaged over all six benchmarks, the change was -0.3% [11].
Extra agents also cost more. A model developer reported in June 2025 that its multi-agent research system used about 15 times the tokens of a chat, against about 4 times for a single agent [22]. In three studies, one agent matched or beat multi-agent setups when it got strong prompts with demonstrations [3], the same thinking-token budget [12] or the same base model as the workflow's agents [13]. A fourth found optimized multi-agent designs about 6% ahead [10].
Practitioners who took opposite sides in 2025 now agree on helpers that gather information in parallel and on a separate checker [23, 26, 28]. Security and ownership boundaries can also require separate agents [16, 30].
Single agent vs multi-agent: the common patterns
A single-agent system has one reasoning loop, even when it calls tools or reviews its own work, and a multi-agent system has several model-backed agents that pass structured messages [11].
| Pattern | Other names | How it works |
|---|---|---|
| Orchestrator-workers | Manager, coordinator, centralized, supervisor | A lead agent splits the task, delegates the parts and combines the results [11, 18, 20, 21, 30] |
| Handoff | Decentralized, swarm | Peer agents pass control to each other [18, 20, 30] |
| Parallel | Sectioning, fan-out, map-reduce | Independent subtasks run at once, then merge [17, 21] |
| Generator-verifier | Evaluator-optimizer, maker-checker | One agent produces, another checks it against criteria [17, 21, 24] |
Where splitting helps
Splitting helps when the parts do not depend on each other. On the Finance Agent benchmark, revenue, cost and market factors can be analyzed separately, and every multi-agent architecture beat the single agent, by 57% to 80.8% relative [11].
A model developer also reported in June 2025 that a frontier lead model with smaller subagents beat the lead model alone by 90.2% on its internal research evaluation (vendor-reported), with gains on breadth-first queries [22]. In its analysis, token use alone explained 80% of the performance variance on the BrowseComp benchmark [22].
A fresh context helps when one context degrades. Across five models, performance fell by 13.9% to 85% as input length grew, even with perfect retrieval [9]. Under equal budgets, Tran and Kiela found a multi-agent pipeline pulled ahead only after the single agent's context was heavily degraded [12]. Overlapping tools have a similar effect: in an agent-framework maker's test, a single agent's score fell sharply once two or more distractor domains of 19 tools each were added [30].
Where splitting hurts
Splitting hurts when each step depends on the last. On PlanCraft, a crafting-plan benchmark, every multi-agent architecture lost to the single agent, by 39% to 70% relative. Traces show orchestrators breaking short sequential tasks into artificial subtasks and spending the token budget on coordination [11].
Parallel agents that write also collide. A coding-agent developer argued in June 2025 that "actions carry implicit decisions" and that parallel subagents act on "conflicting assumptions not prescribed upfront" [27]. In one experiment with planner, implementer, tester and reviewer agents, "the subagents spent more tokens on coordination than on actual work" [23].
Positions have moved. In April 2026 the coding-agent developer wrote that setups work where "writes stay single-threaded" [28]. In October 2026 the research-system developer reported that a single agent with skills often beat subagent designs in enterprise deployments [26].
Are multi-agent systems better than single agents?
Not on average. Once a single agent already scored above about 45%, Kim et al. found that added agents lowered performance, and the paper treats this ceiling as its robust result [11].
Better prompts close much of the gap. Wang et al. found that discussion beat a single agent only when the prompt had no demonstrations [3]. Gao et al. reran published comparisons with a newer model and saw the accuracy gain fall from 10% to 3% [14].
Zhou et al. disagree in part: optimized multi-agent building blocks beat an optimized single agent by about 6% on average [10].
What extra agents cost
Each source measures cost on its own basis, so the multiples do not combine.
| Source and date | Comparison | Figure |
|---|---|---|
| Model developer, June 2025 (vendor-reported) | Single agent and multi-agent system against chat | About 4x and 15x the tokens [22] |
| Model developer, January 2026 (vendor-reported) | Multi-agent against single agent on equivalent tasks | 3x to 10x the tokens [23] |
| Gao et al., May 2025 | Multi-agent against single agent, seven datasets | 4x to 220x input tokens [14] |
| Kim et al., April 2026 | Successes per 1,000 tokens at a matched budget | 67.7 for one agent, 13.6 to 42.4 for multi-agent designs [11] |
Running subagents in parallel, each calling tools in parallel, cut research time by up to 90% for complex queries in one developer's system (vendor-reported, June 2025) [22]. A customer of the same developer measured a single loop running about twice as fast as its multi-agent harness (vendor-reported, October 2026) [26]. The developer also warns that one subagent per team can leave "hundreds of overlapping subagents with no enforced standards and no specific owner" (October 2026) [26].
A separate checker
Kim et al. observed that independent agents amplified errors 17.2 times at the trace level, against 4.4 times when an orchestrator checked outputs before combining them. The effect loses statistical significance once other coordination measures are controlled [11].
A checker needs criteria. A verifier told only to check whether output is good "will rubber-stamp the generator's output" [24]. In the MAST study of multi-agent failures, systems with explicit verifiers showed fewer failures, yet many verifiers ran only superficial checks [8]. A coding-agent developer reported that a separate review agent caught an average of two bugs per pull request, about 58% of them severe, and worked better with no context shared with the coder (vendor-reported, April 2026) [28].
Debate is weaker evidence. Du et al. found that three agents debating for two rounds raised arithmetic accuracy from 67.0% to 81.8%, zero-shot [4]. With the same number of sampled answers, majority voting beat debate in a replication [5], and a NeurIPS 2025 study found that voting accounts for most of the gain credited to debate [7]. Agents with the same model, context and scaffolding also tend to make the same mistakes [25]. For citation checks, see how to check LLM citations against their sources.
Boundaries that justify separate agents
Some reasons sit outside the task. A cloud provider's adoption guide says to start with several agents when a use case crosses security and compliance boundaries, involves several teams or has planned growth. Its example, from financial services, is one agent preparing transactions while another validates them [16]. NIST's separation of duties and least privilege controls cover people and the processes acting for them [1], and the cloud guides apply the same ideas to agents [16, 17]. OWASP advises limiting each agent's tools and permissions, and lists a compromised peer agent as a trigger of excessive agency [2]. When another organization's agent does part of the work, one agent cannot do it all [19, 30].
A model developer offers a counterpoint: each tool can check what the calling user may see or do, so one loop can serve users with different access [26]. MCP access control covers the controls on each tool.
When to use a multi-agent system
| Situation | What the evidence shows | Starting design |
|---|---|---|
| Parts can be worked separately | Gains of 57% to 80.8% relative on Finance Agent [11] | Orchestrator with parallel workers |
| Each step depends on the last | Losses of 39% to 70% relative on PlanCraft [11] | One agent |
| One agent already scores above about 45% | Added agents lowered performance [11] | One agent with better prompts [3] |
| Long or misleading context | Length alone hurts, and splitting helps once degradation is heavy [9, 12] | Read-only helpers with their own context |
| Many overlapping tools or domains | Single agents fall off as domains are added [29, 30] | Clarify the tools first, then split by domain [20] |
| Output must meet explicit criteria | Checks help when the criteria are concrete [8, 24] | Generator plus verifier |
| Data isolation, separated duties, another party's agent | Required by policy or ownership [1, 16, 30] | Separate agents with least privilege |
Outside those boundaries, the guides share a first step: build one agent, test it and split only when tests show a limit it cannot pass [16, 18, 20, 26].
Rillor builds agentic systems for evidence-heavy work over large bodies of text and data. A planner splits each question into parts and gives each part to a specialist agent with only the tools that part needs, and an audit step checks every citation against the logged evidence before an answer goes out.
Read the full report
The full report adds Kim et al.'s results by architecture across all 260 configurations, a dated timeline of practitioner positions, each study's limits and all 30 sources.