Human in the loop: choosing where the approval goes
An approval step is the cheapest safety control and the easiest one to place badly. Put it too early and you have automated nothing; too late and you are rubber-stamping. Four placements and when each is right.
Every AI automation that touches something consequential ends up with a human in it somewhere. The design question is not whether, it is where — and the answer determines both how much time you save and how much protection you actually get.
The failure we see most is an approval placed where it satisfies an auditor and helps nobody: a person clicking "approve" on twelve hundred items a week, at four seconds each, catching nothing. That is not a control, it is a liability with a log.
Placement 1: approve the plan, execute automatically
The agent proposes what it intends to do, a person approves the proposal, the execution runs unattended.
Right when the action is complex, the stakes are in the decision rather than the mechanics, and the volume is low enough that a person can genuinely read the proposal. Infrastructure changes are the archetype: reviewing a Terraform plan is meaningful, watching it apply is not.
Placement 2: approve each action
Every write pauses for a decision.
Right only when volume is genuinely low — tens per day, not thousands — and each item carries real weight: a refund above a threshold, an email to a regulator, a production database change. Above a few dozen a day, attention collapses and you get the rubber stamp. If you need this placement at high volume, the honest conclusion is that the automation is not ready, not that the reviewer needs to be faster.
Placement 3: automate the confident, escalate the rest
The agent emits a confidence or matches a rule; clear cases go through, ambiguous ones queue for a human.
This is the right answer for most document and message processing, and it has the pleasant property of self-improving: the exception queue is your labelled data, and every threshold adjustment is measurable against it. The threshold itself is a business decision, not a technical one — it trades a cost per review against a cost per error, and those two numbers should be written down before anyone tunes it. Being explicit here is what separates a system that improves from one that is argued about.
Placement 4: act now, review after
The action happens immediately, a person reviews a sample or the exceptions afterwards.
Right when the action is reversible, the cost of delay is real, and the error rate is measured and low. Categorising support tickets, drafting internal summaries, tagging resources. Wrong for anything that leaves your company or moves money, because "reversible" stops being true the moment a customer has seen it.
The design rules that apply to all four
Show the evidence, not just the conclusion. An approval screen with a verdict and no supporting context produces automatic approval. Show the source document, the extracted values and what the rule matched, and the reviewer can actually work. This one change moves catch rates more than anything else.
Make the default nothing. A timeout that auto-approves converts your control into a delay. If nobody acts, the item should end up in a queue, not in production.
Batch same-shaped decisions. Twenty items of one type reviewed together are faster and more accurate than twenty interleaved with other kinds of work, because the reviewer builds a rhythm and spots the outlier.
Record the reason for every rejection. It is the highest-quality training signal in the entire system, and it costs one required field. Without it, you learn that something was wrong and never why.
Measure the reviewer. Track approval rate, time per item and — through sampling — accuracy. A reviewer approving 99.4 percent of items in three seconds each is telling you either that the automation is ready for placement 4, or that the control has stopped working. Both are worth knowing, and you cannot tell which without a sample.
What to do this week
Find the approval step with the highest volume in your company and measure two numbers: median seconds per decision, and rejection rate. If it is under ten seconds and under two percent, you have a control that is not controlling anything. Either remove it and move to sampled review, or make it small enough that someone can do it properly.