A person should approve any step where a mistake is expensive, hard to reverse or visible to a customer, and any decision that depends on context the system cannot see. Everything else (moving data, applying rules, sending routine updates) should run on its own. The systems that hold up are built around that line from day one, with the handoff between machine and person designed as carefully as the automation itself.
Human in the loop AI automation: which steps should a person approve?
Automation is good at the parts of a job that have a right answer: move the data, apply the rule, send the update. It is a poor substitute for judgement. A customer who needs to be talked down, an exception that technically breaks the rule but is obviously the right call, a relationship that survives because someone remembered a detail nobody logged anywhere: those belong to a person.
In practice we sort every step of a workflow with three questions. Can a mistake here be undone cheaply? Will a customer, a supplier or the tax office see it? Does the right answer depend on something that isn’t in the data? If all three answers are no, the step runs automatically. If any answer is yes, a person approves it, or at least sees it before it goes out.
Take an accounts payable flow as a worked example. An n8n workflow reads supplier invoices from a shared inbox, Claude extracts the supplier, amount, due date and line items, and a draft bill lands in Xero or QuickBooks. Reading, extracting and drafting are reversible and nobody outside the business sees them, so they run alone. Paying the bill can’t be undone, so a person approves the payment run. A new supplier, a changed bank account, or an invoice well above that supplier’s usual amount (say 20% higher than the last one) goes to a person with the original document and the history attached, because that is exactly where fraud and expensive errors hide.
Why fully automated systems fail quietly
The demo of a fully automated process always works, because the demo uses clean inputs. Real operations don’t. A customer writes in two languages in the same message, a supplier changes the layout of their invoice, a product code is retired but still appears on old orders. A system with no human checkpoint doesn’t stop when it meets these cases. It makes its best guess and carries on, and the wrong answer travels downstream into the CRM, the accounting system and the customer’s inbox before anyone notices.
That is the real risk. People make mistakes too, but an unsupervised system makes them silently and at volume. An error rate that would be trivial for one person handling 20 requests a day turns into a weekly clean up job when the same logic handles 2,000.
Automate the throughput, route the judgement calls to a person with full context, and never let an error travel further without someone seeing it.
How we design the handoff between the system and a person
A handoff only works if the person receiving it can decide in under a minute. That means the system sends context, not just an alert. When a request falls outside what the automation should handle, the person gets the original message, what the system understood, what it would have done and why it stopped, inside the tool they already use (usually Slack or WhatsApp) with a clear option to approve or edit.
The trigger for that handoff is a confidence threshold. When a model like Claude or ChatGPT classifies a support request, it can return how sure it is alongside the answer. Above the threshold, the routine reply goes out. Below it, the draft goes to a person for review. We set the threshold conservatively at the start, so more items reach people in the first weeks, and lower it only as the review log shows which categories the system consistently gets right.
The same principle sits behind a customer service portal we built for a client. Routine requests are now resolved automatically, returning about 30 hours a month to the team, while the cases that genuinely need people stay with them. The goal was never to take the team out of support. It was to stop spending their time on requests that didn’t need them.
What the guardrails look like in practice
The approval step is the visible part. Underneath it, every system we build carries the same set of guardrails:
- Logging on every action, so any output can be traced back to the input and the rule that produced it.
- Alerts when something falls outside the expected range, for example an order quantity ten times a customer’s average, or an overnight sync that processed zero records.
- Scoped access, so an agent that drafts replies can’t also issue refunds or change prices.
- Audit logs that show who approved what, and when.
- Clear escalation rules covering who receives each type of exception, how quickly they need to respond, and who covers when that person is away.
None of this is exotic. n8n, Make and Zapier all support error handling and notifications, and HubSpot keeps a property history on every record. The real work is deciding, before anything goes live, what counts as abnormal and who owns the response when it happens.
Where to start
Pick one workflow you are about to automate, or one that is already running, and list every step on a single page. Mark each step against the three questions: reversible, visible outside the business, dependent on context. The steps with three noes are your automation candidates, and every other step needs an approval point and a named owner. If you want a second pair of eyes on that map, it is the review JARA runs before building anything.
FAQ
What does human in the loop mean in AI automation?
It means the system pauses at defined points and a person reviews, approves or corrects the output before the process continues. The automation handles the volume, and the person handles the decisions where a wrong answer is costly or the right answer depends on context.
Don’t approvals cancel out the time automation saves?
Not when they are placed well. Most of the volume in a typical workflow is routine and runs without anyone touching it. Approvals sit on the small share of steps that carry real risk, and a well designed handoff takes a person seconds rather than minutes because the system has already gathered the context.
How do you set the confidence threshold?
Start conservative so more items go to review, then watch the review log. When a category is approved without edits consistently for a few weeks, lower the threshold for that category. When reviewers keep correcting something, raise the threshold or take that category out of automation.
Which steps should never be fully automated?
Payments and refunds above a set value, changes to supplier or customer bank details, anything sent to a regulator or tax authority, and replies to an upset customer. These are irreversible, externally visible or dependent on judgement, and often all three.
Can a small business run this without a technical team?
Yes. The approvals live in tools the team already uses, such as Slack, WhatsApp or email, and the guardrails are configured once during the build. What the business does need is a named person who owns each type of exception.