Human-in-the-loop (HITL) is the pattern of pausing an agent loop at a defined checkpoint and requiring a human to approve, edit, or veto before the agent continues. It is the standard mechanism for keeping irreversible actions under human control.

HITL is not a debugging tool. It is a control tool. The agent has the capability to act; HITL inserts a human in the decision path so the capability does not become autonomy in places the operator does not want it.

When HITL is necessary

HITL is necessary when the cost of a wrong action is paid by a human or by the world, not by the agent. Three classes of action qualify:

  • Irreversible side effects. Sending an email, posting to a public feed, deleting a file in production, charging a payment method, calling an external API that mutates state on someone else's behalf.
  • Communications to external people. Anything where the recipient is a real human with their own day: a customer, a partner, a journalist, a regulator. The cost of a tone-deaf or wrong send is borne by the recipient.
  • Decisions with non-recoverable consequences. Choosing a vendor, signing off on a contract clause, escalating a complaint, approving a refund above a threshold. The action may be reversible on paper but not in practice.

Read-only actions, retries on the agent's own state, and internal reorganizations do not need HITL. They cost the agent nothing it cannot pay itself.

How to implement it

Three patterns, in increasing order of friction:

  • Pre-action preview. The agent produces the action it intends to take — the email body, the file it wants to delete, the API call it wants to make — and waits. The human approves, edits, or vetoes. This is the lightest HITL and the one that scales best.
  • Approval gate. The agent pauses on a specific tool call and surfaces the call to the operator. The operator must explicitly approve the call before the tool runs. Stronger than a preview, because the agent cannot bypass it.
  • Dry-run by default. The agent simulates the action in a sandbox and reports the simulated outcome. The human decides whether to commit the real action. The strongest pattern, but also the slowest.

The pattern to avoid: HITL at the end of a long agent run, after the agent has already produced irreversible side effects upstream. That is approval theater, not HITL.

The trade-off

HITL kills throughput. Every gate is a synchronous wait; every wait is a delay; every delay is a chance the human context-switches and loses the thread. An agent system with too many HITL gates becomes slower than a human doing the work by hand, and the agent's capability stops paying for itself.

The discipline is to gate only the actions that genuinely need gating. Everything else should run on the cron or the heartbeat schedule the operator has already approved, not re-approved at every step.

See also

  • Cron — cron sessions are pre-approved at schedule time, which is why they are the right pattern for bounded, recurring work.
  • Sandbox — sandboxes are how dry-runs stay safe; HITL on a sandboxed action is cheap.
  • Agent Loop — the HITL gate is a node in the loop, not a side channel.
  • Cron Jobs and Heartbeats — HITL composes with scheduled work; the gate is the human counterweight to the schedule.