Dashboards report what an agent did. The held queue shows what it could not do alone, and why. Read it closely and it tells you whether the agent's limits sit in the right place, whether its sources are good enough, and whether the people behind it have the capacity to decide. Summary metrics smooth all of that away.
What is the held queue, exactly?
It is the set of actions an agent has drafted that are waiting for a named person to approve, edit or refuse. An action lands there because one of its bounds said a person must decide: it exceeds a customer limit, relies on a source too weak for the action, or sits above the depth the agent is certified for on that capability. It is a specific kind of exception queue, one where every item arrives with a draft and a reason.
That reason is what makes the queue so informative. Every item carries the bound that put it there. A dashboard showing "held: 140 today" loses it. The queue keeps it.
What can the queue tell you that a dashboard cannot?
Three things, each found by reading the queue in a particular way.
By deciding bound: are the limits right? If most items are held by the same customer limit, and approvers approve nearly all of them unchanged, the limit is probably set below where the business is comfortable. If they refuse many, it is probably right. If items cluster on the certificate bound, the agent is being asked to act above its proven depth, which may mean it is ready to widen or that the work is being misrouted.
By source: is the evidence good enough? Items held because a fact came from a weak source point straight to a data problem. An accounts payable agent whose items are repeatedly held because the supplier's bank details arrived by email, not from the vendor master, is telling you the vendor master is incomplete. A finance agent that holds reconciliations because it cannot see the ledger entries it needs to match against may simply lack read access; our argument that finance agents need read access to more than they can change addresses exactly that.
By age: is the staffing right? Items that sit for hours or days point to too few approvers, approvers with the wrong authority, or approvers with no protected time. Ageing items are often the first sign that review is about to become rubber-stamping.
How should the queue be read each day?
With a small number of questions, asked in the same order every time.
| Question | What a worrying answer looks like | Likely cause |
|---|---|---|
| How many items arrived, and is that normal? | A sharp rise or fall | New work type, source failure, or a bound that stopped working |
| Which bounds are holding them? | One bound dominating unexpectedly | Limit set wrongly, or a source has degraded |
| What did approvers decide? | Almost all approved unchanged, or almost all refused | Limit too tight, or agent proposing poorly |
| How old is the oldest item? | Older than the service target | Staffing or authority gap |
| What did approvers edit? | Amounts or outcomes changed, not wording | Agent quality has slipped on this capability |
A held queue daily review checklist turns these into a routine, and our playbook on working through an AI agent's held queue each day covers the operational side.
Why do dashboards hide these signals?
Because they aggregate, and aggregation removes reasons. A dashboard typically shows automation rate, volume, time to resolve and perhaps a held-item count. Each is a summary. An automation rate that holds steady can hide a shift from one bound to another. A falling held count can mean the agent improved, or that a limit was raised, or that a bound stopped being checked. The dashboard cannot tell these apart.
Dashboards also tend to be built for sponsors, who want to see progress. The held queue is built for the people doing the work, who need to see problems. Both have their place, but only one shows you what is going wrong while there is still time to fix it.
What does a healthy held queue look like?
Steady volume that tracks the work coming in. A mix of deciding bounds that makes sense for the agent's capabilities. Approvers making real decisions: approving most, editing some, refusing a few, with reasons. Items cleared within the agreed time. And, over months, a falling share of items held by the certificate bound as the agent earns depth on more capabilities.
An unhealthy queue looks like any of the opposite: volume swinging with no explanation, one bound dominating, approvers approving everything or refusing everything, items ageing, or no change in the certificate share because nobody is assembling evidence to widen.
Who should own reading the queue?
The agent operations lead, if there is one, or the process owner. Not the approvers alone, because they see items one at a time and are focused on deciding them, not on reading the pattern. Approvers are a vital source, though: they notice when items start to feel different, and there should be a simple way for them to say so.
Staffing the queue is a separate decision with its own trade-offs; our guide on staffing the queue of actions AI agents hold covers it. The person reading the pattern needs to be able to change staffing quickly when ageing appears.
What is the trade-off?
Reading the queue takes time every day, and it takes some skill to tell a meaningful shift from noise. It also produces findings that are uncomfortable: limits that were set badly, sources nobody owns, approvers without enough time. Dashboards rarely make anyone uncomfortable, which is part of why they are popular.
The queue's discomfort is its value. Every finding it produces is cheaper to act on than the incident it would otherwise become. Spend fifteen minutes each morning with your agents' held queues, grouped by deciding bound, sorted by age, with approvers' decisions alongside. Keep the dashboard for the sponsor. The deployment approach that depends on reading these signals is set out in our guide to deploying an AI agent: train, shadow, certify, widen.
Questions people ask
Should the goal be an empty held queue?
No. An empty queue means either the agent never needs a person, which is unlikely for consequential work, or the bounds are too wide. The goal is a queue that holds the right things and is cleared on time.
How is the held queue different from a list of refused actions?
Held items are within reach of the agent but need a named person to approve them, so they arrive as drafts. Refused actions are outside the agent's bounds altogether and are routed elsewhere without a draft for approval. Both are worth reading, for different reasons.
Can held items be cleared in bulk during a spike?
Only with care, and the bulk decision should be recorded as such, naming who made it. If a spike is caused by a limit set too low, fix the limit; clearing in bulk without review defeats the purpose of the hold.