In LangGraph, what does interrupt() do inside a node and how do you resume?

## The problem it solves An agent that can spend money, send email, delete rows or file tickets needs a person in the loop before the irreversible step. A plain function call cannot do that: the process would have to sit and block for however long the human takes, which might be minutes or days. LangGraph's answer is to make the pause a *persistence* event rather than a *blocking* event. ## What interrupt() actually does `interrupt` is imported from `langgraph.types`. You call it inside a node with any JSON-serializable payload: When the runtime executes that node and hits the call, `interrupt` raises an internal `GraphInterrupt` exception. The Pregel loop catches it and does three things. First, it commits a checkpoint for the current thread containing the state as of the end of the previous superstep, plus a record of the pending task and its interrupt. Second, it stops the run — no further nodes are scheduled. Third, it returns to the caller. The result of `graph.invoke(...)` is the current state dict with an extra `__interrupt__` key holding a tuple of `Interrupt` objects; each carries the `value` you passed. If you are streaming, the same information arrives as an `__interrupt__` update. Crucially, the pause costs nothing while it lasts. No OS thread, no coroutine, no open connection. The run exists only as rows in whatever checkpointer you configured. A web server can return a 200 with the interrupt payload, the human can answer three days later, and a completely different process can resume the run. ## Resuming Resumption is another invocation of the same graph, with a config whose `thread_id` matches the paused run, and `Command(resume=...)` as the input: `graph.invoke(Command(resume="yes"), config)` `Command` also comes from `langgraph.types`. LangGraph restores the checkpoint, finds the task that was interrupted, and re-runs that node. On this pass, the `interrupt()` call does not raise: it returns `"yes"`, and the node continues normally to its `return`. Everything downstream then proceeds as if the pause had never happened. Two details follow from that mechanic and both are frequently probed. The node restarts **from its first statement**, not from the line after `interrupt()` — LangGraph does not snapshot the Python stack, it replays the function. And if a single node calls `interrupt()` more than once, the resume values are matched positionally within that node's task: the first call consumes the first stored resume value, the second consumes the second, and only the call with no stored value pauses again. ## The checkpointer requirement `interrupt()` is meaningless without persistence, so the graph must be compiled with a checkpointer: `builder.compile(checkpointer=InMemorySaver())` for a demo, a durable saver for anything real. Calling `interrupt()` on a graph compiled without one is an error, and calling `invoke` without a `thread_id` in `configurable` is an error too, because there is no key under which to store or find the paused run. ## Payload design The payload is the entire contract with your UI, so put in it everything the reviewer needs and nothing secret they should not see: the proposed action, its arguments, a short rationale, and enough identifying context to render a decision screen. It must be serializable by the checkpointer. Keep it stable — it is effectively an API between the graph and the approval front end. ## Where this sits in a real system A typical shape is: HTTP request starts or resumes a thread; the graph runs until it interrupts; the service persists nothing extra (the checkpointer already did) and returns the interrupt payload plus the `thread_id` to the client; the client renders an approval screen; the human's decision comes back on a second endpoint that calls `invoke(Command(resume=decision), config)`. Because the thread id is the only handle, treat it as a first-class identifier — log it, index it, and make it addressable from the approval queue. ## What candidates get wrong The two classic mistakes are resuming by passing the human's answer as ordinary graph input (which starts a *new* superstep with new input instead of delivering a resume value) and assuming execution continues after the `interrupt()` line. A third is imagining `interrupt()` is a blocking read — it is not; it is an exception plus a checkpoint, and that is exactly why the pause can outlive the process.