How applications preserve what happened, what is currently true, and what may be useful later—without pretending that a long chat transcript is memory architecture.
◷ Estimated reading time: 5 min
State and Memory Are Not the Same
State is the information required to continue a specific process correctly. Memory is selected information retained for future interactions or decisions.
An order workflow needs exact state: order ID, current step, approvals, and completed actions. A support assistant may also retain a preference such as the user's preferred language. Mixing these concepts leads to stale transcripts being used as if they were authoritative process state.
Common State Layers
Layer
Examples
Storage need
Conversation state
Recent turns, active topic
Session store
Workflow state
Current step, retries, approvals
Durable checkpoint
Domain state
Order status, account balance
System of record
Agent working state
Plan, observations, remaining budget
Trace / checkpoint store
Memory Types
Working memory: information needed for the current task.
Semantic memory: stable facts or preferences stored in a retrievable form.
Episodic memory: summaries of prior interactions or outcomes.
Procedural memory: reusable instructions or skills—often better represented as versioned configuration than learned recollection.
These labels are design aids, not guarantees that every system needs all four.
Write Policies and Memory Quality
Do not automatically store everything the model sees. A memory write policy should decide:
whether the information is useful later
whether the user expects it to be retained
whether it is sensitive or regulated
who may read, edit, or delete it
how confidence and provenance are represented
when it expires
Memory poisoning
If untrusted text is saved as a trusted fact or instruction, future sessions inherit the attack or error.
Checkpoints and Resumability
Long-running workflows should checkpoint deterministic state outside model context. A checkpoint allows a task to resume after a timeout or human approval without asking the model to reconstruct reality from a transcript.
Use stable identifiers and record completed side effects so resumed tasks do not repeat actions.
Summaries Are Derived State
Conversation summaries save context, but they are model-generated interpretations. Preserve links to source events when accuracy matters, and regenerate summaries when the underlying record changes. Never let a summary overwrite the system of record.
Key Takeaways
State is required for process correctness; memory is selected information retained for later usefulness.
Keep domain truth in systems of record and durable workflow state in checkpoints.
Memory writes require provenance, consent, sensitivity, access, and expiry policies.
Summaries are derived representations, not authoritative truth.
Checkpoint side effects to support safe resumability.
Which item belongs in a durable workflow checkpoint?
Why is a conversation summary not a system of record?
What is the safest default memory-write policy?
A task resumes after a timeout and creates the same ticket again. What was likely missing?