How Many AI Agents Do You Need: When a Fleet Beats One

Andrew Maryasov, AI consultant, founder of Auspex and Grow2.ai. The rule “collapse a chain of twelve agents into one with a strong eval” holds exactly as long as the eval’s job is to verify an answer. Where it can rank many candidates and the right answer isn’t known in advance, a fleet of agents reaches a better solution faster than a single one. The condition here isn’t “how many agents can you launch” but “does an automatic verdict exist.” Below: what exactly NVIDIA measured, why the second half of the same result says the opposite, and the three conditions under which any of this carries over to business processes.

Eight

The number this paper gets cited for is eight. In the ENPIRE project (NVIDIA, CMU, UC Berkeley, June 2026), larger numbers of agents — on the order of eight in Import AI’s recap — arrive at higher-scoring solutions sooner, and sometimes the multi-agent setup yields a higher absolute score than the single-agent one. The recap presents the reason as likely, not established: broader exploration of the solution space.

The number is the least interesting part. A fleet is possible in ENPIRE only because the system already has an automatic “worked / didn’t work” verdict; without it, eight agents produce eight texts that someone has to read. What’s more, the same paper contains a result that points the other way: as the number of robots grows, average robot utilization drops, because the agent reads logs, writes code and waits on the model while expensive hardware sits idle. Three conditions carry over to business from this: the result is verified automatically, the environment resets without consequences, and the solution space is genuinely wide. Most company processes fail the first two.

The rule everyone is repeating right now

The wording comes in different versions, but the gist is the same: if you can write an end-to-end eval for a task (a set of examples with correct answers plus a script that scores them with no human involved), collapse the chain of five or twelve agents into one with a well-tuned prompt.

It’s put most crisply in the AI-Native Playbook (section 3.4, by Gerstep): “The multi-agent chain is a human coping mechanism for complexity, not an answer to it.” In other words, teams split a task into agents not because the task requires it but because they can’t hold the complexity of a single prompt in their heads. The eval holds it for them.

The arguments behind the rule are strong, and I’m not disputing them. Coordination overhead in multi-agent systems eats a large share of the tokens: context gets serialized into JSON, sent across at every handoff and parsed again on the other side. Most corporate processes are monotonous, ordered and predictable, with no adaptive decisions at all — they don’t need a multi-agent architecture in the first place.

I’ve written myself that failures in a multi-agent system happen at the seams between agents, not inside them, and every new agent is a new seam.

The arguments are fine. The trouble is that the rule is almost always quoted without the precondition that makes it true.

What exactly ENPIRE showed

On 18 June 2026, researchers from NVIDIA, Carnegie Mellon University and Berkeley posted the ENPIRE preprint — a harness that gives coding agents a closed loop for training real-robot policies.

I’ve already written about one of its modules separately. Environment does two boring things — it automatically resets the scene and automatically checks the result — and without it none of the three “smart” modules works. Back then, that was the part I cared about: until a task becomes self-resetting and self-verifying, the agent has nothing to learn from.

Now I’m interested in the other half of the same paper — the one about the number of agents.

The authors put it this way in the abstract on the project page: “ENPIRE can be significantly accelerated on a robot fleet,” and they propose two metrics — Mean Robot Utilization (MRU) and Mean Token Utilization (MTU) — to measure the efficiency of multi-agent physical autoresearch. Not the number of agents. Utilization.

Jack Clark, in Import AI 463 (29 June 2026), sums up the result like this: there are compelling returns to scaling agents; larger numbers of them — eight, for example — arrive at higher-scoring solutions sooner than others, and sometimes a multi-agent setup yields a higher absolute score than a single-agent one, likely because it explores more of the potential solution space.

Two caveats, without which the number is easy to overstate. “E.g., 8” is the recap’s wording, not a threshold from the paper; the public summary gives no returns curve, so “eight” is best read as an order of magnitude, not a setting. And “sometimes” carries weight here: a higher absolute score in the multi-agent setup happens; it isn’t guaranteed.

