State, Memory, and Checkpoints

Fact-check status

Reviewed claim by claim on 2026-09-02 against the primary or official sources identified inline as S1 and S2. Recommendations are design guidance unless a cited standard makes them normative.

Key jargon

Term	Plain-language meaning
State	The authoritative data describing the current workflow position and values. S1
Memory	Information retained for later use, often selected or summarized from prior interactions. S1
Checkpoint	A durable snapshot from which execution can resume. S1
Event log	An append-only sequence of facts describing state transitions. S1

Key concepts

Conversation history, workflow state, and long-term memory solve different problems and should not be conflated. S1
Durable checkpoints make interruption, approval, retry, and incident reconstruction possible. S1

Concept map

flowchart LR
    A["Observe event"] --> B["Persist state transition"]
    B --> C["Create checkpoint"]
    C --> D["Resume with selected memory"]

Diagram semantics verified against S1 and S2 on 2026-09-02.

Kind	Example	Lifetime S1
Turn context	Current user message	One invocation S1
Run state	Completed steps and pending approval	One workflow run S1
Artifact	Draft, report, code patch, dataset	Project-defined S1
User memory	Preference explicitly saved for future use	Until expiry/deletion S1
Knowledge memory	Curated facts with source and version	Until superseded S1
Model weights	Learned behavior from training	Model release S1

Do not call the conversation window “memory” without qualification. Durable memory needs consent, provenance, namespace, conflict handling, retention, and deletion. S1

Checkpoint contents

Task contract, policy version, current state, completed effects, pending effects, artifacts, evidence references, budgets, and safe resume instruction. S1

Exercise

Design a resumable three-step research workflow. Simulate interruption after step two and show how the checkpoint prevents repeating an external action.