Foundations
MDX
Agent Memory Explained
The difference between working context, durable memory, retrieval, and application state.
Editorial review: clarity, operational relevance, safety boundaries, and source quality.
Context is working memory
The context window holds the information available to the model for the current decision. It is temporary, limited, and increasingly noisy when filled with an entire interaction history.
Context management is an allocation problem. Recent messages are not automatically the most important material; the current objective, decisions, constraints, and unresolved questions usually deserve priority. Summaries should preserve provenance and uncertainty so compression does not turn a tentative inference into a durable fact.
Durable memory is selective
Long-term memory stores information outside the model, such as preferences, decisions, or task summaries. The system needs rules for what is worth saving, how it is retrieved, and when it expires.
Long-term memory needs a write policy as much as a retrieval system. Store only facts with a defined future use, attach source and time, separate user-provided preferences from model inferences, and allow correction or deletion. Retrieval should consider relevance, recency, confidence, and access—not vector similarity alone.
State is not memory
Authoritative facts such as payment status or workflow stage belong in a database, not a conversational memory. Agents may read that state, but application logic should remain the source of truth.
Operational state belongs in schemas with transactional guarantees. A task's approval status, payment result, or current owner should never be reconstructed from chat history. Memory can help personalize how the agent communicates about that state, but it must not silently override the system of record.
Practical example
Memory in a travel assistant
The system may save a user's stated preference for morning flights, with source and consent. It retrieves that preference when comparing itineraries, but checks the booking database for the current trip and the airline for live availability. A model inference that the user 'probably dislikes connections' remains session context unless confirmed. Preferences, task state, and external facts follow different lifecycles.
Field checklist
Apply it in practice
- Separate session context, durable memory, and authoritative state.
- Define why each memory may be stored and when it expires.
- Preserve source, timestamp, and confidence.
- Provide user-visible correction and deletion paths.
Decision framework
Questions to answer before you build
Context, durable memory, and authoritative application state solve different problems. Mixing them creates stale facts, privacy risk, and behavior that users cannot inspect or correct.
Will this information matter later?
Save only information with a defined future use. Attach source, timestamp, confidence, and an expiry or review policy.
Is it a preference, inference, or fact?
Keep user-stated preferences separate from model inferences. Confirm consequential inferences before allowing them to shape future behavior.
Where is the source of truth?
Payments, approvals, ownership, and workflow stage belong in transactional systems. Memory may point to them but must not override them.
Common failure signals
Watch for these warning signs
- Saving entire conversations because selecting useful memories is difficult.
- Retrieving by similarity without checking recency, permission, or provenance.
- Letting a summary convert tentative reasoning into a durable fact.
Selected primary references
Continue with the source material
These sources inform the wider editorial perspective for this topic. They are not presented as line-by-line citations for every statement.