What breaks first when one person runs five agents instead of one?

The first agent is easy. You give it a job, you watch it work, and when it drifts you say “no, not like that.” It feels like collaboration, and it mostly is.

The fifth agent is a different job entirely, and the thing that breaks is rarely the one people brace for.

You were the error-correction layer

With a single agent, a large amount of quality control happens invisibly — through you, in real time. You notice the wrong assumption at step two and you redirect. You spot the format drift and you fix it in passing. None of that is written anywhere. It is you, paying attention.

Run five in parallel and that layer is gone. Not degraded — gone. You cannot watch five things at once, and the corrections you used to make live now have to exist up front, as text, or not at all.

This is why the second agent often feels fine and the fifth feels like chaos. The chaos was always there; the human was absorbing it.

The three failures, in the order they appear

1. Incomplete specification. The instruction that worked when you were watching — “review these and flag anything unusual” — produces five different definitions of “unusual.” The fix is not a better model. It is a written definition, which almost nobody has, because until now the definition lived in one person's judgement.

2. Unverifiable output. Five results arrive. Checking each one properly takes as long as doing the work, so you stop checking properly, and you start skimming. Skimmed review is worse than no review, because it produces confidence without evidence. The fix is to require the work to arrive in a checkable shape: the answer, the inputs it used, and the step where it was least certain.

3. Silent divergence. Two agents doing nominally the same job produce two house styles, two thresholds, two interpretations of the same rule. Nobody notices for a month, because each output looks reasonable on its own. Consistency is only visible in aggregate, and nobody is looking at the aggregate.

What the job becomes

The shift is genuinely a management shift, and it is worth being blunt about what it demands, because it is not what most strong individual contributors are good at.

• Specifying before starting, rather than steering while running.
• Designing the check, so a result can be trusted in a minute rather than an hour.
• Judging exceptions — which is the part that stays human, and the part worth protecting your attention for.

The people who thrive at this are not the fastest doers. They are the clearest instructors, which is a different talent and one most organisations have never selected for or promoted on.

The practical constraint nobody mentions

There is a ceiling, and it is set by how much of your work is already written down. If your procedures live in people's heads, one person can supervise roughly one agent, because the specification has to be reconstructed live every time. If your procedures are written, the same person can supervise several, because the specification is already done.

So the honest answer to “how many agents can one person run” is not a number about agents. It is a number about documentation. That is also good news: it is the one variable you can move without waiting for anybody's next model release.

Where to start, concretely

Take one task that two people currently do slightly differently. Write the procedure down until the difference disappears — including the exceptions, which is where the difference actually lives. Then hand the written version to one agent, and check it the way you would check a new joiner: not by watching, but by looking at the output and asking whether you could defend it.

If you cannot defend it, the procedure is not finished. That is a far more useful finding than any benchmark.