How do you handle the exceptions an AI agent cannot process?

Sort them, route them, and learn from them. Give every exception a named type, route each type to the team that resolves it, and let the agent prepare everything it can before handing over. Record how each was resolved. Each month, decide which exception types should become rules the agent follows, and which should stay with people for good.

Why do exceptions need their own design?

Because they are where the work is hardest and the risk highest, and they tend to pile up. Without design, every case the agent cannot handle lands in one queue labelled "exceptions", where an urgent fraud flag sits behind a missing purchase order. The queue grows, ageing items get cleared in a rush, and the cases that most needed care get the least.

Exceptions are also the best source of improvement. Each one shows a gap in the process, the sources or the agent's role. Captured well, they shrink over time. Ignored, they become permanent manual work.

How should exceptions be classified and routed?

"Could it become a rule?" is the column that drives improvement. Some exceptions are really missing rules. Others exist because judgement is the point; those should never be absorbed.

What are the practical steps?

1. Define the exception types from the process document and from what shadow running shows.
2. Route by type, each to a named queue with an owner and cover.
3. Let the agent prepare. It completes every step it can and hands over only the part it cannot do, with its sources.
4. Set ageing limits per type. A risk flag needs hours; a missing purchase order can wait days.
5. Record the resolution in a structured way: what was decided and why.
6. Review monthly. For each type, volume, resolution time, and whether a pattern in resolutions suggests a rule.
7. Absorb deliberately. If a type becomes a rule, the process owner writes it, the procedure is updated, and the agent is re-tested before handling it.

Working the queue itself day to day is covered in how to work an operations exceptions queue with an AI agent, and onboarding has its own variant in handling onboarding exceptions with an AI agent.

What does this look like in practice?

Take a manufacturer's accounts payable team. The agent matches invoices to purchase orders and goods receipts. A steady share of invoices become exceptions, nearly all in one queue.

The team splits the queue into five types. The monthly review shows that most "missing purchase order" exceptions come from three utility suppliers who never quote one. The process owner writes a rule: utility invoices are matched to the contract and the meter reading instead. The rule is added to the procedure, the agent is re-tested on past utility invoices, and that exception type nearly disappears.

The review also shows that "price differs from order" exceptions are resolved in many different ways, depending on the supplier relationship. That type stays with people. The agent now prepares a summary of past price differences with that supplier, which shortens the time each one takes.

Which controls keep exceptions under control?

• Named types and named owners for each queue.
• Ageing limits by type, with escalation.
• Structured resolutions, so patterns can be seen.
• Re-testing before absorbing any type into the agent's work.
• Shadow running before go-live, because live work shows exceptions that test sets miss; see what shadowing proves that testing cannot.
• Process documents kept current as rules are added; see documenting an AI agent's process.

Exception types found in shadow running should be settled before the agent widens; see deploying an AI agent: train, shadow, certify, widen.