LangGraph Agents

Course Content

LangGraph Agents

7 sections · 49 lessons

What is “time travel” or replay in LangGraph terms, and how does it help debugging?

Forking the rejected Rs 64,000 claimafter extractoriginal: score 0.83fork: date fixedrejectfast_track
The fork proved the fault was the OCR date, not the fraud model, and the original branch stayed intact for audit.

What you need to know

Python
config = {"configurable": {"thread_id": "claim-88213"}}history = list(graph.get_state_history(config))        # newest firstbefore = next(s for s in history if s.next == ("decide",))# Replay: re-run everything after this checkpointgraph.invoke(None, before.config)# Fork: edit state, then run the branchforked = graph.update_state(before.config, {"fraud_score": 0.2}, as_node="score")graph.invoke(None, forked)

Replay versus fork

Replay

  • invoke(None, past_config)
  • Same state as it was
  • Nodes after the checkpoint run again, live
  • Tests: is the failure repeatable?

Fork

  • update_state(past_config, values) then invoke
  • State edited at that point
  • New branch; original history kept
  • Tests: would a different input fix it?

as_node tells LangGraph which node "wrote" the edit, so it knows what runs next — the successors of that node.

Why it matters for agents

Agent failures are non-deterministic and costly to reproduce. Time travel lets you:

  • skip the expensive early steps and re-run only the failing part;
  • test "what if the search had returned X?" with one edit;
  • compare three prompts from an identical starting state;
  • repair a user's stuck session and continue it instead of starting over.

Replay re-runs model and API calls, so outputs can differ, and side-effecting nodes will fire again. Replay in a staging copy, or with side effects disabled.

A real-life example

An insurance claim graph rejected a genuine Rs 64,000 hospital claim. The engineer lists the thread's history and finds the checkpoint before decide. The state shows fraud_score=0.83, driven by a date mismatch: the OCR read the admission date as 2062 instead of 2026. She forks with update_state(..., {"admission_date": "2026-08-14"}, as_node="extract") and runs it: fraud_score drops to 0.11 and the claim goes to fast_track. That proves the bug is in extraction, not in the fraud model, and gives a test case for the fix. The customer's real claim is then corrected the same way and continued.

Follow-up questions to expect

  • "Does replay cost money?" — Yes, for nodes after the checkpoint. Nodes before it are loaded from the checkpoint, which is where the savings come from.
  • "Does update_state rewrite history?" — No. It adds a new checkpoint branching from the old one; the original path stays for audit.
  • "Is there a UI for this?" — LangSmith Studio shows the thread's checkpoints and lets you edit state and re-run from a point.