How many agents can one developer run well?
By Soumen Sarkar · October 2026
Short answer: There's no fixed number: one developer can run as many agents as they can keep unblocked and whose results they can absorb, which depends on how independent the tasks are and how much the agents can settle without them. Add agents until waiting or rework starts to rise, then stop.
Why isn't there a single answer?
Because the limit isn't the agents. It's the developer's attention. Each agent needs a clear task, an occasional answer, and someone to take in what it produced. A developer can run many agents on independent, well-specified work, and very few on tangled work where every step needs a judgement call.
Anyone quoting a universal number is guessing. The useful question is what limits you, and how to move that limit.
What sets the limit?
Three things, mostly:
- How independent the tasks are. Agents on separate parts of the code rarely collide. Agents on the same feature need coordinating, and that costs attention.
- How often agents stop for you. An agent that halts to ask questions holds a slot in your head while it waits. An agent that states its assumption and keeps going doesn't.
- How fast you can absorb results. Every finished task needs a look. If changes queue up unread, you're running more agents than you can use.
What does a good setup look like?
Picture a developer working on a reporting product on a normal day. One agent adds a CSV export to the reports page, in Reports · lib/reports. Another upgrades a charting dependency and fixes what breaks. A third writes tests for an under-tested date filter. A fourth investigates a slow query.
These are mostly independent. Each agent has a clear goal, works through the unknowns by stating assumptions, and leaves reasons with its change. The developer's job is reviewing reasons and correcting the occasional call. That's sustainable.
Now suppose the developer adds a fifth agent to rework the same reports page the export agent is changing. Suddenly two agents are in one area, their changes overlap, and the developer spends the afternoon reconciling them. One more agent made the day slower.
Which signals tell me I've gone too far?
- Agents waiting on you. If several are idle at once for your answer, waiting time is the bottleneck.
- Work redone. If you're reconciling overlapping changes, rework is eating the gain.
- Unread results. Finished changes piling up unreviewed means you're producing faster than you can absorb.
- Forgotten context. If you can't remember what one of your agents is doing without opening it, that's one too many.
When these appear, reduce the count or change how the agents work, not the other way round.
How do I raise the ceiling?
Make agents need you less. Instruct them to look in the team's record first, and to state an assumption and keep going when it's silent. Give them context about the code automatically, so they don't ask. Keep tasks independent. Read reasons instead of whole diffs.
Campfyrr helps on the "need you less" side: in Claude Code, agents get the team's state at session start and an area brief the first time they touch a part of the code, and their stated assumptions go to whoever can settle them, often answered straight from the record, while they keep working. How many agents that lets you run is something only your own signals will tell you.
Words used here
- Waiting time: Waiting time is the time work spends stopped for a person: from the moment a question, assumption or handoff needs someone until they act on it.
- Rework: Rework is work done again because it was built on something wrong: a mistaken assumption, a clashing decision, or a plan that changed without anyone hearing.
- Assumption: An assumption is the best available answer to an unknown, stated and acted on, kept visible so anyone can correct it.
The principle behind this: Keep moving: The work never waits, and neither do we.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).