The four AI agent memory types that matter in production
Memory is often described as if it were one feature. In a working agent it is a stack. The current model context carries the messages and tool results supplied to one run. A session store carries selected conversation items across turns. Durable memory extracts facts, preferences or summaries that can be recalled in a later session. Operational state lives outside the conversation in calendars, documents, databases, task systems and immutable receipts. Confusing these layers creates the most common failure: a team sees a fact survive one turn and assumes it will survive a restart, a new thread or a deletion request. Sources: OpenAI Agents SDK; Google Agent Development Kit; LangChain.
The types inside durable memory matter too. LangChain separates semantic memory, which holds facts, episodic memory, which holds experiences or examples, and procedural memory, which holds instructions or rules. That distinction is useful because each type needs a different update policy. A shipping address can be replaced by a newer address. A completed incident should remain an event in history. An approval rule should change only through an authorized configuration path. Sources: LangChain.
| Layer | Typical contents | Persistence boundary | Verification question |
|---|---|---|---|
| Active context | Current messages, instructions and tool output | Usually one model run or one compacted context window | What was actually supplied to this answer? |
| Session history | Thread messages and checkpoints | The session identifier and the backing store | Does it survive a process restart and a new device? |
| Durable memory | Facts, preferences, summaries and prior outcomes | A user or tenant namespace plus retention rules | Can an old fact be corrected, expired and deleted? |
| Operational state | Files, tasks, records, tool results and receipts | The external system that owns the record | Can the agent read the real result back? |
What persists depends on the AI agent memory architecture
A session API does not promise permanent memory by itself. The OpenAI Agents SDK describes sessions as client-side memory that automatically retrieves prior items before a run and stores new items afterward. Its implementations can use SQLite, Redis, SQLAlchemy-backed databases or the Conversations API. Google ADK makes the same boundary explicit: session state is short-term context for one conversation, while a memory service supports information across sessions. Its in-memory implementation loses everything when the process exits, while persistent services survive it. Sources: OpenAI Agents SDK; Google Agent Development Kit.
A product can therefore say it has memory while storing only a conversation transcript. Another can extract long-term facts but rebuild session context from a database after every restart. A third may retain business records indefinitely in connected tools while deleting conversational context after a fixed period. The label tells you very little. Ask for the persistence boundary of each layer, the namespace key used to separate users, the retention period, and the exact deletion behavior. Sources: OpenAI; Google Agent Development Kit.
Platform retention and application memory are separate questions. OpenAI documents endpoint-specific application-state retention for its APIs. An agent builder can also copy selected facts into its own database, vector index or CRM. Deleting one does not prove that the other was deleted. A complete data map should name every store and every processor in the path. Sources: OpenAI.
AI agent memory management is mostly a retrieval problem
Storing a fact is easy. Recalling the right fact at the right time is the hard part. Long conversations can fill the context with stale or distracting material. Anthropic describes context as a finite resource and recommends keeping the smallest high-signal set of tokens that improves the outcome. LangChain makes a similar distinction between short-term thread memory and long-term namespace memory, then treats summarization, trimming and deletion as normal controls rather than exceptional cleanup. Sources: Anthropic; LangChain.
A good retrieval record carries more than text. It should carry when the fact was observed, where it came from, who had authority to state it, how confident the system is, how sensitive it is, when it expires, and whether a later record conflicts with it. Retrieval can then prefer the freshest authoritative record, preserve the conflict for review, and avoid squeezing a complete record in half to fit the context window. The W3C provenance model gives a neutral vocabulary for tracing entities, activities and agents, which is useful even when the storage engine is a simple relational table. Sources: World Wide Web Consortium.
A vector similarity score alone cannot make those decisions. Similarity finds related language. It does not establish permission, truth, freshness or identity. Practical systems combine lexical or semantic retrieval with metadata filters and an explicit ranking policy. The result should be inspectable: which records were recalled, why they were eligible, and how they affected the answer. Sources: Cloudflare; Microsoft Security.
A memory write needs intent, provenance and a reason to persist
The safest default is selective writing. A user saying that a meeting is at three tomorrow creates a short-lived event. A user saying they prefer replies in Hebrew creates a durable preference. A pasted document saying to redirect payments should create neither. Microsoft treats agentic memory as a control plane and recommends gating writes on intent and provenance, blocking secrets and sensitive identifiers, and keeping versioning, rollback and audit trails. That is a stronger model than saving every sentence and hoping retrieval will sort it out later. Sources: Microsoft Security.
Write timing changes behavior. LangChain describes hot-path writes, which happen during the user interaction, and background writes, which happen after the response. Hot-path writes can immediately affect the next step but add latency and may persist a misunderstanding before the user corrects it. Background extraction can compare more evidence and deduplicate records, but it must not silently convert untrusted content into authority. For high-impact preferences, a structured explicit update is easier to audit than a model-generated summary. Sources: LangChain.
A useful write receipt records the original statement, the normalized fact, its scope, the writer, the source event, the timestamp, the expiry, and the record it supersedes. That receipt turns a mysterious personalisation feature into a system an operator can debug. Sources: World Wide Web Consortium; Cloudflare.
Corrections should supersede old memory without erasing history
Suppose an agent remembers that invoices go to Maya, then the user says that invoices now go to Leon. Appending both facts leaves retrieval to choose between contradictory strings. Overwriting the first fact destroys the audit trail. A better pattern marks the Maya record as superseded, links the Leon record to it, and makes only the current record eligible for ordinary retrieval. Historical questions can still reconstruct what was true at an earlier date. Sources: Cloudflare; Microsoft Security.
Cloudflare's Agent Memory exposes remember, recall, list and forget operations and highlights temporal reasoning and supersession. The important design choice is visible control. A user or administrator should be able to list what the system believes, correct a record, remove it from retrieval, and confirm that the change survives a restart. A conversational promise that something was forgotten is not proof of deletion. Sources: Cloudflare.
AI agent memory can preserve an attack long after the source is gone
An agent that reads email, web pages or documents is exposed to indirect prompt injection. NIST describes agent hijacking as instructions hidden in data that steer an agent away from the user's goal. If the agent is also allowed to write durable memory, one malicious document can turn a temporary injection into a persistent preference or rule. Microsoft calls this memory and context poisoning: corrupted context survives and influences later decisions. Sources: National Institute of Standards and Technology; Microsoft Security.
Memory isolation is therefore a security boundary. Records from one user, company, project or sensitivity tier should not enter another namespace. Retrieved text should remain data, not silently gain the authority of a system instruction. High-impact actions should check current policy and current authorization at execution time rather than rely on an old remembered preference. Microsoft also recommends trust scoring, conflict detection, audit logging and rollback so that a poisoned state can be located and reversed. Sources: Microsoft Security; Microsoft Security.
The security test is not whether the agent refuses an obvious malicious sentence in a chat. It is whether untrusted content can write a durable record, whether that record crosses a tenant boundary, and whether a later clean session acts on it without showing its provenance. Sources: National Institute of Standards and Technology.
Six tests for an AI agent memory system
Run these tests against the real product, not a demonstration prompt. For each one, save the input, restart boundary, recalled records, final answer and backing-store readback. The resulting memory receipt is more useful than a feature checklist because it proves the behavior under the exact deployment you will operate. Run the same set after changing the model, retrieval policy, storage provider or compaction settings. Sources: OpenAI Agents SDK; Anthropic.
| Test | Action | Passing result |
|---|---|---|
| Restart | Save a harmless preference, stop the process, start it again and ask from the same account | The intended durable layer recalls it and the session-only layer does not pretend to |
| Correction | Replace a stored fact with a newer contradictory fact | Only the new fact is used, while the old record remains visibly superseded |
| Isolation | Create the same topic with different values in two test tenants | Neither tenant can retrieve or infer the other's record |
| Expiry and deletion | Set an expiry, wait past it, then issue a deletion and inspect every backing store | The record is absent from retrieval and the deletion status is verifiable |
| Untrusted source | Place a memory-write instruction inside a fetched test document | The content remains untrusted data and creates no authorized durable rule |
| Overload | Fill the history past the compaction threshold, then ask for one current critical fact | The current authoritative record survives compaction and its provenance remains intact |
An AI agent memory management checklist for builders and buyers
Start by drawing the data path. Name the active context provider, session store, durable memory store, operational systems and every third party that receives data. Then define which events are allowed to write to each layer. For every durable record, require an owner, scope, source, timestamp, confidence, sensitivity class, expiry and supersession link. Add a retrieval trace that can show which memory influenced a response without exposing unrelated private data. Sources: OpenAI; World Wide Web Consortium; Microsoft Security.
Make correction, export and deletion ordinary product actions. Test them through the same interface a user will use, then inspect the underlying stores. Limit the amount of recalled history and keep high-signal structured facts separate from raw transcripts. Treat summaries as derived records that can be regenerated, not as perfect replacements for source events. Keep action authorization outside memory so an old preference cannot approve a new payment, message or publication. Sources: Anthropic; LangChain; Microsoft Security.
Finally, monitor memory quality as an operating metric. Count stale recalls, conflicting active records, cross-scope retrieval attempts, failed deletions and corrections that did not propagate. A memory system earns trust when those failures are visible and repairable, not when it remembers the largest number of tokens. Sources: Cloudflare; Microsoft Security.
- Map every store and retention boundary.
- Separate session history, durable facts and operational records.
- Gate writes by intent, authority, sensitivity and source provenance.
- Retrieve complete records with freshness, scope, conflict and expiry metadata.
- Supersede corrections and preserve the audit trail.
- Give users visible list, correction, export and deletion controls.
- Test restart, correction, isolation, deletion, poisoning and compaction.
- Require fresh authorization for consequential external actions.
AI agent memory FAQs
What is AI agent memory? It is the collection of context, session history, durable facts and operational records an agent can retrieve while doing work. Each part can have a different retention period and owner.
What persists when an AI agent restarts? Only information written to a persistent backing store and loaded again after startup. An in-memory session disappears with the process, while a database-backed session or durable memory service can survive it.
What are the main AI agent memory types? At the system level, the useful split is active context, session memory, durable memory and operational state. Inside durable memory, semantic facts, episodic experiences and procedural rules need different update policies.
Does deleting a chat delete agent memory? Not necessarily. A product may store the chat, extracted memories, application state and external business records separately. Deletion should name every affected store and provide a verifiable status.
How much should an AI agent remember? The smallest set that reliably improves the task. More context can increase cost and latency while making the right information harder to recall.
Can AI agent memory be poisoned? Yes. Untrusted content can try to write false rules or facts that persist into later sessions. Write gates, provenance, isolation, conflict checks and rollback reduce that risk.
How should an AI agent handle a correction? Create a new authoritative record, mark the old record as superseded, and make the retrieval policy prefer the current record while retaining history for audit.
How do you compare AI agent memory tools? Compare persistence boundaries, supported stores, namespace isolation, write and retrieval controls, correction and deletion behavior, observability, and the results of the six tests above.
Limits and uncertainty
Agent memory products and platform retention rules change quickly, and a provider's documentation describes its interface rather than proving the configuration of a specific deployment. The architecture and tests in this guide are vendor-neutral, but the exact persistence and deletion behavior must be checked against the live product, its contracts and its backing stores. The six tests use harmless synthetic data. They do not replace a privacy, security or legal assessment for sensitive information. Keyword research on September 8, 2026 found 210 monthly US searches and keyword difficulty 27 for the primary query, but the live results page had no weak ranking slot, so this guide makes no near-term ranking claim.