AI agent memory: how agents remember (and forget)
An AI agent maintains context by receiving the instructions, exchanges, and results relevant to its task at each step. To remember information beyond that limited workspace, the application can store summaries, files, or facts in external memory and retrieve them when needed. A stored memory does not necessarily inform the answer: the application still has to select it, and the model has to interpret it correctly.
Context is what the model can see right now
The context window is the amount of information a model can process in a single request. It holds your request, the application’s instructions, part of the conversation, and tool results, among other information. It is the model’s immediate workspace.
The history shown on screen can differ from the context actually sent to the model. An interface may keep an entire conversation while sending the model only an excerpt or a summary. Seeing an old message in the app does not prove that the agent can still read it.
This distinction explains an apparent contradiction: an agent may pick up the general topic while forgetting an exception you gave earlier. The application may have preserved the topic in a summary but left out the detail that now matters.
A large context window does not guarantee perfect reading, either. The paper Lost in the Middle, published online in 2023 shows that, for the models and tasks studied, the position of information within a long context affects retrieval. These findings do not measure the performance of models available in October 2026. They do suggest testing what a model recalls instead of relying solely on its advertised capacity.
As the article AI agent or chatbot: what’s the difference? explains, memory is not exclusive to agents. A chat interface can also retain information between exchanges.
Different kinds of memory serve different purposes
The word “memory” covers several distinct mechanisms. To understand them, separate what travels with a conversation, what allows a task to resume, and what remains available across sessions.
| Mechanism | What it retains | How it is used | Main limitation |
|---|---|---|---|
| History sent to the model | Recent messages and results | Read within the current context | Accumulation and size limits |
| Conversation summary | Goal, decisions, unresolved questions | Added back in place of older messages | Details may be lost |
| Saved state | Progress, variables, references to results | Resumes an interrupted task | Does not provide general knowledge |
| Persistent memory | Preferences, facts, notes, and procedures | Loaded or retrieved as needed | Wrong selection or outdated information |
The memory documentation distinguishes memory tied to a conversation from memory that spans conversations. In LangGraph, a thread’s state can be saved through checkpoints. A separate store can retain information beyond that thread.
Retention time and access scope are therefore separate questions. State saved for a long time may remain limited to a single task. A persistent preference, meanwhile, may be available across several conversations belonging to the same user.
Stored information also varies in nature: facts about a project, records of past actions, or procedures to follow. These categories help organize storage; they do not imply lived experiences or consciousness. Entries in the AI agent directory help identify the memory mechanisms documented for each solution.
How information becomes a useful memory
Consider a fictional example: you ask an agent to prepare your reports in French while keeping technical terms in English. An application with memory could extract that preference, associate it with your profile, and save it. When you make another request, the application still has to decide whether the preference applies.
The process involves several operations: identifying the information, deciding its scope, saving it, retrieving it, and adding it to the context. An error can occur at any stage. In particular, a request intended for one occasion can mistakenly become a permanent preference.
Mem0 documents a mechanism for extracting and saving memories from messages, using identifiers to define their scope. This extraction creates a selective representation of the conversation. It does not automatically replace a complete, faithful archive.
To retrieve memories, an application can use keywords, structured fields, or an embedding, a numerical representation used to find content with a similar meaning. Even a relevant search can miss a negation or retrieve a fact that is no longer current.
The RAG guide explains this process of retrieving external information before generating a response. RAG can supply information to an agent’s memory, but the concepts are distinct: searching a document collection does not mean remembering your preferences. Likewise, a preference saved in a file can be reused without vector search.
Why an agent forgets or distorts an instruction
Forgetting can start with a failure to save information. A fact mentioned in a conversation has not necessarily been written to persistent memory. If you open another session, there is no guarantee it will be available.
The problem can also be a failure to read. The memory exists, but search does not find it, a project filter excludes it, or the application no longer has permission to access it. Adding more storage does not fix this retrieval problem.
Compression is another source of loss. A summary may retain a decision while dropping the conditions that made it valid. The distinction between a general preference and a temporary exception can disappear in the process.
Anthropic describes compaction, persistent notes, and clearing tool results as different context management strategies. Compaction replaces exchanges with a summary; notes preserve information outside the context; clearing removes bulky results. Their usefulness depends on which information needs to survive.
In a fictional example, summarizing an instruction as “prepare payment reminders” would lose an exception such as “exclude disputed invoices.” For a sensitive task, keeping the exact rule and its source is preferable to retaining only a paraphrase.
Finally, an agent can produce a plausible answer without having retrieved the expected memory. Confident wording does not demonstrate that its memory has carried over.
Store less, but keep information verifiable
Useful memory should distinguish a confirmed fact from an assumption or a preference. Saving all of these as undifferentiated text makes corrections difficult: a model’s inference may eventually be treated as an instruction from the user.
For each useful memory, an application can retain:
- The source: an explicit message, a document, or a tool result.
- The date it was saved and, where needed, an expiration date.
- The scope: a person, project, team, or organization.
- The status: confirmed, needs verification, superseded, or expired.
These fields help resolve conflicting information. A recently confirmed address should be able to replace an old address without leaving the agent to choose arbitrarily between them. An expiration date also helps prevent a temporary constraint from becoming a permanent rule.
Storage does not have to be complex. The reference memory server in the MCP repository illustrates an approach organized around entities, relations, and observations. This structure can represent connected facts; it does not certify their accuracy.
Forgetting then becomes a capability that needs to be designed. It must be possible to correct a memory, revoke access to it, and delete representations that could cause it to resurface. Hiding an item from search does not establish that it has been erased from archives, copies, or backups. The expected behavior needs to be checked in the application you choose.
Persistent memory brings ongoing risks and costs
Malicious external content may try to get a false instruction saved for later tasks. This extends the risk of prompt injection: the malicious data is no longer trying only to influence the immediate response, but also future interactions.
A web page the agent reads should therefore not acquire the same authority as a user instruction. Information from external sources needs to retain its provenance. Rules shared by a team may also require tighter write permissions than working notes.
Separation between users deserves a specific check. A memory from one client’s case should not appear in another client’s case simply because the topics are similar. Access controls must apply during data retrieval, as well as when the response is written. The guide to securing an AI agent covers these precautions in more detail.
Memory can also incur several kinds of expense: extracting facts, generating summaries, indexing, storage, search, and processing memories added back into context. A long archive is not necessarily expensive to store, but repeatedly reading it can be.
The LLM pricing calculator helps estimate the token-related portion. To assess the full setup, add storage and search services, then measure whether memory actually reduces repetition and errors.
Test memory before assigning it a task
A useful test reflects how you intend to use the agent: provide a fictional preference, start another conversation, request a task where that preference applies, and then correct it. Next, check that the correction is used and that the old information does not return.
Also test what happens when a memory is missing. The agent should be able to say that information is unavailable and ask for clarification, rather than fill in the record with assumptions. For shared memory, also check that projects and users remain separated.
Key takeaways:
- Stored information still has to be retrieved before it can influence a response.
- A summary helps a task continue, with some risk of losing nuance.
- Memories need to be accessible for review, correction, and deletion.
- For sensitive decisions, require a verifiable source rather than relying on the agent’s assertion.
Frequently asked questions
Does an AI agent remember after you close the app?
That depends on where its state is stored. A saved conversation can be resumed after the app closes, while state held only in RAM disappears when the process ends. Also check whether a new conversation can access information from the previous one.
Does switching models erase an agent's memory?
Not necessarily, if the application stores the memories and passes them to the new model. A switch can still change how the model interprets them or which information it considers relevant. Compatibility with message and tool formats also needs to be checked.
Does agent memory require a vector database?
No. A notes file, a relational database, or a store of structured facts may be enough. Vector search becomes useful when an application needs to find information expressed in different ways across a collection of documents.
Can you export an AI agent's memories?
Check what the product supports: access to files, record exports, or a read API. A useful export preserves sources, dates, and the scope of each memory, rather than just its text. Those details make memories easier to correct and migrate.