When should an automation require human approval?

Let an automation run on its own when its actions are cheap and easy to undo. Make it stop for human approval when its actions are hard to reverse and hit many people or dollars at once. The axis that matters is not how often the bot is wrong. It is what one wrong action costs and whether you can take it back. A flow that misreads a lead every tenth run but only moves it to a different folder is safe to automate fully. A flow that issues refunds correctly 99 times out of 100 still needs a gate, because the hundredth refund is real money you cannot un-send.

Most advice on this gets the question backwards. It tells you to add review steps wherever the AI "might be wrong," which sends you chasing model accuracy. Accuracy is the wrong thing to optimize for here. A 95% accurate classifier that sorts support tickets is fine to run unattended, because the cost of the 5% is a misrouted ticket someone re-routes in a click. A 99.9% accurate process that wires money is not, because the 0.1% is a wire you cannot recall. Stop asking "is it good enough." Ask "what happens when it's wrong, and can I undo it."

Decide by reversibility and blast radius, not by accuracy

Two properties of an action tell you whether it can run unattended.

The first is reversibility. Can you undo the action with a cheap, available step? Amazon's Jeff Bezos framed this as two-way doors and one-way doors: a two-way door is reversible, you walk back through it if you got it wrong; a one-way door is not. Moving a CRM record to a different stage is a two-way door. Sending a client an email is a one-way door, because it is in their inbox the moment it sends. Deleting a customer's history with no backup is a one-way door with the handle removed.

The second is blast radius. How much does one action touch? Tagging one lead has a blast radius of one record. A bulk update that rewrites a field across 4,000 contacts has a blast radius of 4,000. Posting to your company's public profile has a blast radius of everyone who follows it. Same action type, very different exposure when it goes wrong.

Plot any automated action on those two and the decision falls out. Accuracy still matters for how good the automation is. It does not decide whether the automation is allowed to act alone. A frequently-wrong but reversible action is safer to automate than a rarely-wrong but irreversible one, every time.

The grid: four quadrants, four defaults

Place each action your automation can take into one of four cells, and the default control mode comes with it.

	Small blast radius	Large blast radius
Reversible	Full auto. Tag a lead, draft a reply, move a file, label an email.	Auto, but monitor after. Bulk CRM field update, batch enrichment, list re-segmentation.
Hard to reverse	Auto with a guardrail and a logged record. Charge a fixed $9 subscription, send one transactional SMS.	Approval gate or human-only. Issue refunds, run payroll, delete records, publish to production, email a full list.

The two cells operators get wrong sit on the diagonal. The top-right looks safe because each action is reversible, so people fully automate it and skip oversight, then a bad batch rewrites 4,000 records before anyone notices. The bottom-left looks scary because each action is irreversible, so people gate every single one, then a person spends their day approving $9 charges that were never in doubt. Reversibility and blast radius are independent. You have to read both.

Three control modes between all-manual and all-auto

The grid only works if you have more than an on-off switch. There are four settings, not two.

Full auto. The action runs with no person involved. Correct for the reversible, low-blast quadrant. Log it anyway so you can answer for it later, but do not make anyone watch it.

Human-on-the-loop, monitor after. The action runs, then a person reviews outcomes, usually just the exceptions or a sample, and can intervene after the fact. This is the right mode for reversible but wide actions, and for irreversible actions that are too high-volume to approve one at a time. The catch is that monitoring after only works if the run is recorded, so write the structured record described in what to log in every automation or there is nothing to review. Field to Flow, the field-to-office system at field2flow.geninfos.com, runs on exactly this pattern: most jobs flow straight through, and only the exceptions, a failed validation or a missing photo, get routed to a person. The human sees the 5% that need a human, not the 95% that do not.

Human-in-the-loop, approve before. The automation pauses, surfaces what it is about to do, and waits for a person to approve or reject before the action runs. Modern agent frameworks build this in directly: you mark a specific tool as needing approval, and the run records an interruption and stops there instead of executing, then resumes from the same state once a person approves. The model can read data, draft the email, and assemble the refund all it wants. It cannot send until a human says go. This is the correct mode for the irreversible, high-blast quadrant.

Human-only. Some actions should never be initiated by software at all. Firing someone, signing a contract, moving money to a new payee. The automation can prepare the packet and hand it over. It does not get the button.

A worked example: one contractor's eight automations

Take a small home-services company running automations across intake, billing, and marketing. Here is where each lands.

• New lead comes in, AI scores and tags it: reversible, one record. Full auto.
• Draft a follow-up email for the rep to review: reversible, one record, and a person is already the next step. Full auto on the draft, the send is the rep's.
• Send the booked-job confirmation text to the customer: hard to reverse, one record. Auto with a guardrail, because the cost of one wrong text is low and bounded.
• Nightly sync that updates job status across the whole CRM: reversible per record, but large blast radius. Auto, monitor after, with an alert if more than a set number of records change in one run.
• Generate and send invoices for completed jobs: hard to reverse, and it is money to customers. Gate it, or at least gate any invoice above a threshold amount.
• Issue a refund: hard to reverse, real money out. Approval gate, every time, regardless of amount.
• Post the monthly promotion to the company's public page: hard to reverse in practice and seen by the whole audience. Approve before publishing.
• Delete leads marked stale after 90 days: irreversible and potentially wide if the filter is wrong. Human-only, or at minimum a gated bulk review, never a silent cron job.

Notice that "send an email" appears three times and lands in three different modes. The action type told you nothing. Reversibility and blast radius told you everything.

Set the gate by threshold, not by the whole action

The fastest way to ruin an approval system is to gate too much. If a person has to approve every refund, they stop reading and start rubber-stamping, and the gate becomes theater. Gate by threshold instead. Auto-approve refunds under $50 where the AI's confidence is high, and pause only the ones over $50 or the ones where confidence is low. The aim is for the large majority of runs to flow through untouched and a person to see only the small slice that is both costly and uncertain.

This is also where the guardrail and the gate work together. A guardrail is an automatic check that blocks or flags before the action runs, no human needed: refund amount over the order total, recipient domain not on the allow-list, more records changing than the batch should ever touch. The guardrail catches the obvious-wrong cases for free. The approval gate catches the genuinely-ambiguous ones a rule cannot judge. Stack them, and the human only ever sees what actually needs a human.

One more honest caveat. A gated action can still break in the ways that have nothing to do with the gate: the approval fires, the action runs, and the downstream step silently fails. The approval step is not a substitute for the reliability work in why automations silently break. It decides who pulls the trigger, not whether the gun is loaded.

What to do next

Take your highest-stakes automation, the one that touches money or customers, and place every action it can take on the grid. Most will sit in the reversible, low-blast corner and should keep running untouched. You are hunting for the one or two actions in the hard-to-reverse, large-blast corner that are currently running with no person in the path. Those are where a single approval step earns its cost.

We build this layer into every workflow automation system we ship: full auto for the cheap reversible work, monitor-after for the wide reversible work, and a real approval gate on the actions that move money or cannot be undone. If you have a flow that is acting on its own and you are not sure it should be, send it to us and we will tell you which corner of the grid it belongs in.