Here’s how the fleet is set up. The project page has a diagram of the search as a git tree of hypotheses: one branch per agent, one dot per idea tried. A green ring marks an idea that raised the team’s average success rate, and green curves mark ideas carried over between agents.

So this isn’t a fan-out with voting: the agents run parallel branches, peek at each other’s work and are ranked by one shared number that a machine computes, instead of having their conclusions averaged.

Why this marks the rule’s limit rather than refuting it

The “one agent with a strong eval” rule quietly assumes that the right answer is essentially fixed and the work is to carry it out carefully: draw up a document, post a transaction, go through the ordered steps of a procedure. In a task like that, the eval is an inspector at the end of the line who says “correct” or “incorrect” about a single result. A second agent adds no new answer here; it adds one more seam where things can fall out of sync.

ENPIRE tackles the opposite kind of task. Nobody knows in advance which algorithm will teach a robot to fasten a zip tie — not the researcher, not the agent. The work isn’t to carry out a known answer but to find it. Here the eval stops being an inspector and becomes a tournament judge: it compares many candidates and puts them in order.

That promotion has a price, and it’s worth naming right away. As soon as the eval becomes the judge that candidates are ranked by, it turns into a target: optimizing the score is always cheaper than optimizing the outcome. ENPIRE closed this off bluntly — the prompt says in so many words that modifying the environment code is not allowed, that it’s cheating. I broke down the mechanics separately in the piece on reward hacking and four defenses; when you go from one agent to eight, the risk doesn’t stay the same — it gets multiplied by the number of branches.

Hence a distinction I now consider more accurate than the original rule:

Whether an automatic eval exists determines whether a fleet is possible. The width of the solution space determines whether it’s needed.

Without an eval a fleet is impossible — not because it’s expensive, but because eight parallel results with no automatic verdict turn into eight texts for a human to read. At that point the human is the eval, and the number of agents is capped by that person’s attention.

With a narrow solution space a fleet isn’t needed — even with a perfect eval. If there’s one answer, eight agents will find the same answer eight times.

The second half of the result: hardware sits idle while the agent thinks

The same paper contains a result that rarely gets quoted alongside the “eight agents.” The authors say it plainly in the limitations section of the project page:

Coding agents do not fully utilize robot resources when they are reading logs, writing code, debugging, or waiting for the language-model backbone. As the number of robots scales, MRU decreases while GPU active utilization increases.

The expensive, scarce thing here is the robot. It’s physical; you can’t spin up eight more with a terminal command. The agent, by contrast, is cheap and parallel. When you add robots, the bottleneck moves from the physical layer to the thinking layer: a station with a pair of manipulators, cameras and its own RTX 5090 stands waiting while the agent finishes reading the logs and gets a response from the model.

That’s exactly why the authors proposed MRU and MTU. The fleet metric is this: what share of the scarce resource is actually working. The number of agents launched doesn’t answer that question.

That’s also why the result doesn’t read as an ad for fleets: in the very paper where more agents give a better score, growing the number of robots makes hardware utilization worse at the same time. The two scaling axes pull in different directions, and usually only one gets quoted.

Three conditions under which this carries over to business

ENPIRE is about robot policies improving themselves through the work of coding agents. Your contract approval process is a different task, and carrying the result over directly would be a sleight of hand. The transfer is valid only when your task reproduces three properties of the ENPIRE environment.

First: the result is verified automatically. Not “the manager will take a look” — a machine assigns a zero or a one with no human in the loop. In ENPIRE that’s a detector and a segmentation model that answer the same question independently from two cameras. In your case it could be tests, a comparison against a reference set, a schema check. If a human delivers the verdict, the condition isn’t met and you can stop reading here.

