reliable · advanced · 60 min

Survive a restart, wait for a person

Build a claim flow that saves its place after every step, pauses for a human on large amounts, and pays exactly once.

HANDS-ON LAB · YOU RUN IT ON YOUR MACHINE · 4 STEPS
  1. Step 1 of 4

    Write the four steps as a graph and run one small claim end to end

    Run this to check

    uv run --with langgraph --with langgraph-checkpoint-postgres --with "psycopg[binary]" --with openai claim_flow.py start --thread t0 --amount 20

    You pass when

    The claim is paid in one run, and a payments table has one row for t0.

    Files you write

    • claim_flow.py
  2. Step 2 of 4

    Stop and wait for approval when the amount is over 100

    Run this to check

    uv run --with langgraph --with langgraph-checkpoint-postgres --with "psycopg[binary]" --with openai claim_flow.py start --thread t1 --amount 250

    You pass when

    The process prints that it is waiting for approval and exits. Nothing is paid.

    Files you write

    • claim_flow.py
  3. Step 3 of 4

    Approve it from a new process

    The second run is the real test. Any step that moves money must be safe to repeat.

    Run this to check

    uv run --with langgraph --with langgraph-checkpoint-postgres --with "psycopg[binary]" --with openai claim_flow.py resume --thread t1 --approve

    You pass when

    It carries on from the saved step and pays. Run the same command again: there is still exactly one payment row for t1.

    Files you write

    • claim_flow.py
  4. Step 4 of 4

    See the same contract in a ready-made stack

    Optional. Flisk's agent resource keeps sessions in a checkpoint store in the same way your flow keeps threads in Postgres.

    Run this to check

    flisk project agent-stack && flisk up

    You pass when

    A local stack starts with an agent, tools and a database. flisk status --json shows the resources; flisk agent sessions lists stored sessions, and they are still listed after flisk restart .

No transcript here on purpose. This page does not show terminal output, because model answers differ from run to run. Each step says what a pass looks like; your own terminal is the proof.