Human approval in AI workflows: which steps stop for a person, and which just run

Stop the workflow at the last point where you can still change the outcome cheaply. Two things trigger a stop: the next action is one you can't take back from inside your own business, or the step is about to decide something your source material doesn't answer. Everything before that runs.

The common version of this rule stops anything that leaves the business. It sorts two everyday steps into the wrong bucket.

TL;DR

• Test one step at a time with three questions. If this step gets it wrong, who finds out? Can I put it back from inside my own business in the next ten minutes? Is the answer in the source material I gave it? A bad answer to any of the three means the step stops for a person.
• Reversibility beats location. Overwriting your own customer record never leaves the building and can't be undone. An internal status email to your crew is a send, and if it's wrong you send another one.
• The step almost nobody gates is triage: the one that decides something needs no reply. Nothing gets sent, so it looks safe, and the mistake is invisible by construction.
• Drafting runs. A draft is a proposal you can read against your own material, so the person reading it also catches the classification and extraction errors upstream of it.
• When a fact isn't in the source material, the step stops and says what's missing. That instruction belongs in Rules, one of the five inputs.
• A gate has to be cheaper than doing the job by hand, or your team quietly routes around it. Show the source beside the output, allow an edit, and list what the assistant couldn't confirm.
• Read your own approval queue to check the placement. Approving nearly everything unchanged means the gate is in the wrong place. Changing nearly everything means the step isn't ready to be in the workflow.
• Payments and refunds get two approvals from two different roles. Access changes get an approver who owns security.
• The public workshop runs a full day at Avani Mooloolaba Beach Hotel in The Cove room. A seat is A$495 excluding GST per person, places are capped at 15 paid attendees, and the next date is Wednesday 7 October 2026.

Which steps in an AI workflow should stop for a person?

Take the workflow one step at a time and ask three questions about each step.

Start with the first question: if this step gets it wrong, who finds out? A person reading a draft finds out, before anything moves. A customer reading a sent email finds out, later and worse. The answer that should worry you is nobody, which happens more often than owners expect.

Then ask whether you can put it back from inside your own business, in the next ten minutes. Judge that in practice, with the tools you actually have. An email is gone once it's sent. Recovering a payment needs the other party's cooperation. A note on a customer record can be edited by whoever notices. The question separates the steps where your attention buys something from the steps where it buys nothing.

The third question is whether the answer is in the source material you gave it. A step that has to invent a figure needs a person regardless of how small its consequences look, because the invented figure travels into every document downstream of it.

Run those three over an ordinary quoting and follow-up workflow and the gates place themselves.

The published guidance converges on the same place. StackAI's rule for enterprise agents is to require approval when the next action is irreversible, costly, regulated or high blast radius, with read-only work such as retrieval, classification and drafting able to run autonomously, and write actions and external communications supervised by default. 1 JMG Group puts the checkpoint immediately before the irreversible step rather than after every model call. 2 Workflow Builder ranks the action on reversibility, volume and latency tolerance, and argues the placement falls out of those three properties. 3

Volume and latency decide the design at ten thousand runs a day. The businesses I work with run ten. At that size the binding question is the first one: which of these mistakes would anyone ever see?

Reversibility beats location

The boundary to draw is whether you can put things back. The edge of your business is easier to picture, which is why the rule usually gets written that way, and it misplaces the gate in both directions.

The location version of the rule reads well because it names familiar actions: sending, publishing, paying, changing a record outside the business. Lists of actions have edges, and two common steps sit on the wrong side of this one.

The first is your own records. Zapier's list of actions that need a person includes overwriting customer records and deleting data. 4 Neither of those leaves your business. A quoting workflow that writes a corrected address back over the one your bookkeeper entered has destroyed the only copy, and it did it entirely in-house.

The second runs the other way. An internal status email to your own crew is a send. Get it wrong and you send another one. Put a gate on it and you've taught your reviewer to click approve without reading, which is the habit that ruins the gates that matter.

QC Devworks names the third trigger worth keeping: an action that depends on context the system cannot reliably verify. 5 That trigger is a property of the step, and you can only see it by looking at what the step needs to know.