Second: the environment resets without consequences. An attempt can be repeated from a clean slate, and a failed attempt costs nobody anything. The robot puts the zip tie back. A client the agent has already emailed doesn’t reset. This is exactly where most business processes are irreversible, and it’s the main reason nobody runs parallel search on them.

Third: the solution space is genuinely wide. There are many independent ways to do the work, and you don’t know in advance which is best. If there’s one way and it’s written down in a procedure, you need a reliable executor, not a search.

Three out of three — you can think about a fleet. Two out of three — you can’t, and the one that fails most often is the second.

Where a fleet is legitimate in an ordinary company

Areas where all three conditions hold do exist; there are just fewer of them than the announcements suggest.

Code with tests is the canonical case: the test run delivers the verdict, rollback is free, and there are many ways to implement the thing. Data extraction from documents, when you have a labeled reference set of a hundred samples: eight extractor variants get ranked automatically by accuracy on that set.

The closest analog to what ENPIRE does is searching for the agent’s instructions themselves. You freeze an eval set, generate eight variants of a prompt or skill, run each against the set and take the one that scored best. It’s exactly the same construction: parallel branches, a shared number, ranking instead of averaging. And it’s available to any company that has managed to collect fifty examples with correct answers.

But “eight agents write your sales proposals” doesn’t belong on this list. No automatic verdict exists that can tell the better proposal from the worse one before it goes to the client. You’ll get eight documents and a person reading them.

One interpretation trap deserves its own mention. The eight agents’ win in ENPIRE is measured as time to a better solution in exploratory search, not as throughput on routine work. If your task is to process a queue of two hundred identical requests, you’re scaling throughput, and that’s a completely different mechanism. Confusing “found it faster” with “got it done faster” is the most expensive mistake you can make when reading results like these.

Supervision ratios still apply

My rule of thumb hasn’t changed because of this paper, and a rule of thumb is exactly what it is, not a measurement: around ten to twenty agents per supervisor where the cost of an error is low, a few where it’s medium, and just one or two where it’s financial, medical or legal. The numbers come from how many results one person can read in a working day, and on your team they’ll be different.

This is easy to check in my own shop. I have seventeen agents in Paperclip, and there isn’t a single parallel branch among them — they all work sequentially. The reason isn’t budget: I keep the daily LLM ceiling at around fifteen dollars and have never once hit it. The reason is that I deliver the final verdict on the text, and eight variants going in would mean eight texts to read coming out. There is a machine check in the loop, but it looks at fields and file structure, not quality — you can’t rank candidates by it. Exactly the situation the rule describes: an eval that verifies, not an eval that ranks.

Now it’s clear why the supervision ratios are what they are. They describe environments where there’s no automatic eval and the human is the eval. When a human delivers the verdict, the number of agents is capped by that person’s attention, and budget and infrastructure have nothing to do with it. The higher the stakes, the more closely you have to look, and the fewer agents fit in one head.

The stakes here are measured not by gut feeling but by the amount of damage and the time to roll back. Eight agents in a sandbox with tests and eight agents with access to the production database are one row on the dashboard and two different supervision ratios.

The rule “don’t pile on more agents” describes a world with no automatic verdict. For most companies that is their world — which is why the rule remains a sensible default, not a mistake.

How the rule sounds with its precondition

The original wording should be extended to this:

Collapse a chain of agents into one where the answer is essentially fixed and the eval verifies the result. Deploy a fleet where the answer has to be found and the eval can rank candidates without a human. If there’s no automatic eval, do neither; build the eval first.

The practical sequence before adding agents:

1. Ask whether a machine verdict exists for this task. If not, go no further; the rest of the discussion is premature.
2. Ask whether the right answer is known in advance. If it is, you need one reliable executor.
3. Ask what in your process is the scarce resource, the way the robot is, and whether it will start sitting idle while the agents think.
4. Measure the utilization of that resource, not the number of agents launched.

