HITL inserts a human approval, review, or correction step into the agent's flow, used wherever the cost of a wrong autonomous action exceeds the cost of human latency.
Imagine a new assistant who is brilliant but sometimes confidently wrong. For drafting an email, you let them go ahead because if a draft is bad you just rewrite it. For sending a wire transfer, you make them show you the form and wait for your signature, because once the money leaves you cannot pull it back. Human-in-the-loop is exactly that rule applied to an agent. For low-risk steps the agent acts on its own. For irreversible or high-stakes steps it pauses, shows you what it is about to do, and waits for a click. Sometimes you let it run by itself most of the time and only get pulled in when the agent itself says it is unsure.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Human-in-the-loop (HITL) is the practice of inserting a human approval, review, or correction step inside an agent's execution flow. The agent does autonomous work up to a defined gate, pauses, hands an artifact to a person, and resumes only after the person approves, edits, or rejects.
The shape of HITL matters because the simple version (a human approves every output) is almost never the right answer. Approving every step collapses the agent's throughput to the speed of the human, which defeats the entire point of building an agent. The mature version places a human gate only at the specific steps where the cost of a wrong autonomous action exceeds the cost of pausing for human input. That placement is the engineering work.
The rest of this explanation covers the three canonical HITL patterns and where each fits, the rule for choosing which to apply and where, the implementation patterns that make HITL scale beyond a single synchronous web request, and the failure mode every HITL design has to defend against: the approval gate that quietly turns into a rubber stamp.
The three canonical patterns
Most production HITL setups fall into one of three patterns, distinguished by where the human sits relative to the action.
Approve-before-action is the strongest gate. The agent prepares the action (send an email, transfer money, run a deploy, merge a pull request) and blocks until a human clicks approve. The artifact shown to the approver is the exact action that will execute, not a summary of it. This is the right pattern for any side effect that is irreversible or expensive to undo. The approver's job is binary: approve or reject; edits, if any, go through a separate cycle.
Review-and-correct is the mid-weight pattern. The agent produces an intermediate artifact (a draft, a plan, a SQL query, a code patch) and the human edits it in place. The agent then continues from the edited artifact, treating the human's edits as the new ground truth. This is the right pattern when edits compound downstream and a wrong intermediate would propagate. Coding agents like Cursor and Aider use this pattern for every diff: the human reviews and accepts each change, and the next agent action is conditioned on the accepted version.
Exception-only is the lightest pattern. The agent runs autonomously on most tasks and only escalates to a human when something specific trips: low model confidence, a tool error the agent cannot recover from, a value above a configured threshold, a flagged category. This is the right pattern for high-volume mostly-reversible workflows like first-line customer support, where the average task is cheap but the long tail needs careful handling.
These patterns are not exclusive. A single agent can use approve-before-action for irreversible steps, review-and-correct for intermediates, and exception-only for the autonomous middle. The job is to choose deliberately rather than apply one pattern everywhere.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Cursor and other code agents pause for a human to review and accept each diff before it is written to disk, the canonical review-and-correct pattern for code.
- Klarna's customer service agent escalates ambiguous or high-value cases to a human agent rather than answering autonomously, an exception-only pattern.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you stop an approval gate from becoming a rubber stamp?
Surface what is actually being approved: the diff, the affected records, the reversibility class. Sample audit approved actions for correctness. Make reject a one-click path that does not penalise the approver. Track approve to reject ratios per approver as a leading indicator of attention decay.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Putting a human in the loop on every step. That collapses the value of agents back to the throughput of a human worker. The art is choosing the few steps where approval pays for itself.
60 second bullets to scan on the way to the call.
Define HITL as a human approval, review, or correction step inserted into the agent flow.
Name the three canonical patterns: approve before action, review and correct, exception-only.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.