Resume Botie’s Work with LangGraph

Botie has found a manual excerpt and prepared a proposed inspection. The technician needs to ask a colleague before continuing. Closing the page should not turn that request into an unrelated conversation or repeat work that already happened.

We need an explicit record of where the request stopped and what information it had. LangGraph represents work as nodes connected by routes, with state passed between them. We will start by deciding what to preserve before adding pause and resume.

Choose the request checkpoint, then merge incoming excerpts by ID. Observe what happens when a lookup returns an excerpt already seen.

[
  {
    "id": "M7",
    "text": "Inspect mounting."
  },
  {
    "id": "M8",
    "text": "Check alignment."
  }
]

State is the data the workflow needs as it moves between operations. For our request, it includes collected evidence and whether review has happened. A thread ID identifies the request whose saved state we want to continue.

Keep this ID separate from the asset ID. A pump can have several maintenance requests. Also keep it separate from user identity: the application must check that the signed-in user may access the selected thread. Knowing or guessing an ID does not grant access.

Write down which fields belong to the request before choosing how to save them. Otherwise unrelated concerns accumulate in one unstructured transcript.

A node is a function that performs one step and returns changes to state. A retrieval node can return new evidence. A review node can return a decision. Edges describe which node runs next; a conditional edge chooses a route from the current result.

This can describe deterministic work as well as model calls. Our reference uses an invented manual lookup so that the behaviour of the graph is easier to isolate. Adding a model inside a node does not change the need to define that node’s inputs and outputs.

Use a fixed route when the sequence is known. Add a conditional route or cycle only when the task actually needs one.

If a node returns a new approved value, replacing the previous boolean is sensible. Evidence is different: replacing the whole list may lose earlier excerpts, while appending everything may duplicate a repeated lookup.

A reducer is the function that combines a previous field value with an incoming update. Our evidence reducer uses each excerpt’s ID. New IDs are appended, and existing IDs receive their updated text in place. This is an application policy, not LangGraph’s automatic rule for every list.

Before = [{"id":"manual-7","text":"old wording"}]
Update = [{"id":"manual-7","text":"revised wording"}]
After = [{"id":"manual-7","text":"revised wording"}]

The same update applied twice leaves one excerpt. That makes this particular merge idempotent: repeating it has the same result as applying it once.

saved = {"M2": "Old coupling wording.", "M5": "Inspect the filter."}
updated = dict(saved)
updated["M2"] = "Revised coupling wording."
print(list(updated))
print(updated["M2"])
print(saved["M2"])

['M2', 'M5']
Revised coupling wording.
Old coupling wording.

LangGraph has an add_messages reducer for message histories. It can append messages and handle updates using message IDs. Our evidence records are ordinary dictionaries, so the example supplies a different reducer for them.

Do not reuse the word id without deciding what it identifies. A tool-call ID, message ID and document ID name different objects. If two document revisions need to remain separately citable, use versioned document identifiers instead of overwriting one ID’s text.

The workshop’s replace-by-ID policy is chosen for this fixture. An audit trail should retain the prior version somewhere separate when the application needs it.

A checkpointer stores graph state for a thread so a later invocation can continue it. InMemorySaver is convenient for learning, but its contents disappear when that Python process ends. A production service needs an appropriate persistent backend and an access policy for the saved data.

A store is a different persistence mechanism for application data shared across threads. Keep a technician’s preference separate from the unfinished state of a particular inspection request. Retention and deletion rules apply to both.

An in-memory demonstration of resume is not a demonstration of crash recovery across process restarts.

interrupt exposes a value to the caller and pauses execution. When the application later invokes the same graph and thread with Command(resume=...), that value becomes the result of the interrupt call. The code in the interrupted node begins again on resume.

The reference pauses after collecting an invented excerpt. The automatic True near the end stands in for the service’s authenticated review handler. It is useful for observing control flow, but it is not an approval system.

Use the same thread configuration for resume. Creating a new thread would describe a new request rather than continuing the paused one.

from typing import Annotated, TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.types import interrupt, Command

def merge_evidence(old: list[dict], incoming: list[dict]) -> list[dict]:
    by_id = {item["id"]: dict(item) for item in old}
    for item in incoming:
        by_id[item["id"]] = dict(item)
    return list(by_id.values())

class State(TypedDict):
    evidence: Annotated[list[dict], merge_evidence]
    approved: bool

def collect(state: State):
    return {"evidence": [
        {"id": "manual-7", "text": "Inspect the mounting."}
    ]}

def review(state: State):
    decision = interrupt({"evidence": state["evidence"]})
    return {"approved": decision is True}

builder = StateGraph(State)
builder.add_node("collect", collect)
builder.add_node("review", review)
builder.add_edge(START, "collect")
builder.add_edge("collect", "review")
builder.add_edge("review", END)
graph = builder.compile(checkpointer=InMemorySaver())

config = {"configurable": {"thread_id": "maintenance-request-17"}}
paused = graph.invoke({"evidence": [], "approved": False}, config)
print(paused["__interrupt__"])
# In a service, obtain this decision from an authenticated reviewer.
resumed = graph.invoke(Command(resume=True), config)
print(resumed["approved"])

Imagine creating a work order before the review node pauses. Resuming the node could run that statement again. Now the technician has two orders even though there was one request. Place the effect after the decision, and still design the operation to tolerate retries and process failures.

An idempotency key lets the work-order service recognise the same intended action. The receiving service must store and enforce that key, ideally atomically with creation. A local set of completed IDs does not protect against a crash between creating the order and recording its ID.

Checkpointing the graph and making external effects idempotent solve related but different problems. Neither creates a universal exactly-once guarantee.

Two retrieval branches may find different text under the same document ID. Our simple last-update-wins reducer assumes an ordered update stream. If the order is not meaningful, the answer can depend on which result reaches it last.

Use immutable versioned IDs, reject conflicting updates, or define an ordering from trusted revision information. Choose a rule that matches the source system. Adding a reducer removes an implementation ambiguity only when its policy is appropriate for the data.

The workshop is sequential. Its fixtures make the update order explicit rather than claiming to settle concurrent document conflicts.

Select another thread in the workshop and run the same construction. It should load that thread’s excerpts before applying its update. Then replay an existing excerpt and check that one ID remains.

If the old machine simply concatenated lists, the repeated-lookup fixture exposes the mistake. If it hard-coded one thread’s evidence, the other-request fixture exposes that instead. These are different failure modes, so keep both checks after making a repair.

The Python challenge asks you to write the merge operation without mutating either input. Saved state is easier to reason about when an update does not quietly rewrite the fixture used by another test.