Glossary
Human-in-the-loop (HITL)
Human-in-the-loop means designing an automated process so a person approves or corrects particular steps as they happen, rather than only seeing whatever the process produced afterwards.
In plain terms
Somebody has to say yes before the thing that cannot be undone. That is the whole idea, and it is easy to agree with and easy to implement badly. A person asked to approve every step approves every step within a week, because attention is finite and a queue of obvious approvals trains you to click.
Why it matters
It is the control that turns an ambitious automation into one you can defend, and it is where most of the practical safety in any deployment actually sits. It is also the control most easily installed as a gesture. The difference between a review step that works and one that does not is not whether it exists but whether it is placed on the few decisions that matter and shows the reviewer enough to have an opinion.
How it works
Choose the steps by consequence rather than by uncertainty. Anything irreversible or externally visible earns a person: sending to a customer, paying, deleting, publishing. Everything reversible and internal usually does not, and cluttering a queue with those is what destroys attention for the ones that count.
What the reviewer is shown determines whether the step is real. An approval screen displaying only the proposed action invites a click. One that shows the action, the material it was based on and what would happen if it is wrong lets somebody actually judge. The second takes longer to build and is the only version that catches anything.
Rejections are the valuable output and are usually discarded. Every time a person declines something, that is a case your system got wrong, recorded by somebody who knew why. Collecting those gives you an evaluation set built from real failures rather than imagined ones, which is worth more than the rejection itself.
Watch the approval rate, because it tells you whether the step is working. A rate very close to complete approval means either the system is excellent or the review has become a formality, and those look identical from a distance. Sampling a few approved items and checking them properly is the way to tell which you have.
Two review steps, one of which catches things
Seen in the wild
Put a wait-for-approval step in front of the single action in a flow that cannot be undone, and leave every reversible step alone.
n8nBuild a branch where a drafted customer reply is held for a person while the internal filing carries on without one.
MakeLet an assistant draft into a shared workspace so a colleague edits before anything is published, which is the same idea without any approval machinery.
Notion AI
Common misconceptions
People assume
More review means more safety.
In fact
Past a point it means less. Attention is finite, and a person asked to approve forty obvious things a day will approve the forty-first without reading it. Concentrating review on the few consequential steps produces better outcomes than spreading it thinly across everything.
People assume
A person seeing the output afterwards counts.
In fact
That is a report, not a control, because by then the email has gone and the payment has left. The distinction the term is making is that somebody intervenes before the irreversible step, which is a different design and usually a different piece of software.
Telling them apart
Human-in-the-loop vs Guardrails
Human-in-the-loop
A person decides at the moment it matters. Handles cases nobody anticipated, and costs attention, which is finite.
Code decides, on rules written in advance. Handles volume tirelessly, and is helpless in front of a case nobody thought of.
Rules for the situations you can describe, a person for the ones you cannot. A system with only the first is brittle and one with only the second does not scale, which is why serious deployments have both.
Questions
- Which steps should get a person?
- The ones that cannot be undone or that a customer sees. Sending, paying, deleting and publishing are the usual four. Reversible internal steps rarely justify it, and putting them in the queue anyway is the most reliable way to make the important approvals stop being read.
- How do we stop it becoming a rubber stamp?
- Keep the queue short enough to be read, show enough context for a real judgement, and sample approved items periodically to check they deserved it. An approval rate near the top of the scale is ambiguous evidence: it looks the same whether the system is excellent or the review has quietly stopped happening.
- Does it defeat the point of automating?
- Only if it is placed everywhere. Automating nine steps and reviewing the tenth still removes most of the work, and it removes the part that was tedious rather than the part that needed judgement. That is usually a better outcome than automating all ten and discovering the tenth mattered.
Key takeaways
- A person intervenes before the irreversible step, which is different from seeing a report afterwards.
- Choose the steps by consequence, not by uncertainty: sending, paying, deleting, publishing.
- What the reviewer is shown decides whether the step catches anything.
- Rejections are an evaluation set built from real failures, and are usually thrown away.
- An approval rate near the top looks identical whether the system is excellent or the review has lapsed.
Last checked July 2026