The fourth item follows straight from MRU. The number of agents on a dashboard says nothing about whether the thing you’re paying for is working. And as with any agent metric, name the denominator first: “60% utilization” with no answer to “a percentage of what?” is just a number, not an indicator.

What this paper doesn’t prove

ENPIRE doesn’t prove that eight agents are better than one in general. The result was obtained on one class of tasks — searching for an algorithm to train a manipulation policy — in an environment with automatic reset and automatic verification.

The public recap gives no returns curve, so we don’t know where saturation begins or where the returns turn negative. The paper doesn’t measure business agents at all, not once.

Nor does it do away with coordination overhead — it sidesteps it with an architecture in which agents don’t pass work to each other down a chain but run independent branches with one shared number. The payoff comes from a shape in which the agents don’t get in each other’s way, not from how many of them there are. The same fleet of eight, assembled as a sequential pipeline, would give a completely different picture.

FAQ

How many AI agents does a business need?

As many as your oversight can check. If a human delivers the verdict on the quality of the work, the rule of thumb is ten or twenty agents per supervisor at low stakes, a few at medium stakes and just one or two in finance, medicine or law; the exact numbers depend on how many results your person can read. If the verdict is automatic, the ceiling rises, and the constraint becomes utilization of the scarce resource, not human attention.

When does a fleet of agents actually beat a single agent?

When three conditions hold at once: the result is verified by a machine without a human, an attempt can be repeated without consequences, and there are many independent ways to do the work. In ENPIRE all three hold, and that’s exactly where a larger number of agents reaches a better solution sooner.

Does this mean the “one agent with a strong eval” rule is wrong?

No. It’s right for tasks where the answer is essentially fixed and the eval verifies the result — which is most corporate processes. What’s wrong isn’t the rule but applying it without that precondition to search tasks, where the answer isn’t known in advance.

What are MRU and MTU in ENPIRE?

Mean Robot Utilization and Mean Token Utilization — two metrics the authors proposed for measuring the efficiency of multi-agent physical autoresearch. They measure what share of the scarce resource is actually working, not how many agents are running.

Why does growing the robot fleet make utilization worse?

Because the agent spends a large part of its time thinking instead of acting: reading logs, writing code, debugging, waiting for the model’s response. During that time the physical resource sits idle. The authors state it directly: as the number of robots grows, MRU drops. Note that this is about scaling robots, not agents — those are different axes, and the paper measures the decline along the first.

Can we scale agents if we have no automatic verification?

Technically yes; in practice it shifts the load onto a human. Eight parallel results with no machine verdict mean eight artifacts that someone will have to read. First you build the check, then you scale the count.

Where do I start if I want to try parallel search?

With the cheapest area where the verdict is already automatic. Collect fifty to a hundred examples with correct answers, generate several variants of the agent’s instructions, run each against the set and take the best by score. It’s the same construction as in ENPIRE, just without the robots.

What’s next

The most useful thing to take from this paper is the order of the questions: first the automatic verdict, then the width of the solution space, and only then the number of agents. The number “eight” isn’t needed on that list at all.

Companies usually go in the reverse order and run into the fact that the discussion about the number of agents was two steps premature.

If you’re deciding right now how many agents to launch, start with the question of who in your process assigns the zero or the one. If the answer is “a human,” you already know your ceiling, and it isn’t about agents.

Sources:

• ENPIRE: Agentic Robot Policy Self-Improvement in the Real World — preprint, arXiv:2606.19980, 18 June 2026 (NVIDIA, CMU, UC Berkeley)
• ENPIRE project page — abstract, the MRU/MTU metrics, the hypothesis tree
• Import AI 463 — Jack Clark, 29 June 2026, a recap of the result on scaling agents
• AI-Native Playbook, 3.4 Making Agents Reliable — Gerstep, the wording of the rule about collapsing the chain

Published by Andrew Maryasov, AI consultant, founder of Auspex and Grow2.ai; implementations are run by Auspex (CRM) and Grow2.ai (AI agents).