How do you use LangGraph's update_state to edit graph state before resuming a run?

## What it is for Approval is rarely binary. Often the reviewer's answer is "almost — but change this argument", or "drop that message and try again". `update_state` is the API that turns a human correction into graph state. ## The call `new_config = graph.update_state(config, values, as_node="agent")` - `config` identifies the thread (and optionally a specific checkpoint) you are editing. - `values` is a partial state update, shaped like a node's return value. - `as_node` attributes the update to a node. It returns a config whose checkpoint id points at the newly written checkpoint. ## Reducers apply — this is the number-one surprise `update_state` does not blindly overwrite. It routes `values` through exactly the same channel reducers the graph uses for node returns. On a plain channel (no reducer) the new value replaces the old. On a channel annotated with `add_messages`, the update **appends**. So handing `{"messages": [AIMessage("corrected")]} ` to a message channel does not replace the conversation — it adds a turn. The way to actually replace a message is to exploit `add_messages`'s id semantics: a message whose `id` equals an existing message's id overwrites that message in place. So you read the offending message from `graph.get_state(config).values`, construct a corrected `AIMessage` with the *same* id and fixed `tool_calls`, and pass it. To delete instead, pass a `RemoveMessage(id=...)` (from `langchain_core.messages`) and the reducer removes the matching entry. Custom reducers behave the way you wrote them — if a channel accumulates with `operator.add`, `update_state` accumulates too. Knowing your own schema's reducers is a prerequisite for editing state safely. ## as_node and what runs next A checkpoint is not only values; it also records which node produced them, and that determines what the graph schedules when it continues. `as_node="agent"` says "pretend the agent node just returned this", so the run continues along the agent node's outgoing edges — including any conditional edge, which will now be evaluated against your edited state. If you omit `as_node`, LangGraph infers the last node that wrote to the channels; that works when it is unambiguous and raises when it is not (for instance after a parallel fan-out). Being explicit is the safer habit, and it is also a tool: setting `as_node` to a different node is how you redirect a paused run down another path without touching its topology. ## The canonical approval-with-edit flow 1. Compile with a checkpointer and `interrupt_before=["tools"]`, or call `interrupt()` in a gate node. 2. Run until it pauses. Read `snapshot = graph.get_state(config)`; `snapshot.values` holds the conversation, `snapshot.next` names the node about to run. 3. Show the reviewer the proposed tool call from the last `AIMessage`'s `tool_calls`. 4. On "edit": build a replacement `AIMessage` with the same `id` and corrected `tool_calls`, call `update_state(config, {"messages": [fixed]}, as_node="agent")`. 5. Continue with `graph.invoke(None, config)` — the tool node now executes the corrected call. For a rejection you typically do not edit the tool call at all; you append a `ToolMessage` whose content explains the refusal and matches the pending `tool_call_id`, so the model sees a legitimate tool result and can re-plan rather than choking on an unanswered call. ## update_state versus Command(resume=...) They are complementary, not alternatives. `Command(resume=value)` delivers a value *into a waiting `interrupt()` call* — it is the answer to a question the node asked. `update_state` rewrites the graph's state from outside, independent of whether anyone asked. Use resume for the decision, use `update_state` for the correction, and remember that `Command` can also carry an `update` payload when you want both in one call. ## Operational notes Every `update_state` writes a checkpoint, so the pre-edit state stays in the thread's history — a genuine audit trail of what the model proposed versus what the human sent. That is worth designing for: record who made the edit somewhere durable, because the checkpoint records the values, not the actor. And be careful editing a thread that is not paused; state written under a concurrently running graph competes with the nodes' own writes and is a good way to produce a state nobody intended.