There is something strange happening in open source right now. Pi automatically closes issues and pull requests from new contributors unless a maintainer has already approved them. OpenClaw said it was receiving roughly one pull request every two minutes, temporarily locked down new feature work in its core, and now places a hard limit of twenty open pull requests on each author. GitHub introduced repository-level pull request limits in June.
At first this looks like moderation, or perhaps the inevitable tension between popular projects and the people trying to maintain them, but I think it is also an early signal of something larger. Creating code has become easier, proposing it has become almost effortless, reviewing it has not. GitHub's phrasing was clean: the cost to create outran the cost to review.
I keep returning to that line because I think many of us building with agents are about to discover the same problem inside our own systems.
The natural response to a capable coding agent is to run another one. You can see the appetite every time Tibo Sottiaux resets the usage limits for Codex, the announcement lands on X, people celebrate, and the agents go straight back to work. On August 12, after Codex crossed fifteen million active users, he reset them again and told everyone to go /fast. If one agent can inspect a problem, propose a change, write the tests, and open a branch, then four agents should do roughly four times as much work. The models are getting faster, the token cost keeps falling, the machinery is already sitting there, it feels almost irresponsible not to use all of it.
That sounds sensible if the agents are a workforce.
I am not sure they are.
I have been running enough overlapping builder, evaluator, and governor loops lately to see a different shape. The agents do not simply produce work, they send proposed changes toward a shared and fairly narrow destination. That destination has to decide whether the work is new, current, supported by real evidence, and deserving of a place in the canonical system.
When proposals arrive faster than that decision can be made, the system does not merely develop a longer queue. It begins producing the wrong kind of work.
Agents rediscover changes that already landed, they begin from stale branches, they solve adjacent versions of the same problem, they create plausible patches that consume more evaluator time than they save. The branches keep arriving, the repository is not learning faster.
In one recent group of Punk evaluation runs, thirty-six candidates produced only fourteen unique, candidate-attributable direct accepts. Ten more accepted candidates needed evaluator repair, eleven of the thirty-six showed some form of semantic or publication overlap. In CrowdProof, several recent windows spent between three quarters and nine tenths of their scheduled builder runs discovering that somebody else was already working the same ground.
Those are operational observations, not a controlled experiment, but they are enough to make the naive equation feel suspect.
More agents do not necessarily create more useful change. At some point they create congestion.
Networks learned this lesson a long time ago. A sender does not increase the flow forever simply because packets are cheap, it watches acknowledgements, delay, and loss, then reduces the sending rate until the network proves it can carry more.
An agent system may need something similar, except the acknowledgement cannot be a commit, a completed run, or another green test. It has to mean that distinct work was evaluated, integrated, and shown to have independent value. A duplicate is not throughput, a stale branch is not throughput, an hour of evaluator repair is not free simply because the agent was.
The practical implication is fairly direct. Agent schedulers should stop asking only how many agents can run, and start asking how many unresolved changes the system can responsibly absorb. When distinct proposals are being evaluated and merged cleanly, open the window. When branches collide, decisions slow down, repairs rise, or agents rediscover occupied ground, close it. Give agents short leases on a problem, preserve a little deliberate overlap where independent approaches are actually valuable, and let parallel work respond to the rate at which useful decisions settle.
This would also change what we measure. Commit count is activity, completed runs are activity, even accepted changes can mislead when the evaluator is overwhelmed. The number I increasingly want is useful change per evaluator-hour, because the fastest way to improve an agent fleet may be to add an evaluator, narrow the ground, retire stale work sooner, or simply stop sending for a while.
We keep describing agent systems with the language of hiring because intelligence used to arrive one person at a time. It now arrives as traffic, cheaply, continuously, and from more places than the system can necessarily trust or absorb.
If we continue treating agents like a workforce, we will celebrate how much they produce. If we begin treating them like a network, we might finally learn to care how much useful work gets through.
Before adding another agent, ask whether the last agent's work has been acknowledged.