PrymeIntelligence

Agent governance·Answer

How do you handle an AI agent that refuses too often?

Handle an AI agent that refuses too often by finding which bound or behaviour causes the refusals, fixing that cause through change control and retesting.

Find out what is doing the refusing before changing anything. Some refusals come from your bounds working as designed, some from limits set too tight, some from missing sources, and some from the model declining work it could do. Each has a different fix. Never respond by loosening everything: raise only the bound that is wrong, with evidence, and retest.

Why is "too many refusals" a real problem?

A refusal sends work back to a person, or worse, back to the customer with no answer. An agent that refuses a large share of what it is asked costs more than it saves and teaches staff to work around it. We argue in count what an agent refuses, not only what it completes that refusal rates are as important a measure as completion rates.

But a refusal is also a control doing its job. The aim is not fewer refusals. It is the right refusals.

What kinds of refusal are there?

Source What it looks like Usual fix
Role scope Requests outside what the agent is for Route them elsewhere, or widen the role deliberately
Certificate Depth not yet earned for that capability Test for higher depth on your cases
Missing or weak sources The agent cannot confirm a fact, so it declines Connect the source, or improve its provenance
Your limits Amounts or counterparties outside your settings Review whether the limit matches policy
Platform floor Withheld actions None; these are meant to stay refused
The model itself The model declines out of caution, before any bound is checked Improve the brief, examples and sources

The last row is different from the rest. A verdict of refused is the platform's decision and names a bound. A model that says "I can't help with that" when the action would have been allowed is over-cautious behaviour, and it will not show up as a verdict unless you look for it.

What are the steps, and who acts?

  1. Process owner: pulls the refusals. All refused verdicts for a period, plus a sample of conversations where the agent declined without proposing an action. Evidence: the extract.
  2. Analyst: classifies each by source. Using the table above. Evidence: the classification sheet.
  3. Process owner: decides per source. Some refusals are right and stay. Others point to a limit set below policy, a missing source or an over-cautious brief. Evidence: the decision log.
  4. Change owner: makes the change through change control. One change at a time, so its effect can be seen. Evidence: the change record.
  5. Process owner: retests. Rerun the agent on your cases, including the ones that should still be refused, so loosening one thing does not open another. Our answers on how often an AI agent should be retested and how often AI agents should be recertified cover the timing. Evidence: test results.
  6. Process owner: watches the next month. Refusal rate by source, and any rise in errors. Evidence: the monthly review.

A worked example

Take a telecoms company's billing agent that refuses about one request in three. Customers complain, and staff are swamped.

The analysis shows three causes. Many refusals are disputes about roaming charges, which are outside the agent's role on purpose; these go to a specialist queue with a clear message instead of a bare refusal. A second group are credits just above a limit set at 10, while the company's own policy lets frontline staff credit up to 25. The limit is raised to 20 after testing. A third group are the model declining to discuss contract end dates because it is unsure of the date; connecting the contract system as a sealed source fixes that. Refusals fall, and the roaming disputes, still refused, now reach the right people faster.

What about the people who handle refused items?

They need to understand why the agent refused so they can act quickly and report bad refusals. Training matters here as much as for approvers; see approvers need training too.

Which controls stop a fix from creating risk?

  • Change one bound at a time, with evidence.
  • Keep the refusal cases in the test set, so loosening is checked against them.
  • Never touch the platform floor to reduce refusals.
  • Measure errors as well as refusals after each change.

The topic guide, agent governance is a bound, not a model, explains why each refusal names the bound that decided.

Questions people ask

What refusal rate is acceptable?

There is no universal figure. It depends on the agent's role and how much of the incoming work falls outside it. Track the trend by source rather than a single number.

Should the agent explain its refusals to users?

Yes, briefly and with a next step. "I can't change your tariff, but I've passed this to the team who can" is better than a bare refusal.

Can an agent refuse too little?

Yes, and that is the more dangerous problem. A sudden fall in refusals can mean a bound was loosened or a source changed. Investigate it as you would a rise.

Decide what your agents may do. Prove it. Enforce it.

Pryme Intelligence certifies each agent on your own cases, checks every action against five bounds at the moment it happens, and files every verdict.