The Swarm's Own Metabolism

The problem: a cap is a guess, and guesses are wrong twice a day

Any system that lets many workers run at once needs a limit on how many run simultaneously. The obvious knob is a hard ceiling — at most N agents in flight. The trouble is that N is a single number standing in for a workload that is never constant. Set it low enough to be safe during a burst and you leave capacity idle the rest of the time. Set it high enough to use that capacity and a burst floods everything downstream — review queues back up, half-finished work piles up faster than anyone can check it, and the system is “healthy” by the one metric it was tuned against while quietly drowning in its own output.

A hard cap also has a worse failure mode than being wrong: it does not know it is wrong. It caps the same way whether the backlog behind it is empty or overflowing, because a cap only ever looks at how many are running, never at how much unfinished work those runs have already produced.

The approach: let the backlog be the brake

The fix is to stop treating concurrency as a fixed ceiling and start treating it as a target that the system continuously adjusts against its own state — specifically, against how much of its own output it has produced but not yet finished digesting (reviewed, verified, reconciled, closed out). Call that quantity the system’s undigested backlog. As the backlog grows, the effective concurrency target comes down — not to zero, and not by a hard stop, but by a smooth, monotone reduction that always leaves room for at least one worker to keep moving. As the backlog drains, the target rises back toward its full value on its own.

This is a homeostatic loop, and the biological framing is not decorative: an organism does not stop eating because a rule says “no more calories today” — it slows down because it is already full, and the fullness itself is the signal. The system here works the same way. Nothing external has to notice the backlog and intervene; the backlog is the governor, computed from information the system already has about its own state, with no central scheduler watching a dashboard and turning a knob by hand.

The result: two properties a hard cap cannot give you at once

A fixed ceiling gets you one property — a worst-case bound — and pays for it by giving up the other one that actually matters day to day: a system that settles rather than oscillates. The backlog-driven target gets both:

• Equilibrium. The system finds a stable operating point on its own, without anyone hand-tuning a number for “today’s” workload. Push it away from that point — a burst, a slow patch — and it returns, the same way a thermostat returns a room to temperature rather than swinging between too hot and too cold.
• Momentum. The brake never reduces the target to zero. Slowing down is never the same as stopping; the system always keeps some forward motion, and the thing it is braking toward is more digestion — which is itself progress, not merely a pause. A system that can only be paused eventually needs a human to un-pause it. One that can only be slowed never needs that call at all.

The takeaway

The instinct with an unruly system is to add a rule that stops it. The more durable fix is to give the system a sense of its own fullness and let that sense do the throttling — because a rule has to be re-guessed every time the workload changes, and a feedback loop does not. A brake that comes from the system’s own backlog, rather than from a number a person picked in advance, is a system that regulates itself the way a living thing does: not by hitting a wall, but by noticing it is full.