Human-in-the-loop (HITL) is a pattern in which an agent pauses at chosen points to let a person review, approve, edit, or reject an action before the run continues. It keeps a human in control of consequential decisions while still letting the agent handle everything around them, rather than running fully unattended end to end.
Why human-in-the-loop matters
Not every action an agent takes is safe to perform automatically. Issuing a refund, sending an external email, deleting records, or merging code are decisions where a wrong call is expensive and hard to undo. Letting a model commit those actions with no oversight concentrates risk at exactly the steps that matter most.
Human-in-the-loop addresses this by inserting a deliberate pause where a person can intervene. It is also how teams build trust in an agent incrementally: high-stakes steps require approval at first, and as confidence grows the checkpoints can be relaxed. The engineering challenge is that a pause is not free — the run has to hold its place, sometimes for a long time, without consuming a process while it waits and without losing its position if the system restarts.
How it works
A human-in-the-loop interaction follows a consistent shape:
- The agent runs until it reaches a step that is designated as requiring human input.
- Instead of proceeding, it records a waiting state — capturing what it intends to do and the context a reviewer needs — and stops advancing.
- That waiting state is persisted to durable storage, so no process needs to stay alive holding the pause in memory.
- A person reviews the pending action and responds: approve, reject with a reason, or send a correction or additional input.
- The run resumes from the exact point it paused, incorporating the human’s decision, and continues to completion.
Because the pause is durable, the wait can last from seconds to days, and the run can be picked up by a different worker than the one that started it.
Human-in-the-loop vs. guardrails
Both keep an agent’s behavior in bounds, but they act differently. Guardrails are automated checks — validating an output, blocking a disallowed tool, enforcing a schema — that run without a person. Human-in-the-loop routes a decision to an actual human. They are complementary: a guardrail can catch clearly invalid actions automatically, while human-in-the-loop reserves judgment calls for a person. Often a guardrail is what decides that a given step should escalate to a human in the first place.
In practice
A durable runtime makes a human pause cheap and reliable by persisting the waiting state server-side, so a run can sit idle without holding a process and still resume after a restart. This is typically expressed as an approval gate on a sensitive step, works alongside automated guardrails, and inherits its resilience from durable execution. For a complete example, see the human-in-the-loop walkthrough.