The Action-Limit Pattern: Capping What an Agent Can Do
Hard caps per run, per service, per minute. The cap dimensions that matter, sensible defaults, and the dashboard that catches caps quietly hitting in production.
Cap dimensions that matter
Action caps need at least three independent dimensions. A single cap value is either too tight for high-volume cases or too loose for high-risk ones.
- Per-run cap. How many actions a single agent run can take. Default 5; raise only with evidence.
- Per-service cap. How many actions per minute against a single service. Prevents thundering herd on any one upstream.
- Per-tenant cap. How many actions per hour per customer or team. Catches misconfiguration at the integration layer before it spreads.
- Per-action-type cap. Some actions (deletes, rotations) carry their own per-day limit independent of the per-run total.
Sensible defaults to ship with
Defaults are conservative on purpose. Raising a cap when evidence justifies it is cheaper than recovering from a thundering-herd outage.
- Triage agents. Zero write actions; read-only by default.
- Remediation agents. 3 actions per run, 1 per service per minute. Tight enough to prevent cascades.
- Audit agents. 1 write per run (the report). Audits never modify the systems they audit.
- Visible to operators. Each agent’s caps appear in its dashboard. Operators request raises; changes are reviewed and audited.
Watching the caps in production
Cap hits are signal, not noise. Distinguishing the correct hits from the bug hits is what makes the dashboard useful.
- Per-hit classification. Each cap hit is correct (preventing harm) or a bug (the agent should have completed). Distinguish in the dashboard.
- Aggregate hit rate per agent. A spike means something changed: prompt, model, traffic, environment. Investigate immediately.
- Repeat-scenario hits. Cases where the cap repeatedly fires for the same scenario become eval cases. The agent is underestimating scope and the case codifies it.
- Operator override audit. Track raises granted on request. A team granting many raises has a deeper sizing issue than the cap itself.
What happens when a cap hits
Cap behaviour is part of the agent’s contract. Quiet truncation is the failure mode worse than no cap at all.
- Action cap. Agent escalates to human with the actions taken so far and the action it would have taken next.
- Service cap. Agent waits for the rate window to reset, with a max wait. If the wait would exceed the run budget, escalate instead.
- Tenant cap. Agent fails the run and surfaces a clear error. The tenant should know they hit a cap; do not silently degrade.
- Loud signalling. Cap hits emit metrics and log lines. Quiet truncation is the worst possible behaviour because nobody knows.
Eval cases for caps
Caps need eval cases in both directions. Tight caps that fire on routine traffic are as bad as loose caps that miss runaway runs.
- Should hit. Cases that should hit the cap on purpose. Pass if the cap fires; fail if the agent completed regardless.
- Should not hit. Cases that should complete cleanly. Pass if the agent completed; fail if it triggered a cap unnecessarily.
- Aggregate target. Cap hit rate over the eval suite stays under 5 percent. Higher means caps are too tight; lower likely means they are loose.
- Cross-cap interaction. Test cases where two caps could fire together. The agent should hit the most-restrictive cap and escalate cleanly.