An agent that never escalates looks efficient on every dashboard until the case that needed a person. Knowing when to stop and hand over is a capability like any other, so it must be proven on real cases during certification. Writing "escalate when unsure" in the agent's brief proves only that someone wrote it.
Why is a low escalation rate not good news?
A falling escalation rate is usually read as progress: fewer cases reaching people, more work done by the agent. Sometimes it is. But the same number appears when the agent has simply stopped recognising the cases it should pass on. From the dashboard, the two look identical.
The cost of the second kind arrives later and all at once. A customer in financial difficulty is given a standard payment plan instead of being routed to a specialist. A complaint is answered as a routine query. A request that needed a manager's approval is handled within the agent's normal bounds because nothing in the message looked unusual to it. Each one is a quiet success in the metrics until it becomes a complaint, a breach or a loss.
There is no universal right rate. The discussion of how high an AI support agent's escalation rate should be makes the point that the rate depends on the work. What matters is whether the agent escalates the right cases, and that can only be known by testing it.
Why is an instruction in the brief not enough?
The brief is where an agent's behaviour lives, so it is natural to put escalation rules there. They belong there. But an instruction describes intended behaviour, and intended behaviour is exactly what certification exists to check.
Escalation instructions are especially prone to failing silently, for three reasons. First, they depend on the agent recognising a condition, such as distress or a legal threat, that is rarely stated plainly. Second, they compete with the rest of the brief, which mostly tells the agent to be helpful and finish the task. Third, they are tested least during development, because the cases that trigger them are rare in any sample. An agent can follow every other instruction faithfully and still miss most of its escalation triggers.
What does a proper escalation test look like?
It needs cases where the correct outcome is a handover, labelled as such, alongside cases where escalating would be wrong. Both directions matter. An agent that escalates everything is safe and useless; one that escalates nothing is efficient and dangerous.
| Case type | Correct behaviour | How it fails |
|---|---|---|
| Customer mentions bereavement or serious illness | Acknowledge, stop the routine process, hand to a trained person | Carries on with the standard script |
| Request exceeds the customer's own limit | Hold for the named approver | Completes it because the request looked routine |
| Customer threatens legal action or says "complaint" | Route to the complaints process | Answers the underlying question and closes |
| Facts in the case conflict with each other | Stop and ask a person to resolve | Picks one source and proceeds |
| Simple question with a clear sourced answer | Answer it | Escalates out of excess caution |
Each case should be scored on whether the agent escalated, whether it escalated to the right place, and whether it said something sensible to the customer while doing so. The detailed method is set out in how to test an AI agent's escalation behaviour.
Why must escalation clear as its own gate?
When you certify an agent, it is tempting to roll everything into one accuracy score. Escalation should not be folded in. A set with a few hundred routine cases and twenty escalation cases can produce an excellent overall score while the agent misses half the escalations.
The escalation gate is scored separately, with its own floor, and it must clear on its own. If it fails, the capability does not earn depth, however good the routine answers were. The reasoning is simple: routine answers are where the agent saves time, but missed escalations are where it causes harm, and one does not offset the other.
What should the handover itself contain?
Escalating is only half the behaviour. A handover that drops the customer into a queue with no context forces them to start again and leaves the person receiving it guessing. Certification cases should also check what travels with the escalation: the reason the agent stopped, the facts gathered so far, what the customer has been told and anything already promised.
This is also what makes escalations reviewable. If each handover states why the agent stopped, you can sample them and see whether the reasons were sound, which feeds directly back into the next certification set.
How should escalation results affect what the agent may do?
Escalation evidence should decide depth as directly as accuracy evidence. An agent that escalates reliably on the tested triggers can be trusted with more routine work, because you have reason to believe it will stop when it should. An agent that misses triggers should be kept at depth 2, drafting for a person, until the brief or bounds are fixed and the gate is cleared on a fresh run.
Where a trigger can be detected by rule, such as an amount above a limit, it is better enforced as a bound than left to the agent's judgement. The agent's escalation behaviour then only has to cover what rules cannot see: tone, context, vulnerability and contradiction.
Where Pryme fits
In Pryme, escalation is one of the seven gates in Attest and must clear on its own against the customer's own cases. Rule-detectable triggers are enforced as bounds, so a request over the customer's limit is held for a named person regardless of how the agent reads it. Every escalation is filed with its reason in the verdict record.
Questions people ask
How many escalation cases does a certification set need?
Enough to cover every trigger in the brief at least several times, with more for triggers whose miss would cause harm. Count by trigger type, not as a share of the whole set.
Is over-escalation a failure too?
Yes. It wastes people's time and teaches staff to ignore the agent's handovers. Score cases where the right answer is to proceed, not only cases where it is to stop.
Can escalation behaviour drift after certification?
It can, particularly after a model update or a change to the brief. Watch the live escalation rate by trigger type and treat a sudden fall as a reason to retest.