Every few months a new framework makes multi-agent AI look like the obvious next step. You draw a planner, a researcher, a writer and a reviewer on a whiteboard, give each a role, and the diagram looks like a well-run team. Then the system ships, the token bill arrives, and debugging a wrong answer means reading four transcripts instead of one.
Our view is simple: a single agent is the right default, and a multi-agent design is an optimisation you earn with evidence. There are real cases where splitting the work wins clearly. They are narrower than the marketing suggests, and they share a recognisable shape. This guide is for founders, CTOs and product leads who are about to fund an agent build and need to decide which architecture to pay for.
What each architecture actually is
A single agent is one model running in a loop. It reads the task, calls a tool (search, a database query, an API), reads the result, and decides what to do next. Everything it has seen lives in one conversation history. Anthropic's Building Effective Agents guide describes agents in these terms: models using tools based on feedback from their environment, in a loop.
A multi-agent system splits the work across several model instances. The common pattern is an orchestrator that plans and delegates, plus worker agents that each take a subtask in a fresh context and return a result. The same Anthropic guide calls this the orchestrator-workers pattern and notes that the key difference from simple parallel calls is that the subtasks are not predefined: the orchestrator decides them based on the input.
That distinction matters for buyers. If you can write the subtasks down in advance, you probably do not need a multi-agent system at all. You need a workflow: fixed code that calls a model at defined steps. Workflows are cheaper, easier to test and easier to explain to a compliance team.
What the evidence says
Two credible sources, published a day apart in June 2025, are still the best starting point because they come from teams that built and ran these systems in production.
The case for: breadth-first research
Anthropic's engineering write-up on how it built its multi-agent research system reports that a setup with Claude Opus 4 as lead agent and Claude Sonnet 4 subagents outperformed a single Claude Opus 4 agent by 90.2% on its internal research evaluation. The task type is the important part: research questions that branch into many independent directions, where subagents can search in parallel and compress what they find before handing it back.
The same post explains why. On the BrowseComp benchmark, token usage alone explained 80% of the variance in performance, and token usage, number of tool calls and model choice together explained 95%. Multi-agent systems work partly because they let you spend more tokens on a problem than one context window allows. That is a capability, and it is also a bill.
The case against: shared context and conflicting decisions
Cognition, the company behind the Devin coding agent, published Don't Build Multi-Agents by Walden Yan. Its two principles are worth putting on the wall of any team building agents: share context, and share full agent traces rather than individual messages; and actions carry implicit decisions, and conflicting decisions carry bad results.
Their example is a request to build a Flappy Bird clone, split into a background subtask and a bird subtask. One subagent builds a background that looks like Super Mario Bros; the other builds a bird that neither looks nor moves like the original. The final agent is left to merge two misunderstandings. Each subagent did something reasonable on its own. Together, they made decisions the other could not see.
Anthropic's own post agrees on the limits. It names most coding tasks, domains where all agents need the same context, and work with many dependencies between agents as poor fits for multi-agent designs today.
The failure data
Academic work points the same way. Why Do Multi-Agent LLM Systems Fail?, from a team including researchers at UC Berkeley, opens by noting that the performance gains of multi-agent systems on popular benchmarks are often minimal. The authors built a dataset of more than 1,600 annotated traces across 7 popular frameworks and identified 14 failure modes in three categories: system design issues, inter-agent misalignment, and task verification. Two of those three categories are about agents coordinating and checking each other, not about any single model being weak.
The decision matrix
Use this table when scoping a build. If most of your answers fall in the left column, start single-agent. If several fall clearly in the right column, a multi-agent design is worth prototyping against a single-agent baseline.
| Question | Points to a single agent | Points to multi-agent |
|---|---|---|
| Can the work be split into pieces that do not depend on each other? | No, each step builds on the last | Yes, many independent threads |
| Does every step need the full history to act correctly? | Yes | No, workers need only a brief |
| Does the task overflow one context window? | Rarely | Often, even with summarisation |
| Would parallel execution cut latency meaningfully? | No, it is mostly serial | Yes, wall-clock time matters |
| Do steps need different permissions or data access? | No, one tool set is fine | Yes, isolation reduces risk |
| Is value per task high enough to absorb several times the token cost? | No, high volume and low margin | Yes, each answer is worth a lot |
| Do you have a test set to prove the split helps? | Not yet | Yes, with a baseline to beat |
Two of these rows deserve more attention than they usually get.
Permissions are an underrated reason to split. If one part of a workflow reads untrusted input (customer emails, uploaded files, web pages) and another part can write to your systems, keeping them in separate agents with separate tools limits what a prompt injection in the first can do through the second. That is a security argument, not a performance one, and it can justify a split even when the task is small.
The test set row is the one teams skip. Without a fixed set of real cases and a way to score outputs, you cannot tell whether the multi-agent version is better or just more expensive. If you have not built that yet, building it is the first deliverable regardless of architecture.
Working on something like this? See our Claude Agent Development →
What it costs: worked numbers
Anthropic's research post gives the multipliers that matter for budgeting: agents typically use about 4 times the tokens of a chat interaction, and its multi-agent system used about 15 times. That implies a multi-agent run uses very roughly 3 to 4 times the tokens of a comparable single-agent run. Your ratio will differ, but it is a sensible planning assumption until you measure your own.
Here is illustrative arithmetic using Anthropic's published API prices as of November 2026. The token volumes are assumptions for a mid-sized task, not measurements from a real system.
| Setup | Assumed tokens per run | Cost per run | Cost at 10,000 runs a month |
|---|---|---|---|
| Single agent on Claude Sonnet 5.5 ($2 in / $10 out per million) | 50k in, 3k out | about $0.13 | about $1,300 |
| Multi-agent, all on Sonnet 5.5, 3.75x the tokens | 187.5k in, 11.25k out | about $0.49 | about $4,900 |
| Orchestrator on Claude Opus 5.5 ($4 / $20), three workers on Claude Haiku 5.5 ($0.10 / $0.50) | Orchestrator 40k in, 4k out; each worker 50k in, 3k out | about $0.26 | about $2,600 |
Three things stand out.
- The naive split is expensive. Running every agent on the same mid-tier model nearly quadruples the bill in this example, before you count retries.
- Routing is where multi-agent designs can save money. Workers doing narrow extraction or search often do not need a frontier model. In the third row, the strong model only plans and synthesises, and the run costs about double the single-agent baseline while using a more capable model at the top. Whether the cheaper workers are accurate enough is an empirical question for your test set.
- Discounts apply to both. Anthropic lists a 50% discount for its Batch API and much cheaper cache reads. Work that does not need an instant answer, such as overnight document review, can use batching, and stable system prompts benefit from caching in either architecture.
Tokens are rarely the biggest cost line in an agent project. Engineering time on integration, evaluation and monitoring usually is. We broke that down for one concrete case in what an AI claims intake agent costs to build and run. The architecture choice affects build cost too: a multi-agent system has more prompts to maintain, more hand-offs to test and more traces to read when something goes wrong.
Patterns that work in business software
Most useful designs fall somewhere between the two extremes. These are the patterns worth knowing, from least to most complex.
1. One agent, good tools
One agent with a small number of well-designed tools, clear instructions and summarisation for long sessions. This covers most customer support, internal knowledge assistants, document Q&A and data-entry automation. If you are processing invoices, contracts or claims forms, a single agent wrapped in a deterministic workflow is usually enough.
2. Workflow with model calls at fixed steps
Classification, then extraction, then validation, then a write to your system. Each step may call a model, but code decides the order. This is technically not an agent at all, and that is a compliment. It is the easiest design to audit.
3. Single agent with read-only helpers
The main agent keeps all decision-making but can spawn helpers that only search or read and then return a compressed summary. Because helpers never take actions, they cannot make conflicting decisions; they only gather. This captures much of the context benefit of multi-agent designs with far less coordination risk, and it fits Cognition's principle that actions carry implicit decisions.
4. Orchestrator and parallel workers
The full pattern: a lead agent plans, writes detailed briefs, dispatches workers in parallel, and synthesises. It suits due-diligence research, competitive analysis, large codebase audits and multi-source report generation. It needs the most engineering: brief templates, limits on how many workers can spawn, a verification step before synthesis, and tracing across every agent.
5. Separate agents for separate trust zones
An agent that handles untrusted input passes structured, validated data to a second agent that holds write access. The split is about security boundaries, and it is often the most defensible reason to run more than one agent in a regulated product.
How to decide in practice: a five-step process
- Write down the task as a human would do it. List the steps and mark which depend on earlier decisions. If almost everything is sequential, stop here and build one agent or a workflow.
- Build a test set before the agent. Collect 50 to 200 real cases with known good outcomes. Decide how you will score correctness, cost and latency.
- Ship the single-agent baseline. Treat it as a proof of concept with a pass mark, the way an AI proof of concept should be scoped. Instrument it properly: full traces, token counts per step, tool errors. Run it against the test set.
- Find the bottleneck in the data. Is it context overflow on long cases? Serial steps that make users wait? A security boundary you cannot enforce in one agent? Each points to a specific split, not to a general multi-agent rewrite.
- Split one step and compare. Add subagents only where the bottleneck is, rerun the same test set, and compare accuracy, cost per run and latency against the baseline. Keep the split only if it wins on the metric you care about by a margin that justifies the extra cost.
This process is slower in week one and faster by month three. A team that starts with a six-agent diagram risks spending its second month removing agents.
Questions to ask a vendor proposing multi-agent
If an agency or internal team proposes a multi-agent architecture, these questions separate considered designs from fashionable ones:
- Which subtasks run in parallel, and what does each worker receive as context?
- What happens when two workers return conflicting results?
- What is the expected token cost per run, and what single-agent baseline is it compared against?
- Which models run in which roles, and why?
- How will we trace a wrong answer back to the agent and step that caused it?
- What is the cap on agent spawning and retries, so a bad input cannot run up an unbounded bill?
A good answer to each is specific and measured. "The agents collaborate like a team" is not an answer to any of them.
Our recommendation
Default to one agent, or to a plain workflow if the steps are known in advance. Treat multi-agent orchestration as a targeted fix for three specific problems: work that is genuinely parallel, context that will not fit, and permissions that should not mix. When you do split, put a strong model where judgement happens, cheaper models where the work is narrow, and a verification step before anything reaches a user or a system of record.
If you are scoping an agent and want a second opinion on the architecture before you fund the build, Northell's AI development team designs and builds agents and the product interfaces around them, starting from the baseline and the test set rather than the diagram. You can tell us what you are building and we will tell you honestly whether it needs more than one agent.
