Resume an agent after a crash or pod restart

A long-running agent dies with its pod, or the node is drained, or you ship a new image. The usual choices are starting over or snapshotting the whole process; Recall gives the agent a few kilobytes of its own records instead, and the next process starts from a briefing built from them.

The code

Runs as written: pip install polign-recall brings the client, the recall binary and a local polign_db. Swap local_dir for backend="polign" and a server URL when the database should live in your bucket, or for PostgreSQL, MongoDB or Qdrant.

from polign_recall import Client

# Process 1: the agent works and writes down where it is.
with Client(local_dir="./recall-data", agent=True) as client:
    with client.resume("billing-migrator") as agent:
        agent.update_working_state(goal="Move billing to the v2 API",
                                   plan=["find call sites", "migrate them", "run the tests"])
        agent.set_pointer("wip", "git_ref", {"repo": "github.com/acme/billing", "branch": "agent/wip"})
        agent.record_turn("assistant", "12 call sites found; migrating api/checkout.py first.")
        agent.milestone("call sites found", progress="1 of 12 files migrated")
# The process dies here, or the pod is replaced.

# Process 2, anywhere that reaches the same database: pick up from the records.
with Client(local_dir="./recall-data", agent=True) as client:
    with client.resume("billing-migrator") as agent:
        print(agent.context.fresh)        # False: there is something to resume from
        print(agent.context.briefing)     # hand this to the model as its first message

What it printed:

False
You are agent billing-migrator, resuming after your previous process stopped. Continue from your notes and last turns below; check only what you have reason to doubt.

## Working state (version 2, step 0, written 2026-11-03T18:54:43Z)
Goal: Move billing to the v2 API
Plan:
1. find call sites
2. migrate them
3. run the tests
Progress: 1 of 12 files migrated
Last milestone: call sites found

## Where your work lives
- wip (git_ref): repo=github.com/acme/billing branch=agent/wip

## Your most recent turns, verbatim
[assistant #1] 12 call sites found; migrating api/checkout.py first.

What the record looks like

Each call writes one record under the agent id, in a collection next to the memory collection (_agents added to its name). resume takes a lease on the id, so one process acts for the agent at a time, and every write carries the lease epoch; a process that stalled past its lease cannot land a late write. The working state, one turn and one pointer from the run above:

billing-migrator:ws:head   {"record":"working_state_head","epoch":"1","body":"{\"goal\":\"Move billing to the v2 API\",
                            \"plan\":[\"find call sites\",\"migrate them\",\"run the tests\"],\"progress\":\"1 of 12 files migrated\",
                            \"last_milestone\":\"call sites found\",\"version\":2,\"turn_seq\":1,\"updated_at\":\"2026-11-03T18:54:43Z\"}"}
billing-migrator:turn:1    {"record":"turn","seq":"1","epoch":"1","body":"{\"role\":\"assistant\",\"content\":\"12 call sites found; migrating api/checkout.py first.\"}"}
billing-migrator:ptr:wip   {"record":"pointer","name":"wip","epoch":"1","body":"{\"type\":\"git_ref\",\"fields\":{\"repo\":\"github.com/acme/billing\",\"branch\":\"agent/wip\"}}"}

Earlier versions of the working state stay as their own records (ws:1, ws:2), so you can read how the agent's plan changed. Tool calls that touch the world are recorded as actions before they run and closed when they return, so a call the crash interrupted is settled on resume instead of guessed at; Durable agent actions has that part.

Evidence

Measured on Resume without snapshots: a coding agent migrating 16 files was killed with SIGKILL at a random point and resumed in a fresh process through recall-langgraph. On November 3, 2026, 20 of 20 killed agents finished, for 0.2% fewer tokens on average than 10 uninterrupted runs (100.4k against 100.6k). Against a CRIU container checkpoint, Recall came back as the upgraded image on the newer model with 134 KB of records; the checkpoint was 15 MB and brought back the old image, the old model and the API key.

Where to go next

• Resume without snapshots, with the CRIU comparison
• recall-langgraph: hooks for create_react_agent and your own StateGraph
• Kubernetes Agent Sandbox: a recreated sandbox resumes where it stopped
• Recall vs pod snapshotting

Recall is typed, durable memory and state for AI agents. It stores corrections, decisions and task state as append-only records in your own object store (S3 or GCS), so an agent can be corrected without retraining and resumed after a crash, restart or pod replacement without snapshotting the process.