Checkpoints, persistence, and memory

Overview

• A checkpoint records execution progress and state at a recovery boundary.
• Persistence saves it outside the process.
• Memory is selected information reused by later turns or tasks; a checkpoint is not automatically good long-term user memory.

Why this matters

Users return later, workers restart, and approvals may take hours.

An everyday example

Save your position in a case checklist; a customer profile is a different record.

A technical example

Persist graph checkpoints in a supported database backend; store approved language preference separately.

How it works

1. Execute step
2. Checkpoint state/progress
3. Associate with authorized thread
4. Load on continuation
5. Resume compatible graph version.

Architecture and flow

Graph runtime ↔ durable checkpoint store; context builder ↔ scoped memory store.

The insurance assistant example

A customer confirms a claim draft tomorrow without starting document collection again.

When to use it

Stateful conversations, approvals, and recoverable multi-step runs.

When to avoid it

Do not use process-memory checkpoints for production durability or assume persisted history should all be sent to the model.

Interview answer

“Checkpoints recover execution; long-term memory supports selected continuity. I isolate them and enforce thread ownership and retention.”

Benefits, trade-offs, and production considerations

• Back up checkpoint stores, encrypt sensitive data, serialize updates for the same thread, and plan graph migrations.
• Index tenant/thread ownership separately.
• Checkpoint persistence does not make database writes and external calls one atomic transaction.
• LangGraph persistence.