Human in the loop means a named person can review, approve, override or reverse specific actions an AI system takes — and actually has the information and the time to do it. The useful question is never "should we have a human?" It is which actions, what control, and what evidence would let you remove it. This article is about answering those three precisely.
If you are new to how AI steps and agents work, start with what an AI agent is. Here we assume something is already about to act on your behalf.
In short
- Tier every action by reversibility, blast radius and detectability. The tier picks the control.
- There are about seven patterns, and the approval gate is only one of them.
- The failure mode of approval gates is rubber-stamping, which regulators name as automation bias.
- Make review cheap and specific, or it degrades within two weeks.
- Write exit criteria before launch, or every gate becomes permanent.
Start with the action, not the workflow
Humans don't belong "in the workflow." They belong at specific actions. A single lead-handling flow might contain a dozen actions with wildly different risk: reading a CRM record, classifying a reply, drafting an email, sending it, changing a deal stage, deleting a duplicate, issuing a refund.
Ask three questions of each action.
- Reversibility. If this is wrong, can it be undone, by whom, and how fast? A CRM field can be reverted. A sent email cannot.
- Blast radius. Does a mistake affect one record, one customer, or every customer this hour?
- Detectability. How long until someone notices? A wrong email gets a reply. A wrong lead score is silent for a quarter.
Detectability is the one teams forget, and it is often the most important. Silent wrongness is worse than loud wrongness, because loud errors self-report.
The MitHub risk tier table
Score each action and place the control that matches. This is the core artefact — the thing to fill in before you build.
| Tier | Profile | Control | Example |
|---|---|---|---|
| T0 | Reversible, one record, obvious if wrong | None. Log it. | Attach an internal research brief to a record |
| T1 | Reversible, many records, or slow to detect | Sample audit + alerting on drift | Lead scoring, reply classification, field enrichment |
| T2 | Hard to reverse, customer-visible | Approval before action, per item | First outbound message, price quote, stage change that triggers other flows |
| T3 | Irreversible, money or legal exposure | Two named people, and a documented reason | Refunds, contract sends, deletions, anything touching regulated data |
Two rules make the table work:
- A tier is per action, not per project. "This workflow is low risk" is how a T3 delete ends up inside a T0 flow.
- Bulk changes the tier. The same action applied to 10,000 records at once is at least one tier higher than applied to one. A batch update is its own action.
Anthropic's guidance on building effective agents makes the adjacent point about autonomy: more autonomy brings higher costs and the potential for compounding errors, so test in sandboxed environments with guardrails and add autonomy only where it is needed. Tiers are how you decide where "needed" is true.
What oversight has to make possible
Regulation is a surprisingly good design spec here, because it was written by people who watched oversight fail in practice. Article 14 of the EU AI Act requires high-risk AI systems to be designed so they "can be effectively overseen by natural persons," and lists what those persons must be enabled to do: properly understand the system's capacities and limitations, monitor operation to detect anomalies and dysfunctions, remain aware of the tendency to automatically rely or over-rely on output (automation bias), correctly interpret the output, decide not to use the system or to disregard, override or reverse its output, and intervene or interrupt it through a stop button or similar procedure (EU AI Act, Article 14).
Read that as a checklist for any AI workflow, regulated or not:
- [ ] Does the reviewer know what the system can and cannot do?
- [ ] Can they see anomalies, or only individual items?
- [ ] Is the interface built so "approve" is not the path of least resistance?
- [ ] Can they understand why the system proposed this?
- [ ] Can they override and reverse, not just reject?
- [ ] Is there a stop button, and does everyone know who may press it?
The Act also shows what a genuine high-stakes control looks like: for certain biometric identification systems, it requires that no action be taken unless the identification has been separately verified and confirmed by at least two competent, trained and authorised people (EU AI Act, Article 14). That is the two-person rule, and it is the right model for your T3 actions.
Seven patterns
| Pattern | How it works | Best for |
|---|---|---|
| Approval gate | The workflow pauses and asks a person to approve before the action runs | T2/T3 single actions |
| Confidence routing | High-confidence items proceed; low-confidence items go to a queue | High volume with a long tail of odd cases |
| Shadow mode | The system decides but does not act; a person acts and the two are compared | Earning trust in a new model or rule set |
| Sample audit | A person checks a random sample per day or week and feeds corrections back | T1 actions where per-item review is impossible |
| Two-person rule | Two named, competent people must agree | Irreversible, money or legal |
| Delay and undo | The action is queued with a visible cancel window | Outbound sends, bulk updates |
| Escalation with context | The system stops on an unusual input and hands over a summary, not a raw error | Anything reading messy real-world input |
In a workflow tool, the approval gate is concrete. n8n's documentation on human-in-the-loop for tools describes it plainly: when an AI step wants to run a sensitive action, the workflow pauses and sends an approval request over a channel such as chat, Slack or email; if the reviewer approves, the action runs, and if not, it is cancelled and the AI is told. The docs name irreversible actions, compliance-regulated operations and high-impact decisions as the typical cases.
Shadow mode deserves more use than it gets. Run the system silently for two weeks alongside the human process, log both decisions, then compare. You get an agreement rate before anything is at stake, and the disagreements are the most useful training material you will ever collect about your own process.
The rubber-stamp problem
Most approval gates degrade, and they degrade quietly. Signs:
- Approval rate is 99%+ and nobody remembers rejecting anything.
- Review happens in batches at the end of the day.
- The reviewer cannot explain what would make them reject an item.
- One person is the gate for every flow.
This is automation bias operating exactly as the EU AI Act describes — the pull towards accepting output because the system produced it. Four countermeasures:
- Show the reasoning and the source, not just the output. Microsoft's Guidelines for Human-AI Interaction include "G11: Make clear why the system did what it did" and "G2: Make clear how well the system can do what it can do" (Microsoft HAX Toolkit). A reviewer who can see the evidence reviews. One who sees only a conclusion approves.
- Make correcting cheaper than approving. The same guidelines include "G9: Support efficient correction" and "G15: Encourage granular feedback." If editing a draft takes four clicks and approving takes one, you have designed a rubber stamp.
- Cap review volume. Estimate honestly: items per day × seconds of genuine attention each. If that exceeds what the reviewer actually has, the gate is decorative. Either reduce what reaches review through confidence routing, or drop to a sample audit and say so out loud.
- Rotate and spot-check. Occasionally insert a known-bad item. If it sails through, the gate is not working — and that is information about the design, not a reason to blame the reviewer.
Where humans do not belong
- After the irreversible step. A review that happens after sending is a post-mortem.
- On decisions they cannot judge. Asking a reviewer to confirm a similarity score they have no way to evaluate produces noise and false confidence.
- As the integration. If a person copies output from one system into another all day, that is not oversight, it is unbuilt plumbing.
- On every item forever. If a gate has produced zero rejections in thousands of items, either the tier was wrong or the gate should now be a sample audit.
The autonomy ledger: how a gate gets removed
Gates should be temporary by default, and the way to make that real is to write the exit criteria before launch. MitHub calls this the autonomy ledger — one row per gated action.
| Field | Example entry (hypothetical) |
|---|---|
| Action | Send first outbound email drafted by AI |
| Tier at launch | T2 |
| Control | Per-item approval in Slack |
| What the reviewer checks | Correct company, claim supported by a field, no invented facts, tone |
| Metrics tracked | Approval rate, edit rate, reviewer seconds per item, complaints |
| Exit criteria | 300 consecutive items with approval rate above 95%, edit rate below 10%, zero factual complaints |
| What happens at exit | Move to 10% sample audit for one segment; keep the gate for new segments |
| Re-entry trigger | Any factual complaint, or a prompt, model or data-source change |
| Owner | Named person, reviewed monthly |
Three things make this ledger work. Exit criteria are numeric and were written before the data existed. Re-entry triggers exist, so autonomy is not a one-way door — a model change or a new data source sends the action back behind the gate. And the rollout is by segment, so autonomy is earned on the part of the business where you have evidence, not everywhere at once.
This is the loop MitHub teaches in Operate: observe, hypothesise, build, measure, learn, adjust. Autonomy is just another hypothesis that has to be measured.
Security is a reason for a human, too
Human review is also a containment strategy. OWASP's guidance on prompt injection describes indirect injection, where an LLM reads external content such as a website or file that contains content which "alters the behavior of the model in unintended or unexpected ways," and it recommends segregating and clearly denoting untrusted content, restricting model privileges to the minimum necessary, and implementing "human-in-the-loop controls for privileged operations" (OWASP).
The practical design rule: any action an attacker would want to trigger belongs at T2 or above. Sending messages, moving money, changing permissions, exporting data, deleting records. An agent that reads inbound email and can also send email without approval is an attack surface with a workflow diagram.
A five-step placement exercise
Do this for one real workflow today; it takes about half an hour.
- List every action the system can take. Not steps — actions with an effect outside the system.
- Score each on reversibility, blast radius and detectability. Assign a tier.
- Pick the lightest control that fits each tier. Resist gating T1 actions.
- Design the review screen: the proposal, the evidence behind it, an edit box, and reject with a reason.
- Write the autonomy ledger row for each gate, exit criteria included, before you launch.
If step 1 is hard, the process isn't mapped well enough yet — see process mapping before automation. If your gates keep firing because the workflow itself is fragile, the fix is upstream in error handling, not in more human attention.
The point of all this
Placing people well is what lets a system scale without becoming a liability. It is also the skill that moves you up MitHub's capability ladder: a Doer does the task, a Director judges the output, a Designer builds the system and decides where judgment is required, and an Owner is accountable for the result either way. More on that in Director vs Doer, and on choosing between fixed workflows and agents in AI agents vs automation.
Humans in the loop are not a sign the automation is weak. They are how you decide, deliberately, where the risk lives — and how you prove you are ready to take some of it away.