Multi-Agent vs Single Agent: When Do Multiple AI Agents Make Sense?

Every new agent demo makes the same promise: "One agent researches, one writes, one checks, and you just watch." It sounds like hiring a small team. Is that what you get, or does putting three agents side by side mostly mean three times the bill?

This article looks at multi-agent vs single agent AI systems in decision-maker language: what a multi-agent system is, where it genuinely beats a single agent, where it is just added complexity, and what to ask when a proposal uses the phrase. It belongs to our series on AI infrastructure decisions for non-technical leaders; if the word "agent" is still fuzzy, the real setup story we wrote earlier is the better starting point.

Our position up front: in most "multi-agent" proposals we have reviewed, the second agent was built to solve a problem that a single tool added to the first agent would have solved. Below we explain why that keeps happening, and where the real exceptions begin.

What is a multi-agent system?

A multi-agent system is a setup where, instead of one large language model doing the entire job, several AI agents share it, each with its own role description, tool set and context window. The agents pass messages to each other; one usually acts as the manager or planner, and the others run sub-tasks and hand results back.

The definition is simple, but the word "agent" is used so loosely that a distinction is needed first. A single model that can search, query a database and draft an email is already an agent: one intelligence that uses tools and works step by step. A multi-agent system has several of those, and the whole question is about the communication between them.

Four patterns come up in practice:

• Orchestrator-worker: One agent plans, distributes sub-tasks to worker agents and collects the results. Anthropic's research assistant is built this way.
• Planner-executor: One agent only produces the "what to do" list; another carries it out item by item. Separating plan from action makes auditing easier.
• Handoff: Agent A takes the job to a certain point and passes it, with context, to agent B. This is the core idea in OpenAI's Agents SDK.
• Hierarchical: Manager agents above other manager agents. It appears in large enterprise workflows and is rarely needed at small-business scale.

None of these patterns means "a smarter model"; they all arrange the same models differently. That is the heart of the matter: organisation does not create intelligence on its own. It only lets existing intelligence be used better on certain kinds of work.

Is a multi-agent system actually better than a single agent?

Sometimes, and that "sometimes" has a price. In Anthropic's own research assistant, the orchestrator-worker setup scored about 90 percent better than a single agent in their internal evaluation, while burning roughly 15 times the tokens of an ordinary chat. In an independent comparison with an equal compute budget, a multi-agent design delivered only about 4 percent improvement at 4 times the cost.

The gap between those two numbers is not an accident. Anthropic measured a broad research task: reading dozens of sources at once, summarising each, then combining them. That work is naturally parallel. Three worker agents reading three sources simultaneously raise both speed and coverage. In Anthropic's own analysis, about 80 percent of the performance difference was explained by the amount of tokens used, which means the gain came from reading more, not from having more agents.

The equal-budget comparison was run on sequential reasoning tasks. There, the second agent has to wait for the first; no parallelism, only message traffic in between. Every message between agents is another model call. Cost and latency grow with headcount, and task difficulty is secondary. Those numbers rest on a single study, so treat them as direction rather than a precise ratio.

In mid-2025 the team at Cognition published a post titled "Don't build multi-agents." A year later they narrowed the position: reading work can be spread across parallel agents, writing work should stay on a single thread.

That distinction is, in our view, the most useful summary of the topic. Collecting reports, scanning sources, reviewing competitor websites: distributable. Writing one coherent contract, building a software module end to end, answering a customer in one voice: not distributable. Split the second kind across three agents and you get three sets of decisions, three styles, and contradictions at the merge step.

Why do multi-agent systems fail?

The MAST study from Berkeley, published in 2025, examined 1,642 real execution traces across seven popular frameworks and found failure rates between 41 and 87 percent depending on the framework. Roughly 44 percent of failures came from system design, 32 percent from inter-agent misalignment, and the remaining 23 percent from missing verification.

Set the percentages aside and look at the failure modes; they are more instructive. The most common ones:

• An agent repeating a step it had already done (in about 16 percent of traces).
• Not knowing when the job is finished; agents keep talking after the result is ready (12 percent).
• Stepping outside the role; an agent attempts work it was never assigned (12 percent).
• One agent passing incomplete information to another, or the other ignoring what it received.
• Nobody checking the result; a wrong output enters the system marked "complete."

Read that list carefully: none of it says "the model was not smart enough." All of it is organisational failure of the kind we see in human teams. Vague role descriptions, no finishing criteria, nobody verifying who did what. The difference is that in a human team someone says "wait, we already did this"; in an agent team, if nobody is built to say it, the bill keeps growing.

That is also why framework choice (LangGraph, CrewAI, Google ADK) matters less than most proposals suggest. The same study shows most problems are design and verification gaps independent of the framework. Switching frameworks does not fix a bad task definition.

When does a multi-agent system make sense?

A multi-agent system makes sense when the work splits into genuinely parallel parts, when it exceeds a single context window, when sub-tasks need different tool sets or different permission levels, and when the value of the job covers a 10 to 15 times token cost. If fewer than two of those four conditions hold, a single agent is very likely enough.

The conditions in a bit more detail:

• Parallel reading: Reviewing twelve supplier quotes at once, scanning fifty competitor product pages, extracting the impact of one regulatory change on six separate contracts. Each part is independent; results merge at the end.
• Context limits: A single model can only read so much at once. Summarising a thousand-page archive works better when each agent takes a section in its own window and returns a summary than when one agent reads in pieces and forgets.
• Permission separation: You do not want the agent with write access to the payment system to be the same intelligence that emails customers. Separate agent, separate permissions, separate audit trail. Here the second agent is a security control.
• High-value work: Legal due diligence, competitive intelligence, technical literature review. When the outcome shapes a six-figure decision, 15 times the tokens is still a small number in proportion.

