Persistence and Human-in-the-Loop

You have state. You have a graph. On a large refund you still stop in the same program run.

Real life needs this:

  1. Monday — agent reaches “needs approval”
  2. Save the state
  3. Program exits
  4. Tuesday — human says yes
  5. Load the state and continue — refund, without looking up the order again as if nothing happened

That is persistence + human-in-the-loop (HITL).


Same refund story

Person’s question: “Please refund order 4412.”
Amount is large. Graph path:

lookup → decide → wait_human

At wait_human, do not pretend the human is inside your while loop.

Stop. Save. Human. Load. Continue.
  run graph → wait_human


  SAVE state to a file


  (time passes — human decides)


  LOAD state + set approved = yes


  continue → refund → done

Persistence = remember on disk

Persistence means: write state somewhere that survives when the program ends.

For learning, a small JSON file is enough:

{
  "order_id": "4412",
  "amount_usd": 900,
  "size": "LARGE",
  "approved": "not_yet",
  "status": "needs_approval",
  "next_node": "wait_human"
}

Later you might use a database. The idea stays: state outlives one run.

Also save where you stopped (next_node or status). Otherwise you do not know which node to resume.


Human-in-the-loop = a person is a step

Human-in-the-loop means a person must decide before the workflow continues.

Human says What state becomes Next node
yes approved: yes refund
no approved: no done (with a “denied” reply)

The human is not a model call. Your program:

  1. Stops at wait_human
  2. Shows the facts (order, amount)
  3. Waits for yes/no (button, ticket, or a line in a file for the lab)
  4. Writes the decision into state
  5. Runs the next node

Worked walk-through

Run A (Monday)

  1. lookup → amount 900
  2. decide → LARGE
  3. wait_human → reply needs approval
  4. Save state + next_node: after_approval
  5. Exit

Human (Tuesday)
Approves order 4412.

Run B (Tuesday)

  1. Load state
  2. Set approved: yes
  3. Node refund → “Refunded $900…”
  4. done

No second random lookup. State already had the amount.


Rules that save pain

Rule Why
Save before you exit Lost state = lost job
Save the next step Resume needs a clear restart point
Do not refund twice After resume, check status / approved
Keep the human decision in state Audit trail: who said yes

What you can build now

Idea You have it
Shared facts Explicit state
Visible path Graph nodes + edges
Pause for a person Persistence + HITL

Next: Agent Frameworks — tools that package these ideas so you write less runner code yourself.


Words to keep

Word Meaning
Persistence Save state so it survives after the program ends
Resume Load state and continue from the right node
Human-in-the-loop (HITL) A person must approve (or edit) before the next step
Checkpoint A saved snapshot of state (and often “which step”)

See it in Code

The Code panel runs the large-refund path, saves state to a file, simulates a human yes, loads state, and finishes the refund. Check the Example console.