The deciding bound is the one limit, out of the five every action is checked against, that determined the verdict an AI agent received. The most restrictive bound always wins. Naming it in the record turns "the agent was stopped" into "the agent was stopped by the customer's payment limit", which someone can act on.
Why does the deciding bound matter?
A verdict without a reason is hard to use. If an agent's refund is held, the operations team needs to know whether to raise a limit, renew a certificate, fix a data source or leave things alone. Each of those is a different owner and a different conversation. The deciding bound tells them which one.
It also makes patterns visible. If most of an agent's held actions name the customer's limits, the business set the limit low on purpose and the agent is working as designed. If most name the sources bound, the agent is being fed weak data. If they name the certificate, it is time to recertify. The argument for recording this on every verdict is in why every agent decision needs a named bound.
How does it work in practice?
Every proposed action is checked against all five bounds at once:
- Role scope
- Certificate
- Sources
- Customer limits
- Platform guardrails
Each returns its own result: allowed, held, refused or withheld. The overall verdict is the most restrictive of the five. The bound that produced it is the deciding bound. If two bounds give the same restrictive result, both are recorded.
For allowed actions, there is no restrictive bound, so the record shows that all five cleared. That is still useful: it proves the agent was checked, not merely trusted.
What does that look like in an example?
A utility's billing agent proposes to waive a late fee of 30 for a customer. Role scope: waivers are part of its job. Certificate: in date, depth 3 for waivers. Sources: the customer's payment history comes from the billing system, a sealed source. Customer limits: waivers up to 25 without review. Platform guardrails: no issue.
Four bounds allow; the customer limit holds. The verdict is held, and the deciding bound is the customer limit. The action goes to a person at a human gate. When the operations manager reviews held waivers at the end of the month and sees that almost all sit between 25 and 40, she has the information to decide whether the limit is right.
How is the deciding bound different from the other bounds checked?
All five bounds are evaluated every time; only one decides. The others are still recorded, because they show how close the action came to a different outcome. An action held by the customer limit but also only just inside its certificate's scope tells a different story from one held with every other bound comfortably clear.
The deciding bound is also different from an eval result. An eval explains how an agent performed in testing. The deciding bound explains why a particular live action was treated the way it was. That distinction is drawn in an eval score is not a bound, and the underlying approach is in agent governance is a bound, not a model.
Which related terms should you know?
- Minimum chain: the rule that all five bounds apply and the lowest wins.
- Verdict: the recorded outcome of an action.
- Held: drafted and waiting for a named person.
Questions people ask
Can the deciding bound be the platform guardrails?
Yes. When it is, the verdict is withheld: the action exists and works, but the platform refuses it for every agent at every depth. No customer setting changes that outcome.
Should the deciding bound be shown to the end customer?
Usually in plain terms rather than by name. A customer can be told that a request needs a colleague's approval or is outside what the service can do. Internal detail, such as which limit applied, stays in the record for staff and auditors.