One more: agents set up to critique each other (one drafts a proposal, the other only hunts for flaws) can produce more balanced output than a single agent. But that too is reading and reviewing work, not writing; the rule holds.

When is a single agent enough?

When steps depend on each other sequentially, when the job is producing one coherent text or piece of code, when the process needs frequent feedback from the user, or when margin per transaction is thin, a single agent is both cheaper and more reliable. One industry estimate puts about 70 percent of projects sold as "agentic" within reach of a single tool-using agent; that figure comes from a single consulting source, but it matches what we see.

The strength of a single agent lies in something that is routinely underrated: tools. Database queries, a calculator, web search, sending email, writing to the CRM. Connect those to one agent and it already behaves like four or five "specialists," without any coordination problem. Before building a second agent, the question to ask is: "Would adding a tool to the first agent solve this?" The answer is usually yes.

Customer service chatbots, order status lookups, invoice summaries, turning meeting notes into task lists all fall in this class. If a multi-agent architecture has been proposed for any of them, ask for the reasoning. With standard integration layers such as MCP, wiring tools into a single agent is no longer a large software project either.

A concrete scenario: an importer's two attempts

We watched a 30-person import company build a four-agent system for evaluating supplier quotes, then cut it back to one agent plus parallel readers. The second version ran at roughly a third of the cost per evaluation and produced noticeably fewer wrong rankings. The numbers are rounded, but the lesson is clear.

The first build looked sensible on paper: one agent read the quote files, a second normalised prices, a third compared delivery terms, a fourth wrote the report. The problem was that these four steps were sequential. The pricing agent depended on the reader's output; the report agent waited on all three. When one quote listed units as "pieces" instead of "cartons," the reader noted it, the pricing agent ignored the note, and the report agent ranked two suppliers the wrong way round. A textbook MAST failure: information handed over incompletely, nobody verifying.

The second build has one main agent with three tools: a file reader, a unit-conversion table and a report template. Parallelism survived in exactly one place: the twelve quote files are dispatched to twelve lightweight readers at once, each returning a structured summary. The main agent takes those summaries and prepares pricing, terms and the report on its own, in one context. Writing on a single thread; reading in parallel. The pattern Cognition described gave the same result in practice.

The purchasing manager's summary captures the article better than we could: "Four agents did not behave like four colleagues. They behaved like four interns who left each other notes and went home."

Six questions to ask when a proposal says "multi-agent"

If a vendor proposes a multi-agent architecture, these six questions test its soundness without going into technical detail. If the answers are vague, the architecture was most likely chosen for fashion rather than need.

1. Which sub-tasks run independently of each other? (If there is no parallelism, what justifies the second agent?)
2. How many agents do the writing? (If more than one, how is consistency guaranteed?)
3. Who verifies each agent's output, and against what criteria?
4. What is the finishing condition? How does the system know the job is done?
5. Was the same job tried with a single agent plus tools, and what was the result?
6. What is the average token cost per run, and what does it reach in the worst case?

Frequently asked questions

Is multi-agent the same as agentic AI?

No. "Agentic" describes a model using tools and working step by step toward a goal; a single agent can be agentic. A multi-agent system is several such agents working together. The two terms are often used interchangeably in marketing, so pin down which one a proposal means.

How much more expensive is a multi-agent system?

In Anthropic's own measurement, a research-type task used roughly 15 times the tokens of an ordinary chat. On sequential tasks the cost rises without the gain, because there is no parallelism. The exact multiplier depends on the job; if the proposal has no "estimated cost per run" line, ask for one.

Does a small business ever need multi-agent?

Rarely, but yes. Multi-source research, bulk document review and processes that need permission separation exist in small companies too. The need comes from the structure of the work, regardless of company size.

LangGraph, CrewAI, OpenAI Agents SDK or Google ADK?

For a decision maker this is the wrong question. The MAST study shows most failures are framework-independent. Your team's language skills and fit with your existing systems (for example Microsoft's Agent Framework if you live in that ecosystem) are sufficient criteria. Task definition and a verification layer matter far more.

Do errors drop if agents check each other?

One agent critiquing another's output can raise quality, especially in reports and proposals. But that "check" is itself a model call; it does not replace deterministic verification (schema checks, numeric consistency tests, human approval). Build both.

Can we start with one agent and move to several later?

Yes, and that is the recommended path. Go live with a single agent, measure where it struggles (context limit, runtime, permission separation), and add a second agent only when there is a measured gap.

So what should you actually do?

A multi-agent system earns its place only as the answer to a measured problem. Do not buy the answer before measuring the problem.

• Start with one agent plus tools. Add a second agent only when a measured gap (context limit, need for parallelism, permission separation) calls for it.
• Separate reading from writing. Source scanning, document reading and comparison can go to parallel agents; final text, decisions and records stay on one thread.
• Write down the finishing condition and the verification. If the proposal does not answer "when does the job count as done" and "who checks the output, with what," the system is not ready for production.
• Track cost per run. Put average and worst-case token spend on a dashboard from week one; more agents means more room for surprise bills.
• Skip the framework debate. With a sound task definition and verification layer the framework is secondary; without them, no framework will save you.

The industry tells the "agent team" story well; most companies actually need one well-equipped agent and a plain set of rules to supervise it. If you have a multi-agent proposal on your desk, walk through the six questions above with us; which agents are really necessary usually becomes obvious inside half an hour.