Persistent state lets a workflow resume and coordinate. “Memory” is often an overloaded label for conversation history, run checkpoints, customer facts, retrieved documents, or learned preferences. Store each kind deliberately; never dump everything into a vector database and call it memory.
After this lesson, you can design a state schema with authority, provenance, retention, and conflict rules.
Classify State
| Type | Example | Lifetime |
|---|---|---|
| run state | current step, attempt, tool result | one workflow plus audit period |
| business state | order status, assigned owner | authoritative business retention |
| conversation context | recent approved messages | shortest useful window |
| profile preference | chosen language | until changed/deleted |
| knowledge | approved policy version | versioned publication life |
| evaluation | expected and actual outcome | controlled improvement dataset |
The agent’s summary is not authoritative business state. Store order, payment, identity, and consent facts in their proper systems.
Add Provenance and Versioning
Every persisted fact needs source, timestamp, version, confidence where relevant, tenant, and expiry:
{
"key": "preferred_language",
"value": "roman_urdu",
"source": "customer_selection",
"recorded_at": "2026-07-19T10:00:00Z",
"tenant_id": "client_12",
"expires_at": null
}
Summaries should link to the source records they represent. On conflict, follow an explicit rule; do not let the newest model-generated sentence overwrite verified data.
Checkpoint for Resume
Persist a state machine after committed transitions:
run_id, workflow_version, current_state, completed_actions,
pending_approval, budget_used, last_error, next_allowed_action
Use optimistic concurrency or locks so two workers cannot advance the same run. Tool effects remain idempotent if a worker crashes after the effect but before the checkpoint.
Worked Example
A recruitment assistant prepares interview packs. It stores job ID, approved criteria version, candidate reference, completed document checks, draft state, and pending reviewer. CV text has restricted retention and access. It does not store inferred religion, ethnicity, health, or family status.
A worker crashes after creating draft D-44. On restart, the system sees the stable idempotency key and retrieves D-44 rather than creating another pack. A recruiter correction is recorded as human-authored business state; a later model summary cannot overwrite it.
Failure Cases to Diagnose
- Full transcripts stored forever: define purpose and deletion.
- Embedding used as exact lookup: retrieve authoritative IDs and fields directly.
- No tenant filter: enforce tenancy in the data layer.
- Concurrent workers overwrite state: use version checks or locks.
- Model summary loses a critical exception: retain source links and typed fields.
- Deleted customer remains in evaluation data: propagate deletion where required.
- Workflow code changes mid-run: pin workflow version and migrate explicitly.
🇵🇰 Pakistan Angle
Minimize phone numbers, addresses, CNIC data, bank information, CVs, and customer messages. Do not store them merely to make future prompts “smarter.” Define who can access records, how an individual can request correction/deletion, and which legal or contractual retention applies.
For multilingual conversations, store the customer’s explicit language preference and original approved text where needed; do not persist a model’s guess about literacy or education. Keep PKR amounts, dates, and transaction references in typed fields, not narrative memory.
Hands-On Exercise
- Classify every field in one workflow.
- Name its authority, source, tenant, retention, and deletion path.
- Design the checkpoint schema and concurrency rule.
- Test crash-after-effect, conflicting update, and deletion propagation.
- Remove any field without a named purpose.
Done means: a run can resume once, not duplicate actions, and every persisted fact is traceable, bounded, and correctable.
Completion Rubric
- State types and authorities are separated.
- Provenance, version, tenant, and retention are recorded.
- Checkpoints support safe resume.
- Concurrency and idempotency prevent duplicate transitions.
- Sensitive data is minimized and access-controlled.
- Correction and deletion paths are tested.
Sources
Key takeaway: persistent context is a governed state system—typed, sourced, versioned, tenant-safe, resumable, and deletable—not an unlimited transcript archive.