The step nobody gates is the one that decides nothing needs to happen

A step that quietly files something away is an action, and it's the action that gets missed.

Domo's worked example is a review-response workflow. Every review comes through the platform's APIs, an agent classifies each one as positive or negative, the positive ones are set aside, the negative ones get a drafted reply, and an email goes to a named person who approves or denies before anything is sent. 6 The gate is in the right place for the sending. The classification has no gate, and the classification is the step that decides whether a customer hears from you at all.

JMG Group's position is that reviewing intermediate output adds work without adding safety, because a wrong classification will be visible in the draft anyway. 2 That holds for every item that stays in the workflow, and I'd apply it exactly that far. It fails for the items the classifier removes. A one-star review sorted into the positive pile produces no draft, so there's nothing for the reviewer to notice and no queue for it to sit in.

The fix is one rule: the workflow never drops an item on its own. Anything it thinks needs no action goes into a visible list with the reason it was filed there, and somebody reads that list once a day. It takes a minute and it's the minute I'd argue hardest for.

The same shape shows up in enquiry handling. An assistant that sorts the inbox and decides which messages deserve an answer is making a commercial decision every time it files one away. Those are the errors that never reach anybody's screen.

What happens when the facts aren't in the source material?

The step stops and says what's missing, instead of filling the gap.

Zapier's low-confidence pattern escalates to a person when the agent can't confidently classify a message, and sets a confidence threshold below which the workflow defers. 4 QC Devworks routes missing data, conflicting records and policy exceptions into an investigation queue rather than letting the workflow guess at them. 5

For a small business, the version that works is written into the instructions rather than built into a platform. The way I teach a workflow, it has five inputs: Context, Task, Source, Rules and Output. Rules is where this limit lives. Keep the supplied prices unchanged. When a fact isn't in the source material, put it at the top of the draft as a question instead of writing a sentence that sounds right. I've set the method out in full in the five-input prompt.

A flagged gap costs you two minutes. A gap written as though it were true costs you the conversation where a customer quotes it back to you. Most of what people call checking an AI draft is really reading it against the material you supplied, and a flagged list at the top of the draft tells you where to look first.

How do you keep the gate from becoming the job?

Make approving cheaper than doing, or your team will route around it.

JMG Group treats that as the design constraint that decides adoption: approval has to be cheaper than doing the task manually, and a usable checkpoint shows the original input, the generated output, the reason it was produced and a single decision in one place. 2 StackAI puts a target on it, an evidence pack that makes the decision obvious in ten to thirty seconds. 1 Workflow Builder lists what actually goes on the screen: the proposed action first in plain language, the recommended decision including edit, the reasoning summarised to a sentence or two with a click through to the detail, the alternatives the AI considered, any deadline, and the escalation path one click away. 3

Allow the edit. JMG Group's point about forcing a rejection to fix a comma is the one I'd put on the wall. 2 A reviewer who has to send the whole thing back to change a price will stop reviewing.

What I'd add to that list comes from the managed search loop we've been building at Searchmaxxed. It connects the data about our search presence into one process that recommends what we should do next. Getting it working taught me to ask a narrower question than what should the reviewer see: what information would change the next action? Everything else on the screen is decoration. A screen that shows the drafted reply plus the customer's last three emails is a document to read. A screen that shows the reply, the price it used and the two facts it couldn't confirm is a decision you can make in fifteen seconds.

Where the gate sits in my own work

I draw the line at publishing and sending, and the workflow enforces it so I never have to remember.

The article you're reading came out of a workflow like that, built at Searchmaxxed. It reads the business's own material: the offer facts, the founder record, the research collected for the piece, the voice the writing has to match. It prepares the draft, the brief, the list of sources it used and its own account of what it couldn't verify. Then it stops. It doesn't publish to the website and it doesn't send anything. A person reads it, checks the evidence against the sources and decides what happens next.

