How do LangGraph's interrupt_before and interrupt_after differ from interrupt()?

## Two mechanisms, one runtime LangGraph can stop a run in two ways, and interviewers like this question because the choice reveals whether you have actually built an approval flow or only read the tutorial. **Static interrupts** are configuration. You list node names when compiling the graph: `graph = builder.compile(checkpointer=saver, interrupt_before=["tools"], interrupt_after=["draft"])` Both parameters take a list of node names, and both accept the wildcard `"*"` to break on every node. The runtime consults that list at each superstep boundary and stops the run there. Nothing in your node code knows this is happening — the pause is invisible to the function. **Dynamic interrupts** are code. A node calls `interrupt(payload)` from `langgraph.types`, which raises internally, checkpoints, and returns the payload to the caller under the `__interrupt__` key. ## Before versus after The two static flavours answer different questions. `interrupt_before=["tools"]` means: the tool node has *not* run. The last thing in state is the model's proposed tool call. This is the approval-gate position — you can reject the action, or rewrite the arguments with `update_state` before letting it proceed, because the side effect has not happened yet. `interrupt_after=["draft"]` means: the node ran, its state update was committed to the checkpoint, and the graph stopped before scheduling anything downstream. This is the review-the-output position — you look at what was produced and decide whether the run should continue. It is the wrong place for an approval gate over a side effect, because by the time you are looking, the node already did the work. ## Payload and resume semantics Static interrupts carry no information. The caller has to ask: `snapshot = graph.get_state(config)` and read `snapshot.next` (the node names about to run) and `snapshot.values` (the state) to work out what is pending. You then resume with `graph.invoke(None, config)`. The `None` is the important part: it means "no new input", continue the paused thread from its checkpoint. Passing a dict there would instead start a fresh superstep with that input applied, which is a common way to corrupt a run. Dynamic interrupts are self-describing. The payload you pass is exactly what the approval UI receives, and the resume value you send with `Command(resume=...)` is exactly what the `interrupt()` call returns inside the node. That round trip is why dynamic interrupts compose with real product flows: "approve", "reject with this reason", "use these edited arguments" are all just values. ## Conditionality A static interrupt fires every time the named node is reached. If only 3% of tool calls are risky, `interrupt_before=["tools"]` gates 100% of them and trains reviewers to click approve without reading. Dynamic `interrupt()` sits inside an `if` — you inspect the proposed action, decide whether it crosses a risk threshold, and only then pause. Risk-proportional gating is almost always what production wants, and it is only expressible dynamically. ## Granularity Static interrupts are node-granular by construction: the smallest thing you can pause at is a node boundary. If you want a pause in the middle of a node — after computing a plan but before executing it — your only options are to split the node in two or to call `interrupt()` where you want the pause. That is also the reason a dynamic interrupt forces a node replay on resume, while a static one does not: the static pause happens *between* nodes, so nothing needs re-executing. ## What both share A checkpointer is required either way, and a `thread_id` in `configurable` is required either way — the pause is stored state, and the thread id is the handle. Neither mechanism holds a thread, a socket or a coroutine open. Both are durable across process restarts if the checkpointer is. ## Choosing Use static interrupts while developing: `interrupt_before="*"` turns the graph into a step debugger you can single-step with `invoke(None, config)`, inspecting state between nodes. Use `interrupt()` for anything a user will see: it is conditional, it carries structured context, it accepts a structured answer, and its behaviour does not depend on graph topology staying the same. In LangGraph 1.x the documentation itself steers production human-in-the-loop toward `interrupt()`, with static interrupts framed as a debugging convenience. Saying that plainly, and explaining *why* the payload round trip is the difference that matters, is what a strong answer sounds like.