An agentic operating system enforces limits at the moment of action. Each time an agent proposes something, the platform checks it against every bound that applies, using live figures from your systems rather than the agent's own account. The lowest bound wins, the verdict names which one decided, and the result is filed before anything reaches the target system.
What kinds of limit are there?
Limits come from several places, and all apply at once.
| Limit type | Example | What the platform needs to check it |
|---|---|---|
| Role scope | The agent may change delivery addresses, not prices | The capability list for the role |
| Depth | Refunds at depth 2: drafts only | The agent's certificate for that capability |
| Per-action | No single refund over the customer's limit | The proposed amount |
| Cumulative | No more than a set total of refunds per agent per day | A running total from the record |
| Count | No more than a set number of address changes per account in a period | History for that account |
| Time | No payments outside the payment window | The clock |
| Source | No payment authorised by an external claim | The provenance of the facts relied on |
| Platform floor | Reversing a settled payment is withheld for every agent | The guardrail list |
The cumulative and count limits are the ones that most often go missing in home-grown setups, because they need state. A per-action check alone can be defeated by splitting one large action into several small ones.
How does a single check work?
- The agent proposes an action through a registered tool, with parameters.
- The platform identifies the capability and gathers the bounds: the role's scope, the agent's certificate and depth for that capability, the sources the action relies on, the customer's own limits and the platform guardrails.
- It reads live state where a bound needs it, such as today's refund total.
- It evaluates each bound. The most restrictive result wins.
- It returns one of four verdicts: allowed, held for a named person, refused, or withheld.
- It files the verdict with the deciding bound, then, if allowed, performs the action.
The agent does not see the limits as numbers it could argue with. It sees the verdict and the reason.
What does this look like in practice?
Take a subscription business whose support agent can issue goodwill credits at depth 3, up to an amount per credit and a daily total per agent. A customer complains about three missed deliveries and asks for a large credit.
The agent proposes a credit at the per-credit maximum. Allowed. Later, the same customer contacts support again and the agent proposes another. The per-credit check passes, but the platform's count limit allows one goodwill credit per customer per month. Held, with the verdict naming the count limit. A team leader sees the history and decides. Near the end of the day, the agent's running total approaches its daily cap; the next credit is held on the cumulative bound, even though it would pass every other check.
Three verdicts, three different deciding bounds, all visible in the record.
Where do limits sit compared with a gateway or agent platform?
An AI gateway can enforce rate limits on model calls, which protects cost and capacity. It does not see business actions such as refunds, so it cannot enforce business limits; see whether an agentic operating system is the same as an AI gateway. Many agent platforms let you set permissions per agent, but they are typically configured, not earned, and rarely cumulative; the difference is set out in how an agentic operating system differs from an agent platform.
What stays with a person?
Setting limits is a business decision, so people own it: the customer's limits come from risk and process owners, and the platform guardrails are set at the platform floor. People also decide every held action. Raising a limit, or an agent's depth, is a change with an approver, never something an agent requests and receives on its own.
Where Pryme fits
In Pryme, every action meets the minimum chain: role scope, certificate, sources, your own limits and the platform guardrails. The lowest one wins, and the verdict names which bound decided. Every verdict is filed in an append-only record. For a list of limit checks to test any option against, use the agentic operating system requirements checklist. The wider design is in the governed agentic operating system guide.
Questions people ask
Can an agent see its own limits?
It can be told, in general terms, what it is for and what it should not attempt. The enforced values should sit in the platform, so the agent cannot change them or talk around them.
What happens if a limit check cannot read live state?
The action should be held, not allowed on a guess. Failing closed means a temporary outage delays work rather than letting a limit lapse.
Do limits replace the target system's own controls?
No. Systems still apply their own rules. The platform's limits are an additional check focused on what agents may do, and both should hold.