Skip to content

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.

01

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.

02

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

Two review steps, one of which catches thingsThe right-hand column is not built by careless people. It is what happens when a sensible instinct, that a person should check, is applied without deciding where. Forty approvals a day is more than anybody reads properly, and a screen showing only the proposed action gives a reviewer nothing to judge it against, so approval becomes the default response and the step becomes decoration that everybody believes in. The left column asks for less and gets far more: a handful of decisions that genuinely matter, each presented with the material behind it, and the refusals kept because they are the most honest record of what the system gets wrong. The design question is never whether to have a person. It is which few things they see, and what they see about them.A step that worksSits on the irreversible actiononly.Shows the material it was basedon.Arrives a few times a day.Rejections are collected andused.A step that does notSits on everything, to be safe.Shows the proposed actionalone.Arrives forty times a day.Approval is a reflex byWednesday.Both would be described in adocument as human oversight.Only one of them is stilloversight after a fortnight, andthe difference is placement andcontext rather than anybody'sdiligence.
The right-hand column is not built by careless people. It is what happens when a sensible instinct, that a person should check, is applied without deciding where. Forty approvals a day is more than anybody reads properly, and a screen showing only the proposed action gives a reviewer nothing to judge it against, so approval becomes the default response and the step becomes decoration that everybody believes in. The left column asks for less and gets far more: a handful of decisions that genuinely matter, each presented with the material behind it, and the refusals kept because they are the most honest record of what the system gets wrong. The design question is never whether to have a person. It is which few things they see, and what they see about them.
03

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.

    n8n
  • Build a branch where a drafted customer reply is held for a person while the internal filing carries on without one.

    Make
  • Let 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
04

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.

05

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.

Guardrails

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.

06

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.
07

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.
09

Tools that use this

  • n8n

    A wait-for-approval step in front of the one irreversible action.

  • Make

    Branching so the customer-facing path waits and the internal one does not.

  • Notion AI

    Drafting into shared work, which is review without approval machinery.

Last checked July 2026

All glossary terms