Completion counts tell you how busy an agent was. Refusal counts tell you whether it is doing the right work. Every refusal names a bound that stopped an action, so tallying them by bound and by capability shows where limits bite, where they may be wrong, and where people are sending the agent work it was never meant to do.
Why do most agent reports only count completions?
Because completions are what the business case promised. An agent was deployed to handle a volume of work, so the natural measure is how much of it the agent handled. Dashboards show tasks closed, time saved and the share of work that needed no person. Refusals, if they appear at all, are filed under failure.
That framing hides most of what you need to know. A completed task tells you the agent acted. It does not tell you whether the agent was the right party to act, whether its bounds were tested, or whether the work it received matched the work it was approved for. A refusal tells you all three, because a well-built refusal records what was asked, which bound stopped it and why.
What can a refusal tell you that a completion cannot?
A refusal is the moment the agent's authority meets the real world. Every action passes through several bounds at once: the agent's role scope, its certificate, the sources it relies on, the customer's own limits and the platform's guardrails. Most actions pass all five and nobody learns anything. A refusal shows exactly which one held.
Grouped together, refusals answer questions completions cannot. Is the customer's limit set at a sensible level, or is it stopping routine work? Is the agent receiving requests outside its role, which means the routing upstream is wrong? Are its sources missing something it needs, so it refuses rather than guess? Is anyone trying to get it to do something it should never do?
How should refusals be grouped to be useful?
Raw totals are nearly meaningless. A hundred refusals could be one misrouted queue or a hundred separate attempts at misuse. The value comes from grouping each refusal by the bound that decided it and the capability it concerned.
| Deciding bound | What a cluster usually means | Who should look |
|---|---|---|
| Role scope | Work is being routed to the wrong agent | Process owner |
| Certificate | The agent is asked to act above its proven depth | Agent operations lead |
| Sources | The facts it needs are missing, stale or unverified | Whoever owns the source |
| Customer's own limits | The limit may be too tight, or the work too large | Business owner of the limit |
| Platform guardrails | Someone is asking for something never allowed | Risk and security |
This turns refusals from noise into a work list. Each row points to a different owner and a different fix. A spike in source refusals is a data problem. A spike in role-scope refusals is a routing problem. A spike against platform guardrails may be a security problem.
Is a high refusal rate good or bad?
Neither, on its own. A high rate can mean the bounds are doing their job against a stream of unsuitable requests. It can also mean the bounds are set too tight and the agent is refusing work it could safely do, which pushes that work back onto people and erodes the case for the agent. Our piece on what to do with an agent that refuses too often deals with that second situation.
A very low rate deserves as much suspicion. If an agent almost never refuses, either its work is unusually clean, or its bounds are so wide they never bite, or refusals are not being recorded. The last two are governance failures that a completion dashboard will never reveal.
The useful measure is change. A refusal pattern that is stable from week to week tells you the agent and its environment are in balance. A sudden shift tells you something changed: new work types, a new source, a new limit or a new kind of request.
What makes a refusal count trustworthy?
Three conditions. The refusal has to be recorded at the moment it happens, by the system that checked the bound, not reconstructed later from the agent's own account. It has to name the bound that decided, so it can be grouped. And it has to sit in a record nobody can edit, so a run of embarrassing refusals cannot quietly disappear before a review. That last point is why the agent record must be append-only.
You also need to know that refusals are correct. An agent that refuses the wrong things is as much of a problem as one that refuses nothing. Refusal behaviour should be tested before deployment, with cases designed to sit just inside and just outside each bound, as described in our guide to testing whether an AI agent refuses correctly. Once live, a sample of refusals should be reviewed by a person each week to confirm the bound was right to stop the action.
Who should see refusal counts?
The operations team that runs the agent should see them daily, because refusals often mean a customer is waiting. The process owner should see them weekly, grouped by bound, to decide whether routing, sources or limits need to change. Risk should see them monthly, with particular attention to refusals at the platform guardrails and any attempt to act outside role scope.
This is one reason agent governance belongs with operational risk, not only IT. A technology team will read refusals as errors to suppress. An operational risk team will read them as evidence about where controls are working and where the process around the agent is weak.
What is the trade-off in reporting refusals?
Refusals are uncomfortable to report. They look like failure, and a sponsor who promised a high automation rate may not want them on a slide. Grouping and explaining them takes analyst time that a completion count does not.
Leave them out and you lose your best early warning. Most agent problems show up first as a change in what gets refused, long before they show up as a complaint or an incident. If your reporting only celebrates what the agent finished, start counting what it declined, by bound and by capability, and give each cluster an owner. The broader case for bounds that leave this kind of evidence is in our guide to agent governance as a bound, not a model.
Questions people ask
Should refusals count against an agent's performance score?
Not as a blanket rule. A correct refusal is the agent doing its job, and penalising it encourages bounds to be loosened. Score refusal accuracy instead: whether the agent refused the cases it should have and acted on the ones it was allowed to.
How is a refusal different from a held item?
A held item is within the agent's reach but needs a named person to approve it before it goes ahead. A refusal is outside the agent's bounds altogether, so the agent will not draft it for approval. Both should be counted, but they point to different fixes.
What should happen to work an agent refuses?
It should go somewhere specific: a named team queue, a different agent with the right scope, or back to the requester with a reason. A refusal that leaves work stranded creates a hidden backlog, so track how long refused work takes to be picked up.