Count limits against the business object, not the agent. A refund cap belongs to the customer, a payment cap to the supplier, a daily total to the account, and every agent's actions count towards the same total. When one agent hands work to another, the hand-off carries the original limits, and the lower one applies. Then a limit cannot be escaped by changing who acts.
How do agents get around limits?
Rarely by design. Usually an agent is trying to complete a task and finds a path. The common patterns:
- Splitting across agents. Agent A refunds 90 under its 100 cap; Agent B refunds another 90 for the same complaint.
- Handing to a higher limit. A support agent that cannot credit 500 asks the billing agent, which can.
- Splitting across time. Three payments on three days, each under a daily cap.
- Splitting across records. One supplier invoice raised as several purchase orders.
- Routing through a person's queue where items are approved without review.
Each is a version of the same fault: the limit was counted per actor, and the actor changed.
What are the steps, and who acts?
- Process owner: keys every limit to a business object. Customer, supplier, account, invoice, complaint. Write the limit as "refunds per complaint", not "refunds per agent". Evidence: the limit definitions.
- Platform: counts across agents and sessions. Running totals for each object include every agent's actions. Evidence: the totals used in each verdict.
- Platform: carries limits through hand-offs. When one agent passes work to another, the originating agent's scope and limits travel with it. The receiving agent cannot do more than either would alone. Evidence: hand-off records showing inherited limits.
- Platform: links related actions. A shared reference for the complaint, order or case ties together actions taken by different agents at different times. Evidence: correlation identifiers in the record.
- Risk: watches for near-limit clusters. Many actions just under a threshold, across agents, is a signal. Evidence: the monitoring report.
- Process owner: separates preparers and approvers. An agent should never approve another agent's work in place of a person; see why one agent should not approve another agent's work. Evidence: the approval matrix.
What does a chain-aware limit look like?
| Pattern | Per-agent limit | Chain-aware limit |
|---|---|---|
| Two agents refund the same complaint | Both pass | Second is held: complaint total exceeded |
| Support agent asks billing agent to credit 500 | Billing agent's limit allows it | Support agent's lower limit travels with the request; held |
| Three payments across three days | Each passes daily cap | Weekly cap per supplier catches the total |
| Invoice split into five orders | Each under the order cap | Total per supplier per reference flagged |
Rates matter too. A cap on how many actions an agent can take per hour makes splitting slower and easier to see; our guide on rate-limiting an AI agent at the API gateway explains where to set it.
A worked example
Take an airline's customer service operation with three agents: one for booking changes, one for compensation, one for loyalty points. Compensation for a delayed flight is capped at 200 per passenger per disruption.
A passenger asks for compensation. The compensation agent offers 200, the maximum. The passenger then asks the booking agent for a refund of a seat upgrade and the loyalty agent for bonus points "for the trouble". Under per-agent limits, all three would pass. Under chain-aware limits, the disruption reference links the three. The seat refund is a separate entitlement and is allowed. The bonus points are counted as compensation against the same disruption, so they are held for a supervisor, and the verdict names the customer's limit and shows the running total.
Which controls make the answer hold?
- Limits on business objects, not actors.
- Shared running totals across agents and sessions.
- Inherited limits on every hand-off, with the lowest winning.
- Correlation of related actions.
- Monitoring for clusters below thresholds.
These controls also cap how far one error can spread; see how to limit the blast radius of an AI agent. The topic guide, agent governance is a bound, not a model, explains why limits belong to the bound rather than the agent.
Questions people ask
Is splitting by an agent a sign it has been manipulated?
Sometimes. More often the agent was trying to finish the task. Either way, the fix is the same: limits that count the whole chain.
Do orchestrator agents need special treatment?
Yes. An agent that coordinates others should hold only coordination capabilities and should never pass more authority down than it holds.
What about a person approving many small items?
Count them too. A person's approvals of agent-prepared items should appear in the same totals, so a queue cannot be used to bypass a limit.