Why every agent decision needs a named bound

"The system declined it" is not a reason. A verdict on an agent's action, whether allowed, held, refused or withheld, can only be defended if it names the specific bound that decided it: this limit, this certificate, this source rule. Without that name, nobody can say whether the decision was right, who owns it, or what would change it.

What is a bound, and why are there several?

A bound is a limit an agent's action must stay within. Our glossary entry on what a bound means for AI agents sets out the term. In practice every action meets several at once, each owned by a different party and each answering a different question.

1. Role scope: is this action part of what this agent is for?
2. Certificate: has this agent proven it can do this capability, at this depth, on real cases?
3. Sources: are the facts it relies on strong enough to support this action?
4. The customer's own limits: has the customer, or the business unit, set a tighter limit?
5. Platform guardrails: is this something no agent may do, ever?

The lowest bound wins. A refund that is within role, within certificate and on good sources, but above the customer's limit, is held. The verdict should say so: held, customer limit.

Why is a verdict without a named bound indefensible?

Because each bound implies a different justification, a different owner and a different remedy. An unnamed verdict collapses all of that into "the agent decided", which is the one answer an auditor and a customer will not accept.

Think of a held payment. If the record says only "held", an auditor cannot tell whether the agent was uncertified for payments, was relying on an unverified payee, or simply hit a limit the customer had set. Each of those means something different about whether the control environment worked. If the payment was later approved and turned out to be fraudulent, the question "should this have been stopped?" depends entirely on which bound held it and why the approver overrode it.

The same applies when a customer complains. "Your refund was above the amount we allow without review, and our colleague declined it because the item had been used" is an explanation. "Our system declined it" is a brush-off. The first is only possible if the record names the bound.

How does naming the bound change who acts next?

Each bound has an owner, and the named bound tells everyone which owner to call.

Without the name, held and refused work lands in a general queue where someone has to work out, case by case, why it was stopped. With the name, it can be routed straight to the person who can decide. Where a person must approve, the bound also tells you who that person is; our entry on what a named approver is explains the role.

Why is a confidence or evaluation score not a bound?

Many agent systems attach a score to each output: a confidence level, a quality rating, a probability of correctness. Some use a threshold on that score to decide whether to act. That is a different thing from a bound.

A score is the agent's own estimate, or a model's estimate of the agent. It says nothing about authority. A highly confident proposal to refund 10,000 is still outside an agent certified only to 500. A score also cannot be owned by a person in the way a limit can: nobody signs off that 0.87 is the right threshold for refunds in the way they sign off that 500 is. Our article an eval score is not a bound makes the argument fully. Scores are useful inputs to certification. They are not what decides an action.

Does every tool call need a named bound, or only the big decisions?

Every one that changes something. Agents act through tool calls: read this record, update that field, send this message, start that payment. Each call is a small decision, and each can go wrong. If only the large actions are checked and named, an agent can reach the same outcome through a series of small calls that were never checked. Our piece arguing that every tool call is a decision explains why the check has to sit at that level.

In practice, most calls are allowed, and the named bound for an allowed action is simply the one closest to stopping it. That still matters. It shows how much headroom the agent had, and a run of allowed actions sitting just under a limit is worth a look.

How do per-customer limits fit in?

They are one of the five bounds, and often the one that decides. Different customers, products or business units may want different limits on the same capability, and our discussion of whether an agent's limits should be the same for every customer argues that they often should not. Naming the bound makes this workable. If the record says "held, customer limit 300" for one client and "allowed" for another with a limit of 1,000, the difference is explained and traceable to each customer's own choice.

What is the trade-off?

Naming the bound requires the checks to be explicit and separate. A system that bundles all its rules into one opaque decision cannot say which rule fired. Building it so each bound is evaluated and reported on its own takes more design work, and the record grows larger.

It is the only way to make decisions you can stand behind. An agent that is right most of the time but cannot say why it was stopped, or why it was allowed, leaves its owners defenceless the first time a decision is questioned. Pick ten held or refused actions from last month and ask, for each, which bound decided it and who owns that bound. If you cannot answer from the record, the record needs to change. The structure that makes this possible is set out in our guide to agent governance as a bound, not a model.