Article · Implementation
How to Handle Exceptions and Human Escalation With AI Agents
An agent that works well isn’t the one that resolves every case, but the one that knows which cases it shouldn’t. Exception handling with AI agents is, at bottom, designing the boundary of the mandate: the line separating what the agent executes on its own from what goes to a person. Drawing that line well governs the system’s real risk. Drawing it badly produces either a useless agent that escalates everything or a dangerous one that decides what it shouldn’t. Here’s how I draw it: what counts as an exception, how they’re categorised, what escalates and to whom, and how the whole thing improves over time.
What an exception is
An exception isn’t an error. An error is the agent doing badly what it knows how to do. An exception is a case that falls outside what its mandate lets it decide. Confusing the two leads to the trap of treating every exception as a fault to fix, when many are exactly what the system should do: recognise a limit and ask for help.
I distinguish three origins, because each is handled differently:
- Low confidence. The agent could act but isn’t sure enough. The data is ambiguous, the case resembles several patterns at once.
- Out of policy. The case is clear, but it exceeds what the mandate authorises: an amount above the threshold, a sensitive operation, a flagged customer.
- Out of pattern. The case resembles nothing the agent has seen in its rules or its examples. New territory.
A well-designed agent escalates all three. The low-confidence one because guessing would be reckless, the out-of-policy one because the decision isn’t its to make, the out-of-pattern one because it has nothing to go on.
How exceptions are categorised
“Escalate to a human” can’t be a single door through which everything odd arrives. If it is, that door becomes a bottleneck and the person staffing it ends up staring at an unsorted jumble. Exceptions are categorised, just as normal cases are.
Categorising means giving each exception a type, a cause and a destination. Picture a 60M€ B2B services company putting an agent on incoming orders. Its exception table might start like this:
| Exception type | Typical cause | Destination |
|---|---|---|
| Customer without approved credit | Out of policy | Finance, with the case prepared |
| Ambiguous product reference | Low confidence | Operations, with the likely options |
| Order with non-standard terms | Out of pattern | Account manager |
| Amount above threshold | Out of policy | Supervisor confirmation |
This table isn’t invented whole on day one. You start with the exceptions the people doing the work already know, and it grows as the real operation reveals cases nobody anticipated. Each new type that appears gets named, assigned a destination, and stops being “the odd stuff” to become a managed category.
What escalates and to whom
Two decisions a board should make with its eyes open, because they distribute responsibility.
What escalates is set by the threshold for each exception type. There’s a real tension here: the lower you set the confidence bar for acting, the more the agent resolves alone and the more risk you take on. The higher, the safer but the more load on people. There’s no universal number. You start conservative —the agent escalates a lot— and relax where the data proves reliability, never the other way round. That gradation of autonomy, and who confirms what, is a permissions matter I develop in AI agent permissions and controls.
Who it escalates to is decided by competence, not hierarchy. The credit exception goes to finance, the product one to operations, the commercial one to whoever owns the account. The goal is for the case to reach whoever can resolve it in one step, not a generic inbox someone then has to sort. The boundary between what the agent decides and what the person decides —the supervision pattern, whether the person sits inside the loop or watches over it— is a design decision with its own discipline. Here I stay on its operational side.
The context that reaches the person
A badly escalated exception is the one that arrives as “review this case” and forces the person to reconstruct from scratch what happened. That destroys the advantage: if resolving the exception costs more than doing the case by hand would have, the agent subtracts instead of adding.
A well-made escalation delivers the case prepared: what the agent received, what it tried, why it stopped, what options it sees, and what the person needs to decide. The person doesn’t investigate. They judge. And their decision returns to the system in a form that can be reused, not as a loose email that gets lost. That whole trail —what arrived, what was decided, who decided it— is the material the system’s audit lives on, and connects to the framework in AI agent governance.
How the system improves: exceptions that become rules
Here’s the part that turns exception handling into a compounding advantage rather than a permanent tax.
When an exception type recurs and people always resolve it the same way, it has stopped being an exception. It’s a rule that wasn’t written down yet. The mature process captures that pattern, states it as an explicit rule, tests it against historical cases to make sure the person and the new rule agree, and from then on the agent resolves it alone. The exception queue drops, not because it’s ignored, but because it’s been learned from.
That cycle has a strategic consequence: the agent’s mandate widens with use, in a controlled way and with evidence behind it, instead of being fixed once on day one. It’s also why I treat deployment as a living thing and not a project with an end. Many pilots die precisely because nobody tends this cycle and exceptions pile up until they drown the operation, a pattern I analyse in why enterprise AI pilots fail.
Where exceptions sit in the whole
Designing the mandate boundary depends on two pieces that live in their own articles: the data the agent decides with, in what data an AI agent needs —remember that worse data forces a narrower mandate and therefore more exceptions; and the connection to the systems the case arrives and leaves through, in integrating AI agents with the ERP. Before you start, the readiness review in prepare your company for agents covers much of this work, which in turn frames within AI agents for business.
Frequently Asked Questions
What counts as an exception in an AI agent?
A case that falls outside what the agent’s mandate lets it decide. It isn’t the same as an error: I distinguish three origins: low confidence when the agent isn’t sure enough, out of policy when the case exceeds what’s authorised, and out of pattern when it resembles nothing known. A well-designed agent escalates all three instead of guessing.
How do you decide which cases the agent escalates and which it resolves?
With thresholds per exception type, starting conservative. Early on the agent escalates a lot, and control is relaxed only where the data proves reliability, never the reverse. Lowering the bar makes the agent resolve more but take on more risk. Raising it makes it safer but loads the people. There’s no universal number.
Who should an agent escalate an exception to?
To whoever can resolve it in one step, by competence rather than hierarchy: the credit exception to finance, the product one to operations, the commercial one to whoever owns the account. The goal is to keep the case out of a generic inbox that someone then has to sort.
How does an agent system improve over time?
By turning recurring exceptions into rules. When a case type is always resolved the same way, it has stopped being an exception and become an unwritten rule: it’s stated, tested against history, and the agent takes it over. The mandate widens with evidence, and the exception queue drops because it’s been learned from.