Every agent that touches real work will meet a case it cannot place. The invoice matches two purchase orders equally well. The email says "same as last time" and there is no last time. A field that has held a date for two years now holds the word "pending". What the agent does in that second decides whether anyone still trusts it in month three.
Most teams treat this as an edge case and build it last. It should be first. The escalation path is the load-bearing part of the design, because it is the only thing between a confident agent and a quiet mess in your records. Treat it as real software, not as a Slack message with a shrug attached.
What "unsure" means in code
An agent has no feeling about a case. It has checks, and each check fails in a way you can name. Four of them show up in almost every workflow.
Missing input. The agent needs a field that is empty or a document that never arrived. This is the easiest escalation to write, because the reason is obvious and the fix is usually a person sending a file.
Ambiguous match. Two candidates score close enough that picking one is a coin flip. The useful test is not the top score, it is the gap between the top two. A best match at 0.91 with a runner-up at 0.89 is far less certain than a best match at 0.74 with nothing else above 0.30. Score-only thresholds miss this, which is why the same agent can be wrong most often on the cases it rated highest.
Rule conflict. Two rules apply and they point in different directions. The customer sits on a payment hold and the order carries an urgent flag from sales. No agent should settle that alone, whatever its confidence number says. It is a business decision wearing a data problem's clothes.
Out of range. The value parses, the match is clean, and the amount is four times larger than anything this workflow has seen in a year. Keep a running distribution of what each agent writes, and escalate the tail. This one catches the failures nobody wrote a rule for.
Write these as separate checks rather than blending them into one score. A single number tells a reviewer that the agent hesitated. It does not tell them what to look at, so they rebuild the reasoning from scratch on every item, and after a week they stop reading and start approving.
Attach the reason where the check fails
An escalation is a record, and the record gets written at the moment the check trips. Reconstructing it afterwards from logs is guesswork, and it is the difference between a reviewer deciding in forty seconds and a reviewer opening four browser tabs.
Six fields cover it. Which workflow and which run. Which case, with a deep link into the system of record rather than an ID to copy. Which check failed, named in the words the team uses. The evidence the agent had, including the two candidates it could not separate. What the agent would have done if it had been forced to choose. The timestamp.
That fifth field earns its place twice. It gives the reviewer a default to accept or overrule, which is quicker than starting from nothing. It also builds the dataset for later. Once a few hundred escalations carry the agent's suppressed answer next to the human's decision, you can measure how often the agent would have been right.
If a check cannot produce a sentence the team would understand, the check is not finished. "Confidence 0.62" fails. "Two open POs from the same supplier for the same amount, 4,180.00, both dated in the last ten days" passes.
Size the queue before go-live, not after
The queue has a capacity, and it is set by a person's calendar. Do the arithmetic during the build.
Take a workflow that runs 2,000 times a month. At an 8 percent escalation rate that is 160 items, roughly 40 a week. If the median review takes four minutes, that is under three hours a week, which one person absorbs without much thought. Now hold the same workflow at a 30 percent escalation rate. That is 600 items a month, 150 a week, ten hours of review. You have not removed a job. You have converted it into a worse one, where someone reads the agent's homework all day instead of doing the work.
So agree on a ceiling before go-live, in items and in review hours per week. Shadow mode gives you the real escalation rate against real volume. If the rate sits above the ceiling, the answer is not a bigger queue. Narrow the scope until the agent handles a smaller slice cleanly, and leave the rest with the humans who are already doing it.
Why queues become second inboxes
A queue rots for reasons that have nothing to do with the agent's quality.
It has no owner. Items land in a channel, everyone assumes someone else has it, and the oldest item is four days old. Assign at the moment of filing, by rule, to a person. A group is not an owner.
Resolving an item is paperwork instead of work. If the reviewer has to make the decision in the queue and then repeat it by hand in the CRM, the queue is a to-do list about work rather than the work. Every decision in the queue should write back to the source system, with the reviewer named in the log.
Age is invisible. Show the age of every item, sort oldest first, and put one number at the top: the age of the oldest open item. Anything that tracks depth but not age lets a few hard cases sit forever while easy ones cycle through.
Nothing stops. Set a hard limit on depth and age, and when it breaks, the agent stops auto-handling and pages a named person. An agent that halts is an annoyance. A queue that silently grows while the agent keeps writing is how you find out in March that February was wrong.
Notifications fire per item. One digest at a fixed time, plus a page when the limit breaks. Forty pings a week trains people to mute the channel, and then the queue is invisible as well as slow.
Lowering the threshold is an arithmetic decision
At some point someone will say the agent is too cautious. Maybe it is. That is a question with an answer, and the answer is not a feeling about how well things are going.
You need three numbers. How often the agent would have been right on the items it escalated, which you have if every escalation recorded its suppressed answer. What a wrong auto-handled decision costs, in money or in time to unwind. How many review minutes the change gives back.
Then run it as a trade. Suppose dropping the threshold moves 200 items a month from the queue to automatic handling. That is around 13 hours of review returned at four minutes an item. If the agent's suppressed answers were right 97 percent of the time, you are also buying about six wrong decisions a month. Whether that is a good deal depends on what the wrong ones do. Six mislabelled internal tickets, obviously fine. Six wrong payment runs, obviously not.
Reversibility decides more of these than accuracy does. Drafting, tagging, routing and internal notes can all run at a looser threshold, because a mistake costs a correction. Anything that leaves the building or hits a ledger stays strict even when the agent looks excellent, because the recovery cost is what you are insuring against.
Change one threshold at a time, and write down the escalation rate you expect before you change it. If the real rate moves further than that, something in your picture of the workflow is wrong, and that is worth finding before the next adjustment.
An agent reporting a 2 percent escalation rate in its first week is not a good sign. It usually means the checks are too coarse to notice the cases it is getting wrong. Start cautious, let the queue teach you where the real ambiguity sits, and tighten later with numbers on the table.