To pause a LangGraph thread before a specific node and wait for a human decision, configure the graph with (or call inside the node), and persist progress via a so the same thread can resume after `update_state` carries the human input back in.
LangGraph supports human in the loop (HITL) workflows out of the box, but the feature needs two pieces working together: a pause hook and a persistence layer.
**Pause hooks.** There are two flavours. `interrupt_before=['node_name']` is set at compile time on `graph.compile(...)` and pauses execution just before the named node runs. `interrupt(value)` (the newer dynamic API) is called from inside a node body and pauses immediately, optionally returning a value to the caller. Either pause hook works; pick the one whose timing matches the decision point.
**Persistence layer.** A `checkpointer` (SQLite, Postgres, Redis, or an in-memory one for tests) writes the graph state after every step. Without a checkpointer, the pause works inside the current process but evaporates on restart; with one, the same thread can be resumed days later by calling `graph.stream(None, thread_config)` after the human input has been pushed via `update_state(thread_config, {...}, as_node='...')`.
The two work together: interrupt creates the pause point, checkpointer keeps the pause durable.
**Two primitives, paired by design.** LangGraph's HITL story rests on a pause primitive and a persistence primitive that have to be configured together.
**Pausing.** `interrupt_before` (and its sibling `interrupt_after`) are static configurations passed to `graph.compile(interrupt_before=['approval_node'], checkpointer=cp)`. The runtime checks before (or after) executing the named nodes and yields to the caller. The newer dynamic API exposes `interrupt(value)` as a function called from inside a node body; it pauses immediately and the value is delivered to the caller as part of the stream's interrupt event. Both reach the same goal; the dynamic API lets the pause condition depend on state.
**Persisting.** The `checkpointer` writes the graph state after every super-step. Production options are `PostgresSaver` (durable, multi-instance), `SqliteSaver` (single-instance durable), `RedisSaver` (low-latency, distributed), and `MemorySaver` (in-process, for tests). A thread is identified by a `thread_id` passed in config; resumption is `graph.stream(None, {'configurable': {'thread_id': '...'}})` which loads the saved state and continues.
**Resuming with human input.** After the human decides, the application calls `graph.update_state(thread_config, {'field': value}, as_node='approval_node')`. This injects the input into state at the right node boundary; the next stream call resumes from there. Without the checkpointer, neither the pause nor the update is durable, so a single restart breaks the whole flow.
Quick reference
TL;DR
Pause with `interrupt_before` at compile time or `interrupt()` inside a node; persist with a checkpointer so the thread can resume after restart.
Imagine a board game where you sometimes have to wait for another player before you can take your turn. You need two things: a rule that says 'stop here and ask the other player,' and a notebook where you write down the state of the board so the game can be paused for a week and resumed on the same square. Without the rule you cannot pause; without the notebook you cannot resume after a coffee break. LangGraph's interrupts are the rule, and the checkpointer is the notebook.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Single-process, single-request workflows with no need to survive restart A simple try/except plus an in-memory queue may be simpler than configuring LangGraph with a checkpointer. The interrupt machinery is overkill for one shot.
Real-time chat where the pause window is sub-second Checkpoint writes add database round-trip latency. For sub-second human turn-around (typing in a chat), the durability cost may exceed the benefit.
State that does not fit in a checkpointer (multi-GB document content) Checkpointing copies the entire state on every write. If state is huge, every step pays the copy cost. Store IDs in state and re-fetch the content from a content store outside the checkpointer.
Quick scan · 2–4 min
Everything important, quickly.
5 min: static vs dynamic interrupt + checkpointer options + thread_id and resumption mechanics + update_state with as_node + latency budget + time-travel debugging side effect.
Real-world examples
Real products, models, and research that use this idea.
1Linear's AI features use LangGraph with Postgres checkpointing for the issue-triage flow that occasionally needs human approval before posting a comment.
2Devin (Cognition AI) reportedly uses a LangGraph-style state machine with durable checkpointing for long-horizon coding tasks.
3GitHub Copilot Workspace pauses for user approval on multi-file changes; the durable pause is exactly the interrupt + checkpointer pattern.
4Replit Agent's multi-step coding flow uses checkpointing so a tab close does not lose the agent's state.
5Cursor's background-agent feature relies on durable workflow state so the agent can run for minutes while the user works on something else.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWalk through the exact sequence of calls for a HITL approval flow.
Sign in or go Pro to see the approach for this follow-up.
QHow does the same checkpointer enable time-travel debugging?
Sign in or go Pro to see the approach for this follow-up.
QWhat goes wrong if you forget the `as_node` argument to update_state?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Configuring `interrupt_before` without setting a checkpointer. The graph will pause but cannot survive a process restart, so the 'pause' only works within one process lifetime.