Note: the story in this post is a hypothetical scenario assembled from common approval-queue failure patterns — not an account of any real company.
The approval queue at a 60-person logistics company worked perfectly for eleven days. On day twelve, the ops lead who owned it got 300 approval requests. Refunds, address changes, carrier bookings, invoice corrections. She approved them all between meetings, mostly without reading, because the alternative was a backlog of angry customers. By week three, the queue was theater: every request approved, nothing actually reviewed. The team had built a human checkpoint and then trained the human to wave everything through.
This is approver fatigue, and it kills more approval queues than any technical failure. The queue itself was fine. The design assumed a human could carefully review hundreds of decisions a day, forever. Nobody can. So they rebuilt the queue around a different assumption: the human's attention is the scarcest resource in the system, and the queue's job is to spend it only where it matters.
Step one: stop asking about the boring stuff
The first change was risk tiers. Every action the agent could take got sorted into three buckets:
- Low risk: log, don't ask. Reading records, drafting messages, searching. These never hit the queue at all. They just get logged with enough detail that an audit can reconstruct them. This alone removed 60% of the daily requests.
- Medium risk: batched review. Updating a delivery address, booking a standard carrier, correcting an invoice under $200. Real consequences, but routine. These go into a digest the approver reviews three times a day, with a target of clearing each digest in under five minutes.
- High risk: interrupt now. Refunds over $50, any external message sent as the company, deleting records, changing payment details. These push a notification immediately, with the full context attached: what the agent wants to do, why, and what happens if it's wrong.
The key insight was that most approvals were medium risk, and medium risk doesn't need a real-time human. It needs a recent human. A three-times-daily digest keeps the delay under three hours for routine items while costing the approver fifteen minutes a day. The old system promised real-time review of everything and delivered exhausted rubber-stamping of everything. The new system promises timely review of the things that matter, and it keeps the promise.
Step two: auto-approve lists with expiry dates
Some approvals are so routine they're basically paperwork. The same carrier booking for the same weekly route. Address corrections for the same three corporate clients. The team built auto-approve lists: specific action-plus-target pairs that skip the queue entirely for 30 days, then come back for re-review.
The expiry is the whole trick. A permanent auto-approve list is just a hole in your policy that grows over time. A 30-day list forces a recurring question: is this still routine? Twice now the re-review has caught something: a "routine" carrier booking whose rates had quietly doubled, and an address-correction pattern that turned out to be the agent compensating for a broken address form. The lists saved the approver about 40 decisions a day, and the expiries caught the two cases where "routine" had stopped being true.
Step three: batch the similar ones
The digest view groups identical action types together. Twenty address corrections appear as one card: "20 address updates, total value $0, all for existing customers." One tap approves all twenty, or the approver can expand and pick through them. Sorting matters here: the digest sorts by value and novelty, so the unusual items surface first. The approver's eyes land on the weird ones, not the twentieth identical booking.
Batching has a failure mode worth naming: it hides outliers. An approver tapping "approve all" on twenty items isn't reviewing twenty items. The team handles this by flagging statistical outliers inside batches (the one refund that's 4x the others, the address change to a country the company doesn't serve) and pulling them out of the batch into individual review. Batch the routine, isolate the strange. That's the whole game.
The numbers after tuning
Three months in: median approval time went from 47 minutes to 92 seconds for high-risk items. The approver's daily touches dropped from ~300 to ~25. Queue backlog at end of day went from "dozens" to zero, consistently. And the metric they cared about most: sampled re-reviews (a random 5% of approved items, checked weekly by a second person) found the approval quality actually improved. When a human reviews 25 things instead of 300, they read them.
The 5% sampling deserves emphasis. It's the only reason they know the queue works. Without it, "approvals are fast" could just mean "approvals are sloppy." The sample caught one real miss in the first month: a batched invoice correction that should have been high risk. The tier definitions got tightened. Measure the quality, not just the speed.
What still breaks
Fatigue comes back. The ops lead who owned the queue burned out on it after five months. Not from volume, which was fine, but from the ambient stress of being the person who says yes to money moving. They now rotate the approver role monthly across three trained people. Rotation costs a little consistency and buys a lot of sustainability. If your queue depends on one heroic reviewer, you don't have a process. You have a person.
Also: tiers need maintenance. Actions drift between tiers as the business changes. A "medium risk" action becomes high risk when the amounts involved grow. The team reviews tier assignments quarterly, same cadence as their allowlist review. A queue tuned once and forgotten will be wrong within a year. The business it governs won't sit still.
And the honest limit: no queue design fixes an agent that generates bad requests. If 30% of what reaches the approver is nonsense the agent shouldn't have attempted, the problem is upstream, in the agent's instructions or its action policy. The queue is a checkpoint, not a filter for a broken agent. Fix the agent first, then tune the queue.
The short version
Tier every action by risk. Log the low-risk stuff, batch the medium-risk stuff into digests, interrupt a human only for high risk. Auto-approve the genuinely routine with 30-day expiries. Batch similar items but isolate outliers. Sample 5% for quality. Rotate your approvers. The goal was never "a human sees everything." It's "a human who isn't exhausted sees the things that matter." The policy playground shows the risk-tier engine in action: feed it an action log and watch which calls land in require_approval.
What a good approval request actually looks like
Here's the uncomfortable truth about approval queues: the queue isn't the product. The request is the product. An approver deciding in ten seconds versus stalling for an hour comes down to what the request shows them. Most queues fail right here, showing the approver something like this:
Agent wants to: issue_refund. Approve / Deny.
That's a coin flip, not a decision. Nobody can responsibly approve that. So they either rubber-stamp it or let it sit — which is exactly how you get theater. Now compare with a request built like someone's actual attention is on the line:
issue_refund — $42.00 to customer #88312 (2 prior orders, no prior refunds). Ticket: "charged twice for September." Agent checked the billing log: two charges, 40 seconds apart, same invoice number. If this is wrong: the customer gets $42 they weren't owed. Approve / Deny / Ask the agent for more.
Action, target, amount, the customer's own words, the evidence the agent already gathered, and — this is the part most queues miss — what happens if the request is wrong. An approver can decide that in ten seconds, because the decision has been pre-chewed. The cost of the mistake is stated plainly, which means the approver is calibrating against reality instead of vibes.
The "ask the agent for more" button earns its keep here. Maybe the billing log check isn't enough and the approver wants the order history. One tap sends the request back with a note, and the agent gathers more evidence instead of the approver doing detective work. The queue stops being a bottleneck the moment approvers stop leaving it to go look things up themselves.
Timeouts: the decision you make in advance
Every queue needs an answer to the question nobody wants to ask: what happens when nobody answers? An agent waiting on an approval that will never come is its own incident. It stalls, the customer waits, and nobody knows anything is wrong — the request just sits there, aging. So you decide in advance, per tier:
- High risk: auto-deny after the timeout. Fail closed. If nobody approved a $500 refund within 15 minutes, the answer is no, and the agent gets told why — so it can try a different approach, like offering the customer a callback. A denied-with-reason lets the agent recover gracefully. Silence doesn't.
- Medium risk: hold until the next digest. The item rolls into the next three-times-daily review. It's already budgeted for; no drama.
- Low risk: never reaches the queue at all. Logged, not asked. Timeouts are irrelevant for things you don't ask about.
One more rule: escalate before the timeout, not at it. If high-risk items time out at 15 minutes, the secondary approver gets pinged at 5 minutes unacknowledged. The timeout should almost never fire — it's the backstop, not the workflow. If your timeouts fire regularly, your tiers are lying about how fast your team actually responds, and the queue is theater again.
And set the numbers from measured reality, same as budget caps from measured spend. If your high-risk median response time is 92 seconds, a 15-minute timeout is generous. If your team's actual response time is four hours, no timeout policy will save you — fix the approver load first (rotation, fewer tiers, smaller digests), then set the timeout. Policy written against imaginary response times is decoration.
FAQ: approval queues for AI agents
- How do I stop approver fatigue from killing my approval queue?
- Tier every action by risk: low-risk actions get logged, never asked about; medium-risk actions batch into digests reviewed a few times a day; only high-risk actions interrupt a human immediately. In one walkthrough this cut daily approver touches from ~300 to ~25 and median high-risk approval time from 47 minutes to 92 seconds — because a human reviewing 25 things actually reads them.
- What should an approval request show the approver?
- The action, target, and amount; the evidence the agent already gathered (ticket text, billing checks); and what happens if the request is wrong. An approver can decide a well-formed request in ten seconds. A bare "agent wants to do X — approve/deny" is a coin flip that produces rubber-stamping or stalling.
- What happens when an approval request times out?
- Decide per tier in advance: high-risk requests auto-deny (fail closed) with the reason sent back so the agent can recover gracefully; medium-risk items roll into the next digest; low-risk actions never reach the queue. Escalate to a secondary approver before the timeout fires — the timeout is the backstop, not the workflow.