Human-in-the-loop

Human-in-the-loop is a design commitment that a named human reviews and can override a workflow's output before it takes effect. It's defined by three things — who reviews, what they review, and whether their override reaches the workflow — not by the presence of a review step.

Reviewed by Transformation.ai editorial · Markdown version · Stage: Pilot

What human-in-the-loop is

Most teams describe HITL as "a person checks the output." That description is why most HITL quietly becomes theater. A person checking every output without the ability — the time, the authority, the information — to override it is not human-in-the-loop; it's human-next-to-the-loop. The output ships either way.

Real HITL has three requirements:

1. Named reviewer. A specific person, not a role, not a queue, not "the team." If the reviewer can't be named per run — or per exception, for exception-only review — HITL has no owner.
2. Specific review. The reviewer knows what they're reviewing — the drafted reply, the classified ticket, the flagged invoice — not "the AI output." Vague review means vague override, and vague override means review-by-anxiety.
3. Real override. The reviewer's edit must reach the workflow — change the output, change the routing, change the config, or trigger a re-run. An override that doesn't reach the workflow is documentation.

These three requirements are the difference between HITL and rubber-stamping. They're also the difference between the two levels of the autonomy tier model that depend on HITL: L1 (every output reviewed) and L2 (only exceptions reviewed).

Why HITL matters

HITL is the mechanism that makes automation reversible. An agent that ships a bad output with human review can be corrected by the reviewer and re-run. An agent that ships the same bad output without review ships it, and it's now someone else's problem — frequently a customer's. HITL is the design pattern that lets you run an automation at a level of risk you don't yet fully trust.

It's also the mechanism that produces the signal to advance. The intervention rate — how often the human overrides — is what tells you, quantitatively, whether the agent is good enough to run without review. An agent with a stable 8% intervention rate over a quarter is a candidate for L2. An agent with a 2% intervention rate that nobody is paying attention to is not — it's an unmonitored workflow that happens to have a human on screen.

The metric that matters: intervention rate

Track three numbers, monthly, per workflow:

The intervention rate is the sharpest of the three. A rate that hits zero and stays there for weeks is not a sign of quality; it's a sign that reviewers have stopped reviewing. A rate that spikes when a new model deploys is a sign that HITL is doing its job.

Three HITL patterns

1. Approve–reject

   Every output queued for a binary decision.

   The simplest pattern: output arrives, reviewer approves or rejects, approval triggers the workflow's next step. Correct when the workflow's individual decisions are high-consequence and the output is not easily editable — a routing decision, a compliance flag, a discount approval.

   When it fails When review volume grows faster than the review team, approve-reject collapses into rubber-stamping. Splitting the workflow and using exception-only review for routine cases is the usual fix.

2. Exception routing

   Routine cases flow through autonomously; exceptions route to a human.

   The L2 pattern. Requires a written exception definition — the boundary of what the agent can decide — set before the workflow runs. The reviewer sees only exceptions, which means their attention per exception is higher and the review burden is proportional to the exception rate.

   When it fails When the exception line is written by the agent (or nobody) rather than by the business. An exception line that never catches anything is not a boundary; it's an absence of boundaries wearing one.

3. Review queue

   Outputs accumulate for periodic (daily, weekly) batch review.

   Best for workflows where output latency is not critical and where reviewers benefit from seeing many outputs together — QA of a content batch, review of a cold-outreach cadence, sampled audit of a routing workflow. The queue is a specific reviewer's queue, not "the review queue."

   When it fails When queue length grows unchecked — reviewers stop trusting it and start skimming, which is the batch version of rubber-stamping.

Three failure modes

Rubber stamping

The failure that turns HITL into theater. Review volume grows, reviewer attention doesn't, and the approval step becomes a click. Signs: intervention rate falling to zero, approval latency dropping to seconds, reviewers reporting "I just click through these." The fix is not more reviewers — it's a different pattern. Split the workflow, use exception-only review, or automate the workflow and monitor via sampling.

Review fatigue

The precursor to rubber-stamping. Volume is manageable but consistently high, reviewers are tired, and their quality of attention degrades before their throughput does. Signs: intervention rate is stable but the mix of reasons narrows (they catch the easy stuff, miss the hard stuff), review quality drops without volume dropping. The fix is the same as rubber-stamping but earlier — split the workflow before review fatigue becomes structural.

HITL theater

The review step exists but does not fit HITL's three requirements — no named reviewer, no specific review target, or (most commonly) no real override path. The workflow ships on approval regardless of what the reviewer would prefer. Signs: reviewers say "I don't know what I'm supposed to check," or "I can't actually change it," or "I approve everything because it doesn't matter." The fix is a design review — not more documentation, not more process.

What HITL is not

• Not "human in every loop." Exception-only review is HITL. Sample-based audit is HITL. Named review of specific routed cases is HITL. Reviewing every single output is one pattern, not the definition.
• Not explainability. Making the model explain itself is a different design goal — valuable, but not HITL. You can have an explainable model that nobody reviews, and a well-reviewed model whose explanations are opaque.
• Not the opposite of autonomy. HITL and autonomy are on the same spectrum — see autonomy tiers. Most workflows sit at a mixture: some steps run autonomously, the review-requiring steps run at L1 or L2. HITL is a design decision about specific steps, not a global posture.
• Not a guarantee of safety. A rubber-stamped HITL workflow is not safer than an L2 workflow with a written exception line. It's just better-documented exposure.