You ship the agent, the dashboard says it resolves 90% of cases, and the savings show up nowhere. Not in hours, not in cost, not on the face of the person who used to do that work. The dashboard isn't lying: it measures what the agent does. The savings are decided by what it doesn't do. (The 90% is an illustration of the pattern, not a figure from any client.)
The thesis in one line: an automation with no owner for its exception queue doesn't save hours, it moves them somewhere else and hides them. The work the agent can't resolve doesn't disappear; it changes hands, loses the context it had, and stops being counted where the savings were being checked.
An AI agent's exception queue: the 10% that decides whether you save
An exception queue is the list of cases the agent can't resolve, or doesn't dare close, and leaves for a person. Every agent has one, even if nobody calls it that: a mail folder, a chat channel, a “review” tab in a spreadsheet, a strange status in the CRM. What changes from one company to another isn't whether it exists, but whether it has an owner.
The pattern repeats almost every time. In month one the exceptions are few and whoever built the agent looks at them, curious. By month three there are more, whoever happens to pass by sees them, and nobody prioritises them. By month six the queue is a graveyard: cases weeks old, customers who have written twice, and a collective habit of closing with “resolved another way” whatever nobody has investigated. The share of cases the agent resolves is still high. The savings no longer are.
What do we know about what happens to alerts nobody handles?
Little about business agents, and it's worth saying so. The closest data comes from network operations. On 23 September 2026, Cisco published a survey run by Omdia among 1,000 IT and network operations leaders at organisations with more than 500 employees in North America, Western Europe and Asia-Pacific. According to Cisco's release, nearly half of network alerts are closed without investigation, an almost identical share of respondents say investigation time goes on chasing false positives, and the average organisation generates about 4,100 monitoring alerts and events a day. Clearing the daily network-alert backlog by hand would, per the same report, take roughly 100 IT specialists (Cisco press release, 2026-09-23).
Three caveats before you use it. It's a survey published by a vendor that sells exactly the solution to that problem. It's about network operations, not business operations. And it isn't a measurement of the US or of any single country. It doesn't describe what happens to your invoicing agent. We use it as a leading indicator: when what needs looking at exceeds what a person can look at, the rational move is to close without looking. Your queue will be smaller, but the mechanism is the same.
Why does an ownerless queue hide the savings instead of losing them?
Because the work doesn't vanish, it changes shape. Before, one person did the whole case. Now the agent clears the easy stretch and the hard one lands on someone with other things on their plate, without the context the old process had. Each exception costs more than a normal case and, on top of that, it's invisible: it doesn't show up in the agent's dashboard, it shows up as lost time in the calendars of three different people.
- The hours the dashboard says it freed are spent putting out exceptions, spread across people who don't count them.
- The hard cases tend to be the most valuable ones: the big customer, the odd amount, the complaint.
- What gets closed without investigation isn't learned from. The agent doesn't improve because nobody tells it why it failed.
It's the same trap that explains why freed hours are not savings: you count what the agent removes and not what reappears elsewhere. And it isn't the problem of the metric that makes your agent lie: there, what's measured fails; here, the shift fails. Nobody is assigned to look at what's left.
What should be written down before you switch the agent on?
Four things, on one page, before the first production run:
- Who watches the queue. A name and a backup, not “the team”. If the answer is “whoever can”, nobody does.
- How often. One or two fixed slots a day, not “when there's a gap”.
- What the SLA for an exception is. How long a case can wait before it counts as a breach, different by customer or amount.
- What happens when the queue grows two weeks running. A trigger rule: the agent's expansion is paused and you review why so many cases are coming in.
The fourth is the one almost nobody writes, and it's what turns the queue into a management instrument instead of a bucket. A growing queue isn't a people problem: it's a sign the agent resolves less than it thinks, or that what reaches it has changed. The guide to measuring the performance of your automations counts exceptions per week as one of the key metrics; here we add the owner and the shift that metric needs to be of any use.
Who should handle exceptions: a person, a team or another agent?
It depends on what the error costs. If the cost is low and the volume high, another agent can triage and resolve with stricter rules. If it's high and infrequent, it goes to a person with judgement and the authority to decide. It's the same logic as where to put human validation without killing the savings, applied to what's left after the agent has done its part.
When volume grows, goodwill stops being enough and you need human oversight of AI at scale: shifts, sampling and written criteria. And for whoever handles an exception to reconstruct what happened, they need traceability of AI decisions. Without it, every exception is investigated from scratch or not at all.
How do you know if your exception queue is already dead?
With a ten-minute test. Ask three people who touch the process how many exceptions there were yesterday and how many are still open. If they give you three different numbers, or none, the queue has no owner. Then sort the open cases by age and compare the oldest with the SLA it should have. If there's no SLA, you have your answer.
A second sign is the closing reason. If most exceptions are closed with a generic label and no note on what happened, the queue is working as a wastebasket, not as a source of improvement. Every well-closed exception should be able to go back to the agent as a test case.
When this doesn't apply to you
If your agent handles low volume and the cost of an error is trivial, a formal queue is bureaucracy: a daily summary to one person is enough. It also doesn't apply if the exception already has a natural owner, like the inbox of a support team with its own on-call rota. That changes when exceptions from several agents land in the same place, or when nobody could say how many there were yesterday.
The line to take away: an agent's savings aren't measured in what it resolves, but in what's left after counting what it doesn't resolve and who picks it up. Before you switch it on, put a name on whoever watches the queue.