We let an AI close 4,812 support tickets. It got 61 of them wrong. Here is every category.

Every AI support vendor will tell you their accuracy figure. It is always somewhere between 92% and 97%, it is always measured on a benchmark they chose, and it is completely useless to you.

Here is the number that is useful: what did the wrong ones look like? Not how many. What kind. Because the failure taxonomy is what determines your architecture. Nine hundred harmless errors and nine catastrophic ones are the same accuracy figure and two entirely different products.

So: across a supervised support deployment, 4,812 tickets handled end to end by an agent with real write access to an ERP. 61 got it wrong — either rejected at the approval queue for a substantive reason, or executed and later recalled. Every one fell into one of six buckets.

1. Right action, wrong amount — 19 of 61

The single largest category, and the most reassuring one. The agent correctly determined that a credit was owed, correctly identified the order, and got the number wrong — usually by including or excluding freight, occasionally by crediting the full line when only part of it shipped short.

This is a boring, mechanical failure and it has a boring, mechanical fix: any monetary action recomputes its amount from structured system data rather than from anything the model produced, and the proposal fails validation if the two disagree. The model decides whether; arithmetic decides how much. After that change this bucket went to near zero.

2. Right answer, wrong customer context — 14 of 61

Answers that were correct in general and wrong for this account: quoting standard freight terms to a customer with a negotiated freight agreement, quoting list pricing to a contract account, applying the consumer returns window to a trade account on terms.

This is a retrieval failure wearing a model failure's clothes. The account's exemptions existed — in a different system, in a field nobody had mentioned during discovery. The fix was to make account-level policy overrides a mandatory part of the retrieval context, and to have the agent abstain outright when a customer record carries a contract flag it cannot resolve. Abstaining is a feature.

3. Missed escalation signal — 11 of 61

The agent handled an angry customer politely and competently, four separate times, without noticing that "this is the fourth time I have written about this" is itself the most important fact in the message. Each individual reply was fine. The sequence was a disaster.

Models are bad at this because each turn looks locally reasonable. The fix is not a smarter model, it is a hard structural rule: more than two prior AI-handled contacts on the same order goes to a human, regardless of confidence, regardless of sentiment. Repeat contact is the loudest quality signal in any support queue.

4. Correct but unauthorised — 8 of 61

The agent proposed an action that was arguably the right thing to do and that it had no business doing: waiving a restocking fee, extending a return window as a goodwill gesture, promising a delivery date the warehouse had not committed to.

Note the word "arguably". A human agent might well have made the same call. The difference is that a human has judgement about when to spend the company's money and an agent has a policy document. Everything with a discretionary component stays behind approval permanently. Not because the agent is worse at it — because discretion is not a thing you delegate to a system that cannot be held accountable for it.

5. Hallucinated capability — 6 of 61

Six times, the agent told a customer the company could do something it cannot: expedite via a carrier service they do not have an account for, split a shipment across two addresses, take payment by a method they do not accept. None of these were in the grounding corpus — they were in the model's general picture of how distributors work.

The fix is to constrain generation to declared capabilities: an explicit allowlist of what the business does, injected as a hard constraint, with the agent required to cite a capability before promising one. It is unglamorous and it works. Grounding stops the model inventing your policies; a capability allowlist stops it inventing your operations.

6. Right on everything, wrong on tone — 3 of 61

Three rejections were purely stylistic: correct action, correct amount, correct policy, and a reply so brisk that the reviewer would not have sent it to a customer who had just had a bad week. These are worth counting, because a queue that only tracks factual errors will drift into something technically accurate that customers quietly hate.

What the distribution tells you to build

Look at the shape of it. Fifty-two of the 61 errors were context and authority failures, not reasoning failures. The model was not confused about what the customer wanted. It was missing a fact about the account, missing a signal about the history, or reaching past its remit.

That is genuinely good news, because those are all engineering problems with known solutions: better retrieval, hard structural rules, recomputed values, capability allowlists, permanent approval on anything discretionary. None of them require the model to get smarter. All of them require somebody to have looked carefully at the failures.

The reason to run every action through an approval queue at first is not that AI is untrustworthy. It is that the queue is how you find out what your failure taxonomy actually is, on your data, in your business, at zero risk. You cannot design the gates until you have seen the failures, and the queue is the cheapest possible way to see them.