Fork and write the handoff note

For the complete documentation index see: llms.txt

All documentation pages available in markdown.

In Phase 3 you picked checkpoint seq 3 from the history table: the moment right after identify_order set order_id to ORD-10482, before intent or resolution were chosen. Phase 4 is where that saved state pays off. The customer still wants a replacement, and the corrected message still does not mention headphones. Instead of starting a new thread (which would lose the order id), the demo sends the replacement text through the same graph while telling LangGraph to resume from that reuse checkpoint.

Phases 4 and 5 finish the story: run forward on the corrected path, then read the untouched refund checkpoint for a handoff note.

Phase 4: fork from the reuse checkpoint

Advance to Phase 4:

Phase 1 used prod_config (thread id only), so each super-step advanced the latest checkpoint. Phase 4 uses fork_point.config instead. That config is the reuse checkpoint’s id from Phase 3. Passing it to graph.invoke() tells LangGraph to load that saved state and continue from there, not from the refund outcome at the end of the thread.

The graph still runs identify_order → classify → resolve, but LangGraph skips nodes whose work is already captured in the checkpoint. identify_order already ran when seq 3 was written, so ORD-10482 is already in state. Only classify and resolve run on the replacement request. Watch for order_id staying ORD-10482 even though the new message never names the product.

Press Enter when prompted.

Review the fork output:

================================================================
Phase 4 - Fork from that checkpoint
================================================================
  user        > On second thought, please send a replacement instead.
  assistant   > I can handle that as a replacement for order ORD-10482.
  order_id    : ORD-10482  (reused from the checkpoint)
  intent      : replacement
  resolution  : Replacement selected for order ORD-10482
  -> The correction never mentioned the product, yet the order id carried over.

Phase 5: write the handoff note from saved history

Advance to Phase 5:

Phase 4 resolved the ticket as a replacement for ORD-10482. That is the outcome to act on now. Support agents often need the backstory: what the customer first asked for, what changed, and why the order id did not need to be looked up again.

Phase 1 saved the checkpoint id for the original refund resolution before Phase 2 introduced the correction. Phase 4 forked from an earlier row, so those refund checkpoints were never overwritten. Phase 5 reads that saved refund checkpoint back from Aerospike with get_tuple() and pulls the original request text and refund decision into an internal handoff note alongside the corrected request and replacement outcome from Phase 4.

Press Enter when prompted.

Review the handoff note output:

Watch the “Source fields read from Aerospike” section. Those values come from the original refund checkpoint that the fork left untouched.

================================================================
Phase 5 - Use history to write the handoff note
================================================================
  Internal note from saved state:
    Customer first asked for a refund, then corrected the request to a replacement.
    Order id stayed ORD-10482; no second order lookup was needed.
    Use current outcome: Replacement selected for order ORD-10482

  Source fields read from Aerospike:
    original request : "I bought a pair of AeroPro headphones that arrived broken. I'd like a refund."
    original decision: Refund selected for order ORD-10482
    corrected request: "On second thought, please send a replacement instead."
  -> The kept checkpoint supplies the before-state for this handoff note.

Confirm the fork and handoff note:

Phase 4 produced a replacement resolution while reusing ORD-10482 without a second order lookup. Phase 5 proved the original refund checkpoint is still readable and unchanged. The handoff note combines both: what the customer first asked for, what changed, and which outcome to use now.
- order_id matches the original run (ORD-10482).
- intent changed from refund to replacement.
- The handoff note cites both the original refund decision and the corrected request.
You branched to a different resolution path without repeating the order lookup. Prior checkpoints remain in Aerospike for audit or handoff.

Advance to the Result summary:

Press Enter once more to reach the closing summary. The demo confirms the historical checkpoint was not modified, the fork produced a different resolution, and the order id survived the rewind.

================================================================
Result
================================================================
  - Rewound to a saved checkpoint that already knew the order id and
    resumed down a new path -- reusing that context, not recomputing it.
  - The old final checkpoint is useful context for a handoff note:
    what the customer first asked for, what changed, and what to do now.

Confirm the Result summary:

The demo’s guardrails passed: the original refund checkpoint is unchanged, the fork produced a different resolution, and ORD-10482 carried over without a second lookup.
- Result bullets restate the rewind-and-resume pattern and why kept history feeds the handoff note.
- You completed all five demo phases plus the closing summary.

You listed checkpoint history from Aerospike, rehydrated a reuse point, forked to a new resolution path, and built a handoff note from saved state.

Stop Aerospike

Stop and remove the Aerospike container:
Terminal window
```
docker rm -f aerospike
```

Explore the cookbook source at cookbooks/agent-path-correction/ in the langgraph-aerospike repository for the full step-by-step code walkthrough.