Coordination · Established
Human-in-the-loop
Also known as: Approval step, Human task, Interrupt
Human-in-the-loop pauses an automated workflow at a defined point until a person approves, rejects, edits or supplies input, then resumes with that decision as part of the workflow state.
01Problem it solves
Some actions are too risky, regulated or ambiguous to execute fully automatically, but stopping the whole process and restarting it by hand loses state and creates inconsistent records.
02Use when / Avoid when
Use when
- Actions are irreversible, costly or regulated (payments, deletions, outbound messages).
- Model or rule confidence is below a threshold for full automation.
- An audit trail of who approved what is required.
Avoid when
- Decisions are high-volume and low-risk; a human queue becomes the bottleneck.
- Response-time requirements are shorter than realistic human reaction time.
- The approver has no real information to judge with (rubber-stamp approvals).
03How it works
- 1Reach gateThe workflow arrives at an approval point with the proposed action.
- 2PersistState is saved and the workflow suspends without holding a worker.
- 3NotifyA person is notified with the context needed to decide.
- 4SignalThe decision arrives as an external signal or callback.
- 5ResumeThe workflow continues on the approve, reject or edit path, or escalates on timeout.
04Capabilities
| Capability | What it means |
|---|---|
| Wait for external input | Execution pauses until an outside signal arrives (an approval, a callback, a human edit) without holding compute while it waits. |
| Persistent execution state | Progress, variables and position in the workflow are stored outside process memory, so a crash does not lose where execution was. |
| Runtime branching | The next step is chosen at runtime from the current state, input or classification result. |
05Tradeoffs
| Aspect | You gain | You pay |
|---|---|---|
| Safety | High-risk actions get human judgement and accountability. | Throughput is bounded by human availability. |
| Latency | Automation handles everything around the decision. | Workflows may wait hours or days; state must survive that. |
06Failure considerations
| Failure mode | Mitigation |
|---|---|
| Approval never arrives and the workflow waits forever. | Set a timeout with escalation or a safe default outcome. |
| The approved action differs from what executes (state changed while waiting). | Re-validate preconditions after resume and bind approval to a specific payload version. |
| State held in memory is lost during a long wait. | Suspend through durable execution or checkpointing, not an in-process wait. |
07Implementations
Examples of products and frameworks that implement this pattern. Listed as evidence, not endorsement.
| Implementation | Mechanism |
|---|---|
| TemporalDurable execution engine | Signals and Updates deliver external decisions to a waiting workflow. |
| LangGraphAgent framework | interrupt() pauses the graph; execution resumes with the human's input. |
| CrewAIAgent framework | Tasks can request human input before their result is finalised. |
| PrefectWorkflow scheduler | Flow runs can pause or suspend until input is provided. |
| AWS Step FunctionsCloud workflow service | Task-token callbacks pause a state until an external system reports success or failure. |
| Azure Durable FunctionsCloud workflow service | Wait for external events with durable timers for escalation. |
| RestateDurable execution engine | Awakeables and durable promises suspend until external input arrives. |
| CamundaProcess orchestration (BPMN) engine | BPMN user tasks assign work to people or groups. |