Human in the loop: designing the approval step so it is not the bottleneck

"A human reviews everything" is how most AI pilots get approved, and it is how many of them die six months later. The review queue grows with the volume, the reviewers rubber-stamp by week three because nothing they see is wrong, and the process ends up slower than the manual one it replaced, with an AI bill on top. Human in the loop is the right principle. The mistake is treating it as a single setting, on or off, instead of a design with thresholds, routing, sampling and a plan for withdrawing the human as the evidence comes in.

On the systems we ship, the approval step gets as much design attention as the model pipeline, because it is where the economics are decided.

Decide who reviews what, by amount and by risk

Full review is the correct starting point and the wrong steady state. The first refinement is thresholds. An invoice under a given amount with a matching purchase order posts without a look; above it, or with a mismatch, it waits. A support reply that changes nothing about the customer’s account goes out; one that promises a credit does not. The thresholds come from the business owner, in writing, and move with the measured error rate. The rules are deterministic and belong to plain automation rather than to the model. Document processing is where we have run this most often, and the pattern transfers to any workflow with a verifiable output.

The second refinement is confidence routing. The model, or better a validation layer around it, produces a score per item, and only items below a threshold go to the queue. This works when the score is calibrated: a system that says 90 percent should be right about nine times in ten on that slice, and we check that on a held-out set before trusting the routing. Uncalibrated confidence is worse than none, because it moves the human’s attention to the wrong items with a number that looks like evidence.

Sample instead of reviewing everything

Once the error rate on a slice is known, full review of that slice stops being a control and becomes a cost. We switch to sampling: a random share of auto-approved items goes to a reviewer, with the share set so that a change in error rate shows up within a day or two of normal volume. On several processes we run, the reviewer now sees a small fraction of items, and that fraction is where a new supplier’s invoice format gets caught.

A review screen that shows the evidence

The reviewer’s job is to decide quickly and correctly, and the interface decides whether that is possible. We put the model’s proposal next to the evidence it was based on: the extracted amount beside the highlighted region of the invoice, the proposed reply beside the ticket and the policy article it cites, the suggested match beside both ledger lines. Structured outputs matter here, because a field-by-field decision can be shown and corrected field by field, while a paragraph of prose can only be accepted or rewritten. Every correction is recorded as a labelled example and feeds the eval set and the next review of the thresholds.

Put an SLA on the queue and measure the reviewers

A queue without a service level fills up quietly. We set one (items older than a day raise an alert, a backlog above a limit pauses intake or widens auto-approval on the lowest-risk slice) and we report queue age next to accuracy, because a correct decision that waited four days is a failed one. We also measure the reviewers: how often they change the model’s proposal, and, on a sample, how often two reviewers agree with each other. When reviewer agreement with the model is as high as reviewer agreement with each other, the review on that slice is adding delay and nothing else, and that is the signal to widen autonomy. Review time is a cost, and an ROI measurement that counts every cost puts it on the ledger, where an untracked queue can turn a working system into a losing one.

Where the human stays, whatever the numbers say

Some decisions stay with a person at any measured accuracy. Money leaving the company above a floor. Commitments made to a customer in writing, such as a credit, a delivery date or a cancellation. Anything with legal weight, from a contract clause to a regulatory filing or a dismissal letter. Decisions that cannot be undone. For these the loop is the product, and the design goal is a fast, well-informed approval rather than a vanishing one. Everywhere else, the human should leave as the evidence accumulates, slice by slice, in writing, with the audit trail kept: what the model proposed, from what inputs, who approved it or which rule did, and when. That trail is what the auditors read, and in finance operations it is often the reason the project gets signed off at all.

The pilots that survive are the ones where the review step was designed to shrink. If yours was sold on "a human checks everything" and the queue is now the longest part of the process, the fix is a redesign of the loop rather than a better model, and that is a build we take on without replacing anything underneath.