The distinction worth taking from that is about permissions. An agent with access to your business's context and a defined work product is a different thing from a chat window you describe the business to from memory. Access to context and authority to act are two separate settings, and most tools let you grant the first without the second. If you're still working out which of those three words describes what you already have, assistant, automation and agent each carry a different approval question.

The search loop holds the same split. Collecting the evidence and producing a recommendation is one job. Executing an approved action is another, and it happens after somebody agrees. I'd propose that shape for a business coming at this for the first time, on one task, with the send step still done by hand for the first month. It's a proposal rather than a result: your task, your source material and your team decide whether it survives contact with a Tuesday.

How do you know the gate is in the right place?

Read your own approval queue.

JMG Group's test is to count how many items were approved unchanged. If that's nearly all of them, tighten the auto-approve threshold, because the gate is costing you attention and buying nothing. If it's very few, the interpretive step isn't ready to be in the workflow at all. 2 Workflow Builder describes the same number from the other end: teams discover their approval rates sit near 100 percent, because the screen gave the reviewer nothing to act on and rubber-stamping was the rational response. 3

Then test the paths that break. QC Devworks' list is the one I'd run before widening any workflow: a record with a missing attachment, a conflicting customer name, a policy exception, a duplicate event and a delayed reviewer. Check that the system doesn't invent the missing facts, doesn't repeat an action after a retry, and doesn't leave a request without an owner. 5

That retry case catches people. Approval and execution are separate events, and StackAI treats the gap between them as the place duplicate side effects appear when a network call fails and something retries. 1 The small-business version of that engineering discipline is one question to whoever set your tools up: if I press approve twice, does the customer get two emails?

Log the input, the output, the reviewer, the decision, any edit and the timestamp. JMG Group's argument for keeping the edits is that corrections are the most valuable data you own, because they show which categories are unreliable and which steps should be a fixed rule instead of a judgement. 2 Set an alert on queue age too, since unreviewed items are a silent outage. 2 Workflow Builder makes the same point as a design requirement: every gate needs an explicit timeout policy, whether that's auto-approve, auto-reject, escalate or stop, and that choice belongs to the business rather than the software. 3

Reading the queue is also how you find out which steps to retest and maintain once the workflow has been running for a season.

Who in your team is allowed to approve?

Name the approver by role before you turn the workflow on, and use two names wherever money moves.

StackAI's two-person rule requires two separate approvals before execution, with the practical variant being two roles holding one approval each so the same person can't approve both steps. Their action matrix puts payment initiation and refunds under dual approval, and routes access provisioning and role changes to an IT or security approver. 1 QC Devworks asks the same questions from the queue-design side: who can approve, reject, request changes or delegate, and when the queue should remind, escalate or fall back to a manual path. 5

In a business of six people the same person often holds every one of those roles. Then the second approval is a different moment rather than a different person. The payment run gets prepared on Tuesday and released on Wednesday against the invoice, because a night's gap catches most of what a second reader would. Write down which steps stop, who releases them and what that person has to see, and you have most of a team AI use policy without needing to write one from a template.

Public workshop or private training?

Take a public seat if you're the person who runs the task. Book private onsite training if the task crosses your team, because an approval rule only holds when everyone who touches the work agrees on the same one.

The public workshop runs a full day, in person, at Avani Mooloolaba Beach Hotel in The Cove room. A seat is A$495 excluding GST per person, places are capped at 15 paid attendees, and the next date is Wednesday 7 October 2026. Bring a laptop, a charger and a safe example of one repeated task, along with the notes, prices and templates that task needs. You leave with the written workflow you built and the example you tested on it.

Private onsite training runs at your workplace on your team's own tasks. There's no list price. After you enquire we talk about the tasks, the location and how much experience the team has, agree the scope, and then you get a fixed quote. Team size, session length and travel set that quote. Sessions are scoped for roughly 4 to 20 people, and a larger team can be split across sessions.

The case for the private version is agreement. If one person sends the quote straight out, another waits for the owner, and a third rewrites it from scratch, then the approval rule isn't a rule yet. Getting three people to settle which steps stop, who releases them and what the reviewer has to see takes one session in the same room.

Frequently asked questions