How to work an operations exceptions queue with an AI agent

The agent works the front of the queue; people decide the hard tail. It reads each exception, finds the cause, groups items that share it, and proposes a resolution with evidence. Routine repairs from the system of record run at depth 3. Anything that moves money, writes off a balance or affects a customer waits for a named person.

What is an exceptions queue, and who owns it?

Most operational processes run automatically until something does not fit: a payment rejected by the receiving bank, cash received with no matching invoice, a form that fails validation, a trade that does not match its confirmation. Those items drop into an exception queue, a work queue of items the straight-through process could not handle, for people to investigate and fix.

The operations team leader owns the queue and its ageing. Each exception type may have a specialist owner. The process owner upstream owns the root causes. Exceptions queues are often where experienced staff spend their days, because the work needs judgement and knowledge of the systems.

How is this different from the agent's own held queue?

An agent's held queue contains actions the agent has proposed and is waiting for a person to approve. The exceptions queue contains items the process could not complete, whoever ran it. The agent may produce entries in both: it can work an exception, propose a fix, and hold that fix for approval. Keep the two queues distinct so that approvers know what they are looking at. The routine for the held queue is in working through an AI agent's held queue each day.

What does the agent prepare, and what does a person approve?

1. Agent, depth 1: reads each new exception: the item, the error or reason code, and the related records in the source systems.
2. Agent, depth 1: diagnoses the cause from a list of known exception types: missing reference, wrong format, duplicate, amount mismatch, closed account, unknown counterparty.
3. Agent, depth 1: groups items that share a cause, such as forty rejections from one file with the same format error.
4. Agent, depth 3: resolves routine repairs of certified types, where the fix uses only data from systems of record and changes nothing of value: adding a missing reference the ledger already holds, correcting a known format issue, linking a duplicate to its original.
5. Agent, depth 2: proposes a resolution for every other item, with the evidence and the change it would make.
6. Person, named approver: approves resolutions that move money, re-release payments, post adjusting entries, write off small balances or affect what a customer sees.
7. Agent, depth 1: escalates items it cannot diagnose, or that fit no known type, to a specialist with what it found.
8. Agent, depth 2: drafts a root-cause note for each group, for the upstream process owner.
9. Team leader: reviews ageing daily and decides on items older than the target.

What does the approver need to see?

For each proposed resolution: the original exception, the agent's diagnosis and the evidence for it, the exact change proposed, and the provenance of every fact used. A payment re-release proposal should show that the corrected beneficiary details came from the system of record, not from an email chasing the payment. An external claim, however plausible, should never be the basis for releasing money.

Where does it usually go wrong?

Forced matches. Under pressure to clear the queue, the agent matches cash to the nearest invoice by amount. The queue shrinks; the ledger is now wrong in a way no one will notice until a customer complains. Matches need a reference or a rule, not a resemblance.

The easy items clear and the hard tail ages. The agent resolves the simple exceptions quickly, the queue count falls, and the remaining items, the difficult ones, sit for weeks. Report ageing, not just volume.

Root causes are never fixed. The agent repairs the same format error every day. It is efficient, but the upstream process stays broken. Each group's root-cause note must reach someone who can fix it, and the team leader should track whether they do.

Exceptions that need a person are worked by the agent. Some items are not process failures but judgement calls: a customer disputing a charge, a suspicious payment, an onboarding case outside policy. These have their own processes, such as handling onboarding exceptions. The agent should recognise them and route them, as described in how to handle the exceptions an AI agent cannot process.

Repairs widen quietly. A repair type certified for one file format is applied to another. Each repair type is a capability, certified separately.

Which controls leave evidence?

Known exception types. Evidence: the diagnosis and the type list version.

Certified repair types only at depth 3. Evidence: the repair type and certificate for each auto-resolved item.

Approval for anything of value. Evidence: the approver, the proposal and what they saw.

Provenance on every fact. Evidence: the source and class of each fact used in a resolution.

Ageing reported daily. Evidence: the ageing report and the team leader's decisions.

What should you measure?

• Queue size and ageing, by exception type.
• Auto-resolved items reopened, the key quality measure for depth 3 repairs.
• Proposals amended or rejected by approvers.
• Recurring root causes, and how many were fixed upstream.
• Escalations to specialists, and how many could have been diagnosed.

Where Pryme fits

In Pryme, each repair type is a separately certified capability, and every proposed fix carries the provenance of its facts. A fix that relies on an external claim to move money is refused by the minimum chain, and the verdict names the bound. The approach follows train, shadow, certify, widen.