Glossary

Human in the Loop (HITL)

Quick Answer: Human in the loop is a design where a person reviews or approves selected AI agent actions before they take effect.

Author: Chase Dillingham 4 min read
Human in the Loop AI Governance AI Agents Oversight Approvals

Human in the loop (HITL) means a person reviews or approves certain AI agent actions before they take effect. The agent does the work. A human holds the last say on the steps that carry risk.

The goal is not to review everything. If a person approves every step, you built an expensive way to do the task by hand. The goal is to put a human at the right few points.

How it works

Most HITL designs have the same shape. The agent runs until it reaches a checkpoint. It pauses and shows a person what it plans to do. The person approves, rejects, or edits. The agent continues with the answer.

Frameworks build this in. In LangGraph, an interrupt() call pauses the graph, saves state with a checkpointer, and resumes when you send a Command with the human’s answer. Patterns include approve or reject, and review and edit.

The Model Context Protocol spec says the same thing about tools. Its tools section says there should always be a human in the loop with the ability to deny tool invocations. It also says clients should show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration.

Where the law points

The EU AI Act makes oversight a design requirement for high-risk systems. Article 14 says those systems must be built so people can oversee them effectively. It lists what the overseer must be enabled to do. They must understand the system’s limits, stay aware of automation bias, interpret outputs, decide not to use the system or override it, and stop it through a “stop” button or similar procedure.

The automation bias point matters. People tend to over-trust machine output. An approval step that nobody reads protects no one.

Where to place the human

I use three questions for each action the agent can take:

  1. Can it be undone? Drafting a reply is reversible. Sending it, wiring money, or deleting a record is not.
  2. How big is the blast radius? One customer, or ten thousand?
  3. How sure is the agent? Low confidence or missing data should route to a person.

Actions that fail the first two checks get an approval step. Actions that pass can run on their own with logging. OpenAI’s browser agent works the same way. It asks for confirmation on consequential actions, such as completing a purchase or sending an email, and tells people to read those requests carefully.

Three common patterns

  • Approve before acting. The agent proposes, the human clicks. Best for irreversible steps.
  • Review after acting. The agent acts, a sample is audited. Best for low-risk, high-volume work.
  • Escalate on exception. The agent handles the normal case and hands off when confidence drops or a rule triggers.

A short example

Say an accounts-payable agent matches invoices to purchase orders. Clean matches under a set dollar limit post automatically and go into a weekly audit sample. Mismatches, new vendors, and bank-detail changes stop and wait for a person. The person sees the invoice, the matching evidence, and the agent’s reason for flagging it. They approve in one click or fix the record.

Why it matters for production agents

HITL is how you ship an agent before you fully trust it. It limits damage from prompt injection and indirect prompt injection, because a hijacked action still needs a human to release it. It also gives you labeled data. Every approval and every override tells you where the agent is weak.

Common mistakes

  • Approval fatigue. Too many prompts, and people click yes without reading.
  • No context in the request. “Approve action?” with no inputs and no reason is a rubber stamp.
  • No timeout or owner. Requests sit in a queue nobody watches.
  • Never loosening. If the override rate drops near zero for months, the step may no longer be needed.
  • Never tightening. Oversight set at launch and never reviewed after incidents.

What a good approval screen shows

The approval request decides whether oversight is real. A reviewer needs five things on one screen:

  1. What the agent wants to do, in plain words.
  2. The exact inputs, such as the amount, recipient, or record ID.
  3. The evidence the agent used.
  4. Why it asked, such as low confidence or a policy rule.
  5. What happens if they reject, edit, or ignore it.

Keep the choices simple: approve, edit, reject. Log who decided and when. If reviewers approve nearly everything in under a few seconds, that is a signal the step is either unnecessary or the screen hides what matters.

Agentic workflows are the multi-step processes where checkpoints live. Agent orchestration is the layer that decides when to pause. AI guardrails are the automated controls that sit beside human review. For why pilots stall without clear ownership of decisions, see why AI pilots fail and AI agent permissions and least privilege.