State persistence and checkpoints

Overview

• State persistence stores task progress; checkpoints record recovery positions.
• Neither automatically means user preference memory.
• A durable claim workflow may need execution records even when conversational history is deleted under a different retention policy.

Why this matters

Recovery, auditing, and personalization have different data lifecycles.

An everyday example

A task checklist and a customer address book are separate records.

A technical example

runs stores phase and checkpoint; profiles stores approved preferences; claims stores authoritative business data.

How it works

1. Assign each data type an owner
2. Persist updates at clear boundaries
3. Reload authorized state
4. Revalidate facts
5. Resume.

Architecture and flow

Run → checkpoint DB; customer preference → profile DB; business outcome → claim DB.

The insurance assistant example

A pending approval is resumable without promoting a draft into an actual claim.

When to use it

Long-lived tasks and recovery across restarts.

When to avoid it

Avoid a single giant “memory” collection for messages, approvals, claim truth, and checkpoints.

Interview answer

“I separate execution checkpoints, user memory, and authoritative business records because their ownership and retention differ.”

Benefits, trade-offs, and production considerations

• Plan consistency and migration between these stores.
• The UI should show claim receipt data from the authoritative service, while run records explain how the assistant reached it.