At what point does running more agents backfire?
by•
I keep seeing tools talk about how many agents they can run in parallel or how much of the backlog they can take on.
But every additional agent also creates more work to review, more decisions to make and more places where something can quietly go wrong.
At some point, the person supervising them is no longer properly checking the work. They are just trying to keep up with it.
So I’m starting to think agent count is the wrong measure. What matters is how much verified work gets completed without creating another pile of work for the human overseeing it.
Has anyone found where that tipping point is?
162 views
Replies
Promomix
More agents make sense when they reduce waiting. If they increase context switching i would rather run fewer.
For me, reliability would matter more than the number of agents running.
Buffup.AI
I would measure this by accepted work vs. review work generated. that tells you whether the extra agents are actually helping.
I'm curious how others are deciding when to stop adding agents.
For me two focused agents beat five noisy ones. context overlap creates a surprisingly big review tax.
i wonder if smaller teams hit this limit much earlier.
Bababot
The dangerous part is that the extra workload doesnt always look like work its tiny decisions, reviews, conflicts, and corrections pilling up.
it backfired on us when an agent put a confident number into a report that nobody measured. other agents took it as ground truth and we spent a day tracing what was just a placholder ) more agents fail the moment they start verifying each other's hallucinations instead of real data
Nobody has named the thing that actually moved the tipping point to me: it was how much of the review had to happen by reading.
The count I can supervise is roughly how many of these can fail in a way CI tells me about. My repo has a test that greps the whole source tree for marketing claims we retired, and another that pins the exact list of files allowed to use an old naming convention. Neither is "smart". Both exist so that one class of agent mistake stops being something I have to personally notice. Every rule I move into that category raises the agent count I can handle, and it raised it more than any prompt change ever did.
Konstantin's example is the best failure in the thread, and I'd draw the line slightly differently than by counting agents. The danger starts when one agent's output becomes another agent's input without passing through something that can fail. Several agents working from the repo is fine. Agents working from each other is how a placeholder becomes ground truth.
i ran four in parallel today and the tipping point showed up somewhere between the third and the fourth, but not for the reason id have guessed. it wasnt review time. it was that only some of the outputs were checkable. one came back claiming a page was live when it wasnt, and i could settle that in about thirty seconds by loading the url myself. another came back with a synthesis i had no cheap way to test, so it just sat there costing me a full read every time i wanted to use any of it. so the number that predicts backfire for me isnt agent count, its what fraction of the output i can verify mechanically. anything i can check with a lookup is nearly free to add. anything that resolves to a judgement costs the whole read, every time. the other thing that surprised me is that one of them was wrong in a consistent way, it kept swapping two fields, and that would have propagated straight into my conclusions if i hadnt caught it. a second agent whose only job was checking the first would have been worth more to me than the fourth one producing new material.