Order the steps of an `interrupt_before` HITL flow in LangGraph

Order steps·Medium·4.0 · 0·~1 min·Asked atCoreweave Dify Kpmg

Attempt it

1Graph resumes from the saved checkpoint and executes the previously interrupted node
2Control returns to the caller with the pending state visible via `get_state(thread)`
3Caller invokes the graph again on the same thread id, optionally with `update_state` carrying edits
4Human reviews the pending state and decides whether to approve, edit, or reject
5Checkpointer saves the current state, keyed by thread id, at the pre-node boundary
6Graph runs to the node listed in `interrupt_before` and stops just before executing it

LangGraph supports human in the loop interruptions through `interrupt_before` and `interrupt_after`. You list the node names where the graph should pause, attach a checkpointer (SQLite, Postgres, Redis), and invoke the graph with a thread id. The flow has three phases. First, the graph runs normally until it reaches a node listed in `interrupt_before`. It stops just before that node. The checkpointer saves the current state to durable storage, keyed by the thread id. Control returns to your code with the graph paused. You can call `get_state(thread_id)` to see the pending state. Second, a human reviews the pending state. They might approve as-is, edit some fields, or reject and abort. Edits go through `update_state(thread_id, ...)`, which writes a new checkpoint with the modifications. Third, your code re-invokes the graph with the same thread id. The graph reads the saved checkpoint, restores state, and executes the node that was previously skipped. From there it continues normally, possibly hitting more interrupts. The thread id is the load-bearing piece: it is how the checkpoint and the resumed call find each other.

LangGraph's human in the loop interruption is one of its strongest features and one that makes the explicit-graph design pay off. The mechanism splits a single logical run into a pause-resume sequence that survives across processes, restarts, and even long human-review delays. The ordered phases run like this. The graph executes nodes in topological order until it reaches one listed in `interrupt_before`. It pauses before that node fires. The configured checkpointer persists the current state, every key in the State TypedDict, to durable storage, indexed by the thread id passed in the config. Control returns to the caller, who can inspect the pending state via `graph.get_state(thread_id)` and see exactly what the interrupted node would have received as input. A human reviewer reads the pending state, decides on approve / edit / reject, and the application calls `graph.update_state(thread_id, {...})` to persist any edits. Update applies a reducer-aware merge to the saved state, not a blind overwrite. List-valued state keys that use an additive reducer will append rather than replace. When the application re-invokes the graph with the same thread id and the same compiled graph, LangGraph reads the latest checkpoint, restores the state, and runs the previously-interrupted node with the (possibly edited) inputs. Execution continues from there as if no pause had happened. The two design choices that make this work are the checkpointer abstraction (so state is durable, not in-process) and the thread id (so the resumed call can find the right checkpoint).

TL;DR

LangGraph stops before the marked node, checkpoints state by thread id, returns control, then resumes from the checkpoint on the next invocation, optionally with updated state.

Memory aid

Easy to grasp

Picture a board game where one player has the rule that before they take a particular kind of move, they must put the game on hold and ask the table for permission. They lay down all the pieces exactly where they are, write the current score on a card with the table's name on it, and walk away. The other players read the card, decide yes, no, or change this piece, and put the card back on the table. Whenever any player comes back, they look up the card by the table's name, restore the board to exactly the saved state, and play the held move with whatever edits were made. The card is the checkpoint and the table name is the thread id.

Key concepts

LLM Frameworks Agents

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.

LangGraph's human in the loop support is the feature that justifies the framework's explicit-graph design over the cheaper alternatives. The ability to pause an agent in the middle of a run, hand control to a human, and resume cleanly with edited state is what makes LangGraph the right choice for any production workflow where approvals or reviews sit in the loop.

This deep dive walks through the six ordered steps of an interrupt_before flow, explains why each one is necessary, and covers the checkpointer choices and external-trigger patterns that make the mechanism work in production.

Phase one: execution and checkpoint

When you compile a LangGraph with interrupt_before=['some_node'] and a configured checkpointer, the runtime treats every node boundary as a potential pause point.

What happens at the interrupt boundary

The graph runs nodes in their dependency order. The runtime tracks the next node to fire at every step. When the next node matches an entry in interrupt_before, the runtime pauses. It does not execute the node; it stops just before it would have.

What the checkpointer does

The checkpointer is an injected dependency on the compiled graph. Its job is to persist state across the pause. Before returning control to the caller, the runtime calls the checkpointer's put method with the current state, the thread id, and the next-node pointer. The state is the value of the State TypedDict at the moment of the pause: every key, every value.

Different checkpointers ship out of the box. The MemorySaver stores in process memory; useful only for tests. SqliteSaver stores in a local SQLite file; useful for development. PostgresSaver and AsyncPostgresSaver store in Postgres; this is the standard production choice. Redis and DynamoDB backings exist in the community.

Why this happens before control returns

The checkpoint write must complete before the runtime yields control. If control returned first and the process crashed before the write, the resume would have nothing to read. The runtime makes the write durable as part of the same logical transaction as the pause.

Phase two: caller observability and human review

Phase three: state edits via update_state

Phase four: the resume

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

LangGraph's own documentation uses customer-support ticket approval as the canonical interrupt example.
Stripe-style payment-tool approvals are a common LangGraph HITL pattern in 2026 production deployments.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you design the resume trigger for a workflow where the human review happens in a separate web app?

Persist the thread id with the review ticket, have the review app post a webhook to your service when approved, the webhook handler re-invokes the graph with the saved thread id; checkpoints make this safe across deploys.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Calling the graph without a thread id and being surprised the resume picks up from scratch. The thread id is what binds the checkpoint to the resumed call.

60 second bullets to scan on the way to the call.

The six ordered steps of an interrupt_before flow
Why the thread id is the load-bearing identifier

Primary sources. Browse if you want the original framing.