Run the original resolution

For the complete documentation index see: llms.txt

All documentation pages available in markdown.

The support graph lives in agent.py and the phased demo in demo.py. Open those files to see how the graph nodes run and how AerospikeSaver writes a checkpoint after each super-step. By the end of Phase 1, the thread holds a chain of checkpoints for support-thread-7842, including one where the order is known but no resolution is selected yet. That row becomes the reuse point in Phase 3.

Start the demo

From the repository root, run the demo:
Terminal window
```
uv run python cookbooks/agent-path-correction/demo.py
```
The script deletes any prior state for support-thread-7842, then pauses between phases. Leave the terminal open through the rest of this tutorial.
Advance to Phase 1:

Phase 1 simulates the original support ticket. The customer mentions broken AeroPro headphones and asks for a refund. The graph starts with empty state (order_id, intent, and resolution all unset) and must derive the order id from the product mention before classifying intent and selecting a resolution.

Press Enter when the demo prompts you.

Review Phase 1 output:

Watch order_id. The graph should derive ORD-10482 from the product mention in the customer message, without being given the order number directly.

================================================================
Phase 1 - The original ticket
================================================================
  starting state : order_id=None  intent=None  resolution=None  (nothing derived yet)
  user        > I bought a pair of AeroPro headphones that arrived broken. I'd like a refund.
  assistant   > I can handle that as a refund for order ORD-10482.
  order_id    : ORD-10482  (derived from 'headphones')
  intent      : refund
  resolution  : Refund selected for order ORD-10482

Confirm Phase 1 resolved the refund:

The support graph ran identify_order, then classify, then resolve. AerospikeSaver wrote a checkpoint after each super-step, so Aerospike now holds the full refund timeline for support-thread-7842.

Before moving on, the demo records which checkpoint holds the final refund decision. Phase 5 reads that row back by order ID to write a handoff note. Forking in Phase 4 does not touch it.
- order_id is ORD-10482 after the graph run.
- intent is refund and resolution references the same order id.
Five checkpoints now exist for this thread. The next part introduces a corrected customer request and walks the checkpoint table to find the row saved after order lookup but before any resolution was chosen.