ALLMAcademy

C2

Thread State, Checkpoints, Tasks, and Memory

15 min2 optional deep dives

Choose the right storage scope instead of calling every retained value memory.

  1. 01Distinguish thread state, checkpoint, task handle, and long-term memory
  2. 02Choose retention and ownership rules for each kind of state
  3. 03Resume work without duplicating completed side effects

Choose state by scope and lifetime

decision table
State type Scope Typical lifetime
Thread state One conversation or run Minutes to days
Checkpoint One workflow snapshot Until completion or retention expiry
Durable task One long-running operation Until terminal result and TTL
Long-term memory Across threads Explicit product retention period

Checkpoints are restart points

A checkpoint records enough graph state to continue after a crash or pause. It may include messages, tool results, intermediate variables, budget counters, and the next scheduled node.

It does not automatically make external side effects exactly once. A payment or email tool still needs idempotency.

Durable tasks are handles

Long work should return a task identifier instead of keeping one request open. The client can poll, provide requested input, cancel cooperatively, or fetch the final result later.

Production failure modes

  • In-memory checkpoints disappear during a production restart.
  • Task identifiers are exposed without per-user ownership checks.
  • Long-term memory stores a wrong fact with no correction path.
  • Checkpoint retention grows forever because no deletion policy exists.
Deep dive: Event logs and replay

An event log stores changes rather than only full snapshots. Snapshots make restart fast; events make history and replay visible. Many durable systems use both.

References & deeper reading (2)

Retrieval Practice

Check one idea at a time

Question 1 of 3

Match each stored item to the best state type.

Match each item to its pair.