Two agents are not twice as good as one. On some jobs they are far worse.
In January 2026, Google Research put 180 agent setups through the same set of tests. On one kind of task, every single multi-agent design it tried lost to one agent working alone. On another kind, a team beat the lone agent by a wide margin. The deciding factor was not the model, and it was not the number of agents. It was the shape of the work.
The short answer: Use one agent when the steps have to happen in a fixed order. Use a team when parts of the job can run side by side. If you do use a team, give one agent the job of checking the others. In Google's tests that one change cut how far a single mistake spread, from 17.2 times its original size down to 4.4 times.
What Is a Multi-Agent System?
A multi-agent system is two or more AI agents that split one job between them and pass work to each other.
An agent here means an AI program that can take actions by itself. Not just write text. It can look something up, open a file, call another piece of software, then decide what to do with what it got back.
A single agent system is exactly what it sounds like. One agent, start to finish, holding the whole job in its head.
The useful thing to know is that the second one is not simply a weaker version of the first. They fail in completely different ways, which is why the choice matters more than most teams expect.
The One Question That Decides It
Ask this before anything else: can two agents work on this job at the same time without waiting for each other?
If the answer is yes, a team will probably help. Pulling numbers out of forty separate documents is that kind of work. Nobody has to go first.
If the answer is no, one agent will usually win. Booking a trip is that kind of work. You cannot pick the hotel before you know the dates, and you cannot know the dates until the flights are settled. Handing those steps to different agents just adds queues and handovers to something that was always going to be a single line.
That is the whole rule. Most of the trouble people run into comes from skipping it.
What Google Found Across 180 Agent Setups
Google ran five designs against three families of AI model and four kinds of task. The published numbers are below.
Test | Outcome | Shape of the work |
|---|---|---|
Finance task, one lead agent with helpers | 80.9% better than a lone agent | Parts can run at the same time |
Planning task, all five multi-agent designs | 39% to 70% worse | Steps must follow each other |
Team with nobody reviewing output | A single error grew 17.2 times | Either |
Team with one agent reviewing output | A single error grew 4.4 times | Either |
A gap that wide from the same hardware and the same models is worth sitting with for a second. Nothing changed except how the work was divided.
Two limits are worth stating. This is one study, so treat it as strong evidence rather than settled law. And Google published hard numbers for two of its four task types, not all four.
Why One Small Mistake Turns Into a Big One
Errors in a team of agents do not stay the same size. They compound.
Picture the first agent getting a date slightly wrong. It hands that date on. The next agent builds a schedule around it, confident, because it has no way of knowing the date was invented. The third agent writes a summary of the schedule. By the end there is a tidy, well-written document that is entirely wrong, and no line in it looks suspicious.
The name for this is error amplification. Measured without any review step, Google saw one mistake end up more than seventeen times larger. Add one agent whose only job is to check what the others send back, and that fell to roughly four times.
This is the strongest practical finding in the whole study. If you take one thing from this article, take the reviewer.
The Five Designs, and When Each One Fits
Design | What happens | Use it when | The catch |
|---|---|---|---|
Single agent | One agent does everything | Steps must run in order, or the job is small | Gets slow and forgetful on long jobs |
Independent agents | Several run in parallel, nobody reviews | Never, really | Worst error growth of any design |
Lead agent | One agent assigns work and reviews it | Most real jobs | Everything funnels through one point |
Peer discussion | Agents argue it out as equals | You genuinely need competing views | Slow, talkative, expensive |
Hybrid | A lead agent plus some direct peer work | Large jobs with both shapes of work | Hardest to debug when it breaks |
Across the tests, the lead agent design gave the best trade between finishing the job and keeping errors small. Start there unless you have a specific reason not to.
Where Self-Hosted and Sovereign Setups Get Harder
Everything above holds whether you rent your AI or run it yourself. Running it yourself just removes the safety nets.
Sovereign AI means your organization controls the data, the model and the machines, and nothing has to leave your network. Plenty of people need that: hospitals, banks, defense, anyone under strict data rules. It costs you four things that normally paper over performance problems.
No extra machines on demand. A rented service quietly adds capacity when load spikes. You have the servers you bought.
Usually a smaller model. Open models you can host are genuinely good now, but the very largest ones are still only available as a service.
Tuning becomes your job. The speed of a hosted service is partly other people's engineering work. On your own stack, that work is yours.
Your own rules can block the usual fixes. Automatic retries and full logging hide a lot of agent failures. Some data rules forbid both.
Being straight about this: there is no independent published benchmark comparing self-hosted agent teams against hosted ones. Vendor speed claims are vendor numbers. Useful, but not measurements you can lean on.
Sovereign, Private, On-Premise: Quick Definitions
These four words get swapped around as if they mean the same thing, and that is how teams end up with less protection than they paid for.
Term | What you actually get | What it does not include |
|---|---|---|
Data residency | Storage in a country you chose | Protection from foreign legal reach |
Private | Nobody outside your company uses it | Control of the model or the hardware |
On-premise | It runs on machines you own | A guarantee it never phones home |
Air-gapped | No network connection at all | Easy patching or repair |
Sovereign | Control of data, model and hardware | Any promise about speed |
The first row is the one people get wrong. Choosing where data sits is not the same as controlling it.
Six Numbers Worth Watching
Count finished jobs, not tokens. Teams that measure volume end up optimizing volume, which is why so many agent systems get busier without getting better.
Measure | Why it matters |
|---|---|
Task completion rate | Whether the thing actually gets done |
Error amplification | How much one wrong step grows by the end |
Time to first output | How long a person sits watching nothing |
End to end time | How long the full job takes |
Cost per completed job | What one genuine success costs |
Human intervention rate | How often someone has to step in |
The last two carry more weight than they look like they do. An agent that fails twice before succeeding is not cheap, however low the price per attempt. And if a person rescues most runs, you have a demo rather than a system.
A Checklist Before You Add Another Agent
Run through this list before the next agent goes in. It takes five minutes and saves weeks.
Can any two steps of this job run at the same time? If not, stop here.
Is there one agent whose job is checking the others' output? If not, add that before adding anything else.
Does each agent have only the tools its own part needs? Google found coordination costs climb faster than expected as tools pile up, using a coding agent with sixteen or more tools as its example.
Is there a hard cap on turns and spend, so nothing loops forever?
Do agents read from one shared set of notes instead of passing whole conversations around?
Could a smaller, cheaper model handle the sorting and labeling steps and free the big model for the thinking?
Do you have a fixed set of test tasks with known answers, so you can tell whether a change helped?
That last one is the most commonly skipped and the most expensive to skip. Tuning a system you have never measured is guessing with extra steps.
Mistakes People Make Most Often
Adding agents to a job whose steps have to happen in sequence.
Running a team with no reviewer, which is where errors grow fastest.
Giving every agent the full toolbox because it was easier than deciding.
Judging the system on output volume instead of completed tasks.
Assuming a benchmark run on hosted infrastructure predicts your own.
Treating data residency as if it meant data control.
Launching with no test set, then tuning on vibes.
How We Checked This
Every figure quoted here comes from Google Research's January 2026 study of 180 agent setups, linked above so you can read the original. The points about self-hosted systems being harder to tune come from vendor and practitioner write-ups rather than controlled tests, and we have said so in that section rather than dressing them up as data. Where a claim could not be confirmed, it was left out.
FAQs About Single Agent vs Multi Agent Systems?
What is the difference between single agent and multi-agent systems?
A single agent handles the whole job alone. A multi-agent system splits the job between several agents that pass work to each other, which helps when parts can run at the same time and hurts when they cannot.
When is one agent better than several?
Whenever the steps depend on each other. On Google's sequential planning task, every multi-agent design tested came in 39% to 70% worse than a lone agent.
What is error amplification?
It is a small mistake getting bigger as later agents build on it. Unchecked, Google measured growth of 17.2 times. With one agent reviewing output, 4.4 times.
Do multi-agent systems cost more to run?
Usually yes, because agents spend tokens talking to each other as well as doing the work. Judge it on cost per completed job rather than cost per call.
Does any of this change if I host the agents myself?
The rules do not change, but the margin for error shrinks. You cannot add machines on demand, you are usually on a smaller model, and the tuning is yours.
How many agents should I start with?
One. Add a second only when you can point at two parts of the job that genuinely run at the same time.
Wrapping Up
The honest answer to single agent vs multi-agent systems is that neither one wins in general. Match the design to the shape of the work. Keep sequential jobs with one agent. Split work that can run side by side. And whatever you build, put one agent in charge of checking the rest, because that is the change with the clearest measured payoff.
More agents is not a strategy. The right number of agents is.
Sources
research.google, Towards a Science of Scaling Agent Systems, January 2026. Every performance figure above comes from here.
The peer reviewed paper behind that write up is available on arXiv for anyone who wants the full method and the raw task set.