Most teams meet rate limits for the first time as an error message: the provider throttles a call, the agent stalls, and someone raises a limit they never wrote down. That is backwards. A provider's limit protects the provider. Your AI agent rate limit policy template protects your plan: it records, per agent and per plan, how many calls may run in a window, how many may run at once, and how much the whole plan may spend \u2014 before any of those numbers is reached.
Why rate limits are a governance problem, not a settings page¶
Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by 2026, up from under 5% in 2025. Every added agent multiplies call volume, and call volume is where the documented failures live: practitioner reports describe a runaway agent loop that burned over $700 in 72 hours with no budget control in place. A loop does not need malice. It needs an uncapped call rate, no parallel-call limit, and nobody watching the counter until the bill arrives.
Rate, parallelism, and spend are three faces of one bound: calls per window without a spend ceiling still lets expensive calls through, and a ceiling without a parallel-call cap lets one plan consume the whole window in a burst. A rate limit is only real when all three are recorded together, in the plan bound, and enforced before the call runs.
A rate limit is part of the plan bound¶
In the Governed Agent Mesh Playbook, the plan bound is the unit governance operates on: if a unit of work cannot be expressed with its bounds filled in, it is not a plan and it does not run. Rate limits belong inside that record, next to the cost ceiling, the time window, and the expiry \u2014 not in a provider dashboard, not in a prompt, and not in the agent's own code where the agent is the one being limited.
The record also names who the limit applies to. Every agent holds a stable, owner-scoped identity \u2014 in the Playbook's format, agent:owner/name \u2014 before its first action, and anonymous, shared, or unregistered actors are rejected at the dispatch path. A limit attached to "the API key" limits everyone and no one; a limit attached to an identity and a plan can be enforced, audited, and changed on purpose.
What the rate limit record contains¶
Each record carries eight fields. A plan missing any of them is incomplete, and a call depending on it fails closed until the record is finished.
- Agent identity and plan. The stable identity the limit is issued to, and the plan it belongs to. Limits apply per plan, never per account.
- Calls per window. The maximum number of calls the plan may make inside its stated time window.
- Max parallel calls. The maximum number of calls running at the same time. This is a required field of the plan bound's resource record, not an afterthought.
- Cost ceiling. The maximum spend for the plan, counted in real time. Rate limits slow a burn; the ceiling stops it.
- Alert thresholds. The points at which the owner is told the plan is approaching its bounds \u2014 the Playbook's spend policy uses 50% and 80% as its example thresholds.
- Time window and expiry. When the window opens and closes, and when the plan itself expires. An expired plan is the same as no plan.
- Owner. The human who owns the limit and receives its alerts and blocks. Never the acting agent.
- Audit reference. Where each use, alert, and block is recorded in the hash-linked audit log.
The fill-in template¶
Copy one record per plan; fill every bracket before it counts as adopted.
- Identity: agent:[OWNER]/[NAME] \u00b7 Plan: [PLAN ID AND WORKLOAD]
- Calls per window: [MAXIMUM CALLS] per [WINDOW LENGTH]
- Max parallel calls: [NUMBER RUNNING AT ONCE]
- Cost ceiling: [AMOUNT] [CURRENCY] per plan, counted in real time
- Alerts at: [THRESHOLDS \u2014 e.g. 50% and 80% of calls, parallelism, or spend]
- Time window: [START] to [END] \u00b7 Plan expires: [DATE OR RULE]
- Owner: [LIMIT OWNER] \u00b7 Audit: [LOG LOCATION AND ROW REFERENCE]
Worked examples belong in the template only as labelled synthetic rows \u2014 a demo row labelled "synthetic demo" in the row itself, or the record stops being evidence. Keep credential material out of the record, too: secrets live outside the policy and the audit log, always.
When the limit is reached: fail closed¶
When a ceiling is reached, the action fails closed: it is blocked, recorded as blocked, and never retried automatically. The same rule covers missing evidence \u2014 when identity, grant, approval, or budget headroom cannot be shown, the action is blocked, never degraded to a warning. Warning-only paths are prohibited for any action with external or financial side effects.
Every block persists an audit row with the actor, the action, the target, outcome=blocked, the timestamp, and the exact reason \u2014 which limit, which counter, which plan. And every block tells the owner, in plain language, which piece of evidence would unblock it: a raised limit, a new window, or a new plan. A block that says only "rate limited" teaches nobody anything.
Alerts fire before the ceiling, not after¶
A limit that announces itself only by blocking has done half its job. Spend \u2014 and with it, call volume \u2014 is counted against the plan in real time, and the owner is alerted at the recorded thresholds on the way up. The alert names the plan, the identity, and which counter is climbing, so the owner can tell a legitimate burst from a loop while there is still headroom to act.
Raising a limit is a hard-gated change¶
Raising a ceiling is a hard-gated action: it requires human approval and a recorded reason. The same applies to widening a call window or a parallel-call cap \u2014 each is a permission change, and the acting agent can never approve its own. The approval is recorded with the approver's identity, the timestamp, the action reference, and the decision; a denied or missing approval produces a recorded block, never a silent skip or a quiet auto-raise.
A rate limit an agent can raise for itself is a suggestion. A rate limit that changes only through a recorded human decision is a bound.
Retries need new evidence, not a timer¶
Blocked actions are never retried automatically. A retry requires new evidence, not a timer: a raised limit approved by its owner, a new window opened by the plan's own schedule, or a corrected plan. An agent that simply waits and hammers the same bound converts one block into a log full of blocks and, where calls are metered, into spend against the very ceiling it hit. Waiting is not evidence.
Unmetered frameworks run behind a meter¶
Frameworks with no native budget controls run behind a meter. Unmetered execution is prohibited. If the framework cannot count calls, parallelism, and spend against the plan in real time, the counting happens at the dispatch path in front of it \u2014 the same place identity is checked and blocks are enforced.
Common mistakes¶
- Relying on the provider's limit. The provider's throttle protects the provider's capacity, at the provider's number. Your plan's bound is yours, set from your ceiling, and usually reached first on purpose.
- One limit for the whole account. Account-wide limits hide which plan is burning. Limits apply per plan and per identity, so the audit row can name the culprit.
- A call cap with no spend ceiling. Cheap calls and expensive calls count the same in a call counter. Pair every rate with a per-plan cost ceiling counted in real time.
- Auto-raising on block. A limit that widens itself under pressure is a loop's best friend. Raising is hard-gated, human-approved, and recorded with a reason.
- Timer-based retries. Retrying a blocked call on a schedule spends against the ceiling and proves nothing. Retry on new evidence only.
The 10-minute starter version¶
In ten minutes: pick one agent and one plan. From its logs \u2014 not memory \u2014 write down the calls it actually makes, the most it runs at once, and what a run costs. Set the record slightly above that observed shape: calls per window, max parallel calls, a per-plan cost ceiling, alerts at 50% and 80%, an owner, and an expiry. Then turn on the default: at the bound, the call blocks and writes its audit row.
That is the core of the AI agent rate limit policy template: rate, parallelism, and spend written as one plan-bound record \u2014 identity, window, ceiling, thresholds, owner, expiry \u2014 counted in real time, enforced at dispatch, and changed only by a recorded human decision.
The Governed Agent Mesh Playbook \u2014 Studio Edition ($29) collects the fill-in policies, the plan-bound and audit-row schemas, and the fourteen-day rollout that puts records like this one in force: Get the Studio Edition.