How Many AI Agents Can One Person Run?

The number every staffing committee reaches for is fixed: four, twelve, twenty. The one that actually matters depends on a variable nobody puts on the slide.

Carlos Andrés Ramírez · 2026-09-24

Every committee that staffs an agent team asks the same question: how many agents can one person run? The number that circulates is fixed, four, twelve, twenty. The one that actually matters depends on a variable nobody puts on the slide: how deterministic the work each agent does really is.

Greg Meyer, who studies how these teams get built, tells the case that sums up the whole problem. A company staffed one operator for twelve agents, back when the work was predictable: clear instructions, output you could check in seconds. The work drifted into ambiguity over time, and that same operator now barely holds four. The org chart still says twelve. Source: Greg Meyer, gregmeyer.com, June 2026.

Tomasz Tunguz, an investor who runs agents daily for his own work, lands on the same number from a different direction: he says he can barely manage four AI agents at once, and blames constant interruption. Every agent that asks for permission, raises a question or hands back something half finished demands attention the moment it happens, not when it suits him to look. Source: Tomasz Tunguz, tomtunguz.com, 2026.

At the other end, the most practiced operators hold ten to fifteen agents at once, because the work handed to them is different: well defined tasks, no ambiguity, reviewed in batches once they finish instead of one at a time. The full range, four to fifteen, has nothing to do with how skilled the operator is. It comes down to how deterministic the task in front of them is.

The symptom

The staffing ratio gets set once and never gets checked again.

It shows up before the whole team falls behind. Someone worked out how many agents the team needed the same way you would size a software license: one fixed number per person, baked into the year's budget. The math got done against the first use case, the simplest one, the one that looked clean in the demo. Eight months later the team is running five different processes on that same ratio, and nobody has gone back to measure what one person can actually hold on process number five, the messiest of the lot.

• The agents-per-person ratio got set once, against the simplest case, and never got recalculated against the real work.
• Nobody counts how many times an hour an agent stops to ask for permission or handle an exception; only how many agents are running gets counted.
• The operator who used to hold ten deterministic tasks is now juggling four ambiguous ones, and on paper still shows the same workload.
• Ambiguity creeps in slowly: month one the process is simple, by month six it carries seven undocumented exceptions.
• When an operator starts missing things, the first question is whether they need more training, never how many agents they are being asked to hold at once.

The problem underneath

The ceiling isn't set by the operator. It's set by how deterministic the task is.

An agent that does the same thing every time, with a clear input and an output checkable in seconds, barely interrupts: it does the work, hands it over, and review is a glance. An agent working in ambiguous territory, where "done" has no single definition, interrupts constantly: it asks for permission on the edge case, checks how to read an instruction, hands back something that needs careful review because it can be wrong in a way that doesn't show at a glance. The gap between holding fifteen and holding four isn't about the operator. It's about how many times an hour each agent needs something from them.

And this shifts over time, not just between different processes. The same agent, on the same process, gets more ambiguous as the business feeds it cases that were not in the original design: a new exception, a customer that does not fit any category, a rule that changed and nobody updated. The interruption rate climbs without anyone measuring it, and the operator who held ten agents three months ago now holds six without the change ever getting written down anywhere. By the time someone notices, they have been the team's bottleneck for weeks, not the multiplier they were supposed to be.

The number that matters isn't how many agents the team has. It's how many the person can hold before becoming the bottleneck themselves. And that number moves every week, whether or not the org chart notices.

BECOME

The framework

Three numbers before you set how many agents one person runs.

Interruption rate

How many times an hour a typical agent in that process needs something from the operator: permission on an edge case, an ambiguous call, a correction. Measured by watching one real week, not by guessing from memory how often it interrupts.

Review cost

How long it takes to check that what the agent handed back is actually right, not just that it finished. An agent that delivers fast but demands a long review does not free up time. It just moves the cost to another part of the day.

Real attention block

How many hours of uninterrupted focus that person actually has to spend supervising, not the full eight hours of the working day. Between meetings, other responsibilities and the rest of the job, it is rarely more than two or three.

Real ceiling

The result of dividing the available attention block by what each agent consumes, interruption plus review combined. It is not a number set once. It gets recalculated every time the process changes shape.

With these three numbers, an operator staffed for a deterministic process can comfortably hold ten or fifteen agents. The same operator, moving the same kind of work onto an ambiguous process, might need to drop to four without that meaning they lost any capability. They lost the ground where that higher ratio was possible.

Take whoever on your team currently runs the most agents and count, over one real week, how many times each agent asked them for something: permission, a decision, a correction. If nobody has ever counted that, the number alone explains why the staffing plan that looked fine in the demo does not hold up in production.

Let's size your agent team