A customer changes a requirement. You ask your agent to revisit an architecture decision. It retrieves the original choice, but misses why you accepted higher latency to guarantee consistency. Its proposed change meets the new requirement and breaks that guarantee. To change a decision safely, your agent needs to remember the tradeoffs behind it, and re-compute a decision without forgetting variables. That's the central challenge of agent memory in 2026 — and it is measured: LongMemEval, presented at ICLR 2025, found commercial chat assistants and long-context LLMs showing a 30% accuracy drop on memorizing information across sustained interactions.
Key takeaways
Table of contents
1. What is agent memory—and what isn't it? 2. What are the three layers of a memory system? 3. What are the eight types of agent memory ontology? 4. What does epistemic memory add? 5. How does memory move from remembering to understanding? 6. Why can memory maintained in documents drift? 7. What happens to your memory when you switch tools? 8. How should you compare memory systems? 9. What is each provider useful for?
Agent memory is any system that lets an agent retain and use information beyond what is immediately available in its context window.
A saved instruction can be memory. So can a conversation archive, a customer profile, a record of failed attempts, or a graph connecting an architectural decision to its requirements.
The context window holds the information available for the current model call. It can include your latest message, tool results, instructions, and retrieved memories.
A larger context window holds more information. It does not establish which statements remain valid or distinguish observations from assumptions. Importantly, a large context window doesn't mean the model will use all the information in context. "Context rot" is a well-documented phenomenon for LLMs; depending on the model, but often past 100k tokens, agents start to lose track of key information.
More recently, agents can edit their own context, which can improve performance but also increase the risk of drift.
Persistent memory lives beyond that call. It determines what can be brought back when the conversation grows, a session ends, or another agent takes over. As such, a good memory system works synergistically with context.
Retrieval-augmented generation brings external information into a model's context or for human consumption. It is often part of a memory system.
But retrieving passages from a product manual and distilling key learnings from a sequence of customer interviews are different jobs. The first asks what the documents say. The second asks how your understanding should change based on multiple data points.
RAG can retrieve the evidence in the desired format. Your architecture still needs a way to manage what that evidence means over time.
A vector database stores and retrieves information by similarity. It is a storage and search enablement component.
It does not automatically decide whether a claim has been superseded, whether two statements conflict, or whether a changed assumption weakens a recommendation. You can build those behaviours around it, but they are additional design decisions.
Chat history preserves what was said. That is valuable for replay and auditing.
It also preserves mistaken guesses, abandoned proposals, and temporary instructions. If everything enters the archive with the same status, your agent context will quickly fill up and the agent has to reconstruct the meaning each time it reads it.
Saving the conversation is the first step in memory management.
A useful starting point is to separate three layers:
Ingestion — a pipeline that loads the data, and sometimes transforms or mines it.
Storage — local or cloud, short- or long-term.
Retrieval & use — how the right information is found and brought back into the agent's work.
At ingestion, decide what deserves to become memory. A user confirming a requirement is different from an agent proposing one. A tool reporting a failed deployment is different from the agent predicting that deployment will fail. More advanced memory systems also connect memories at ingestions, helping to maintain logical coherence.
Keep the source and status of those statements. Otherwise, an early guess can return later as an established fact.
At storage, choose the structure your workload needs. Files are easy to inspect. Relational databases support explicit fields and queries. Vector indexes support similarity search. Graphs represent relationships. Many systems combine them.
At retrieval and use, decide what the agent needs for the task: an exact identifier, a relevant passage, the latest valid fact, the history of a decision, or the assumptions and logic behind it.
Two questions cut across all three layers: How does knowledge change? And what relationships must survive those changes?
Those questions matter whether your backend is a folder of files or a graph database.
See Types of agent memory for the longer breakdown.
Semantic, episodic, procedural and working memory come from the cognitive-science vocabulary commonly used in agent research. We extend that vocabulary with practical categories for sessions, coordination, identity and reasoning.
These eight categories are an ontology framework. They do not imply that you need eight databases.
The information your agent needs for the task in progress: the goal, relevant constraints, recent tool results and unresolved questions.
For a coding agent, that might include the failing test, the files being changed, and the acceptance criteria. Good working memory keeps the agent focused as it acts. The LLM's context window primarily provides working memory, and some systems use hooks and decision-model automations to remind the agent of priorities.
The record of a session: messages, tool calls, outputs, and their order.
Replay lets you inspect how the agent reached a result. It is especially useful when the final answer looks reasonable, but the actions behind it were wrong. Most consumer agents handle this natively, while work systems tend to use external tools that are often bundled with other memory functionalities.
The information agents need to work together: ownership, handoffs, dependencies, and completed work.
If one agent changes an API while another writes its client, both need to know which contract is current. Shared storage helps only if each agent can distinguish a proposal from an accepted change. Here we encounter artifacts like kanban boards and task management systems.
Who the agent is helping, what role it serves, and which preferences or responsibilities apply.
Your preferred writing style belongs here. So does the distinction between an agent advising a founder and an agent handling customer support. Identity provides continuity without making you repeat the same setup. This is often implemented via an AGENTS.md file that provides role guidance as well as high-level procedural guidelines.
The skills and methods your agent can reuse: how to deploy the service, run a customer interview, or investigate a recurring incident. For agents, this is mostly addressed by Skills and MCP tools that are exposed to the agent at the start of a session and retained via context.
Facts and concepts: your product's pricing, a customer's requirements, the relationship between a service and its database.
Semantic memory answers questions such as "Which database do we use?" Its harder task is keeping that answer current without discarding useful history.
Events and experiences: a launch, a meeting, a failed experiment, a decision made during an incident.
Episodic memory puts knowledge in time. "The customer asked for SSO" becomes more useful when you know whether that happened before or after they changed their deployment requirements.
Most systems of record (GitHub, task management systems, ERPs, CRMs, etc.) include some version of this but are rarely optimized for contextual search so the narrative around individual events can be understood. As such, companies can implement projections from the traditional systems of record into a memory system that acts as a company brain for all the facts, events, etc.
Connects the dots: the evidence, assumptions, arguments, alternatives, tradeoffs, and causal relationships behind facts, decisions, and other events. For example, semantic memory might store "we should target developers," while epistemic memory stores the evidence and reasoning that led to that belief, and what new evidence would cause it to change.
This matters when your agent makes decisions across sessions, and it is the weakest ability across the systems benchmarked. BEAM, presented at ICLR 2026, evaluated ten memory abilities and found that "all methods—including ours—perform strongest in abstention and weakest in contradiction resolution."
Imagine your team chooses a managed database.
The decision rests on three considerations: your infrastructure team is small, you expect modest traffic, and the managed service meets your current data-location requirements.
Semantic memory stores the choice. Episodic memory stores when you made it. Procedural memory stores how to deploy it. Epistemic memory preserves the reasons, the alternatives you rejected and the conditions under which you would reconsider.
Now a prospective customer requires deployment in a region the service does not support.
Your original choice was reasonable. The new evidence does not erase that history. It changes the conditions that made the choice suitable.
The agent should recognize the affected assumption and review the dependent recommendation. It should also preserve the other reasons: the small team and modest traffic still matter.
This is why "always use the newest statement" is an insufficient general rule. A recent message might report a requirement, speculate about one, or misunderstand it. Newness tells you when something appeared. It does not establish how much weight it deserves.
Epistemic memory helps distinguish those cases. It connects a belief to its basis, so your agent can explain both its recommendation and what would change it.
An explanation generated after the decision is weaker evidence. It may sound convincing without reflecting the reasons that actually produced the choice.
Retrieval asks: What information might be relevant?
A maintained model of your work also asks: What does this new information change?
That model connects observations, beliefs, decisions and requirements. In product work, a common chain is:
Customer → problem → use case → feature → workflow → requirement.
If your understanding of the customer's problem changes, the feature priority may need review. If a feature is deprioritized, requirements created solely for it may no longer justify implementation.
Finding the interview transcript is useful, but it consumes significant context filtering the noise. Getting the distilled facts that there was a previous decision (semantic memory) is efficient if the facts are correct. To make the information actionable and let the agent efficiently redesign the system without regressions, it's critical to remember dependencies and causality (the epistemics).
Computational Memory is the emerging category:
An emerging category of long-term memory that goes beyond retrieving stored facts and events. These systems process relationships between evidence, beliefs, decisions, outcomes, and sometimes causal claims, allowing new information to update more than a single stored fact. Instead of asking only "what should I retrieve?", it also addresses "what does this new information change?". Computational Memory systems actively process information to learn by creating a logical world model of an organization, technical system, or project, enabling better reasoning and higher agent autonomy.
This still depends on the quality of the data provided to the memory system and the relationships recorded. A graph does not make a mistaken premise true. Propagation makes dependencies computable; it does not guarantee a correct decision if the premises are flawed, but it does provide a substrate for learning across cycles so the memory becomes increasingly rich and accurate.
Markdown is a common starting point in agentic systems. You can inspect it, edit it and keep it in version control. Agents can search files by keywords, embeddings or other indexes.
The difficulty appears when your documents become a continuously changing representation of what you believe.
Suppose your agent maintains architecture.md, customers.md and roadmap.md. Each is readable. But the reason for a roadmap item lives in a customer note, while its implementation constraint lives in the architecture document.
After a new interview, the agent edits customers.md. The other documents still present the earlier conclusion as current.
Alternatively, the agent rewrites all three. That can work, but it must find every affected dependency and preserve the reasoning through each edit without accidentally changing something else.
Compression adds another risk. "We selected the managed database because of team capacity, expected traffic and regional availability" becomes "We prefer managed infrastructure." A conditional decision has turned into a general preference.
Version control preserves the edits. It does not automatically tell the next agent which assumptions were lost or which conclusions should be reviewed.
Documents can store excellent reasoning. The architectural question is whether that reasoning remains visible and connected as agents update them.
If your memory grows through repeated summaries, test what survives and consider more robust architectures than LLM wikis or purely agent-maintained memory systems.
You might use one coding agent for backend work, another for the frontend, and a personal assistant for planning. Each interaction adds useful context.
Switching tools should not require rebuilding your understanding of the project.
Instruction files such as AGENTS.md make some project setup easier to share. But an instruction file and the accumulated history behind your decisions serve different purposes.
Memory migration is improving. It is also uneven.
Claude documents memory import and export through a text-based workflow. Its import process extracts remembered information from pasted text and is described as experimental. Gemini offers memory import and chat-history import, subject to account and regional restrictions. OpenAI's account-transfer documentation distinguishes uploaded conversation history from transferring saved memories and settings. Sources: Claude, Gemini, ChatGPT; checked October 11, 2026.
Those workflows help. They are not equivalent to sharing a continuously maintained memory across tools.
A summary might preserve "we chose the managed database." It might omit the regional assumption, the rejected alternative, or the source that established the requirement.
The next agent inherits your conclusion without enough information to judge whether it still applies.
Keeping memory outside an individual harness can reduce this fragmentation. Compatible agents can use the same memory rather than rebuilding separate copies. This is one reason companies are moving to dedicated memory systems they own — the npm package mem0ai grew from 515,005 to 3,914,344 downloads across the last twelve months, a 7.6× increase, though @getzep/zep-cloud grew only 1.4× over the same period. The goal is continuity of reasoning and multi-harness compatibility. Moving a list of facts is only part of it.
Start with the failure you need to prevent.
For a support assistant, accurate customer facts may matter most. For an incident agent, event order and source evidence matter. For a coding agent making architectural changes, you also need the reasons behind constraints (epistemics). And for a company brain, you need all agent memory ontologies (semantics, episodic, epistemic, procedural, identity, coordination, session replay, and working memory).
Use the same workload to compare candidates:
| Dimension | What to test | What a useful result shows |
|---|---|---|
| Recall | Ask for a fact from an earlier session. | The correct information returns with its source. |
| Time | Ask what was true before and after a change. | Current and historical answers are distinguished. |
| Contradiction | Introduce conflicting statements with different evidence. | The conflict is resolved or exposed without treating recency as proof. |
| Abstention | Ask about something the agent was never told. | It reports the missing information. |
| Portability | Export and restore memory in another client. | Content, relationships and usable access controls survive. |
| Efficiency | Measure ingestion, retrieval and revision under realistic load. | Latency, cost and failure behavior fit your workload. |
| Belief Propagation | Change a premise supporting a decision. | Affected conclusions are identified and reassessed. |
| Complex Reasoning | Measure the ability to converge on a decision with many co-dependent variables. | Reliable reasoning: not failing to account for variables, nor being swayed by the last message. |
An agent memory benchmark is useful when you understand what it measures. LongMemEval evaluates primarily Recall, Contradiction, Time, and Abstention.
A headline score does not reveal differences in models, retrieval budgets or judging methods. Nor does success on historical question answering establish that an agent will safely revise a deployment plan (belief propagation, complex reasoning).
Ask for the evaluation setup and inspect failures. Then run a small test drawn from your own work.
Cost also extends beyond search. Account for extracting memories, resolving entities, revising knowledge, storing history, and assembling context. A cheap query can sit on top of expensive ingestion, but expensive ingestion can reduce overall costs that otherwise hide in agents re-deriving knowledge by processing facts without causal connections (without epistemics). Cost analysis requires production data of the whole system to produce outcomes.
Several approaches are worth considering. The table below describes documented capabilities and practical starting points, rather than an overall ranking. Product surfaces and versions differ; verify the specific edition you plan to use.
| Provider | Documented approach | How change is handled | A useful starting point for |
|---|---|---|---|
| Tortoise | Claims, evidence and computable logical relationships. | Confidence propagates through logical connections when evidence changes. | Maintaining reasons and dependencies for decisions across cycles and increasing agent reasoning and autonomy. |
| Mem0 | Extracted memories with search and memory operations. | Documentation describes reconciliation and explicit update/delete operations, and summarisation; behaviour depends on version. | Adding persistent facts based on markdown. |
| Zep / Graphiti | Temporal facts and relationships with source episodes. | Can invalidate older facts while retaining their temporal history. | Questions about relationships and what was true at a particular time. |
| Letta | Persistent agent state, editable memory blocks and retrievable messages. | Agents or developers can edit memory; blocks can also be shared or read-only. | Building stateful agents with explicit control over their context. |
| Supermemory | Extracted facts, profiles and update, extension and derivation relationships. | Documents supersession, enrichment, inferred memories and forgetting. | Maintaining evolving profiles and searchable memory across inputs. |
| Cognee | Document ingestion, graph construction and multiple search modes. | Provides processing and data-management operations; evaluate your required revision behavior. | Turning document collections into graph-backed context. |
Provider documentation checked October 11, 2026.
If you only want fact retrieval without logic, mem0 is a good candidate. For fact retrieval with fact updates but no belief propagation nor complex reasoning improvements, Supermemory and Zep are good candidates.
To understand what happens to a dependent conclusion when its supporting premise changes, show logical dependency, inspect the reasons behind a decision, or generally increase agent autonomy, Tortoise focuses on that.
Run this sequence through the same write and retrieval paths your application uses. Start with a fresh memory namespace, and use a new session for each step.
Session A: establish a decision.
We chose Service A for our database. Our team is small, expected traffic is modest, and Service A supports the deployment region our current customers require. Service B supports more regions but takes more work to operate. Remember the decision, its reasons, and the alternative.
Session B: change one assumption.
A new customer has confirmed a mandatory deployment region that Service A does not support. Service B supports it. Team size and traffic expectations are unchanged. Remember this new requirement and consider what it affects.
Session C: test revision and restraint.
Should we keep Service A for this customer? Explain the original decision, which assumption changed, which reasons still hold, and what needs review. Has the team approved a migration? Cite the stored evidence for your answer.
A useful answer identifies the regional conflict, retains the operating tradeoff and distinguishes a recommendation from an approved migration. You never told the agent that migration was approved.
Now repeat the test with Session B framed as an unconfirmed rumour. The answer should distinguish tentative evidence from a confirmed requirement.
Finally, inspect the memory itself. A fluent answer can conceal missing records. Check whether the original decision, changed premise and source references remain available.
This small test exposes several independent failures: poor recall, stale knowledge, lost reasoning, overreaction to weak evidence and invented approval.
Choose the next step from the failure you observed:
Memory is an architectural concern when your agent's next action depends on what it learned earlier. Design for that dependency before repeated conversations turn provisional assumptions into permanent instructions.
The useful question is what your agent will carry forward: the conclusion alone, or enough of its basis to reconsider it intelligently.
LLM memory usually means mechanisms that preserve and reuse information across model calls or sessions. Application memory is distinct from the knowledge encoded in a model's trained weights. It can include conversation records, facts, procedures and decision reasoning.
Short-term memory supports the immediate task. Long-term memory persists beyond it. The distinction concerns lifetime; either can hold facts, events or reasoning.
No. Files, relational databases, key-value stores and vector indexes can all support memory. Graphs become useful when relationships matter to retrieval or revision. A graph backend still needs a policy for interpreting and updating those relationships.
Yes. They are accessible and easy to inspect. Test how your workflow preserves evidence, qualifications and dependencies as agents rewrite or summarise them. File format alone does not determine memory quality.
A reasoning trace records a sequence of thoughts or actions. Epistemic memory preserves the evidence, assumptions and relationships that justify a belief or decision. A stored trace can contribute to it, but needs interpretation before its statements can be treated as reliable knowledge.
No. Confidence represents an assessment based on the available evidence and update rules. Its value depends on source quality, relationships and calibration. It should help expose uncertainty, not hide it behind a precise number.
Yes, provided the architecture supports shared access. Define which agents can read and write, how proposals become accepted knowledge, and how conflicting writes are handled. A shared database alone does not settle those questions.
Preserve sources and timestamps, distinguish proposals from confirmed facts, define a revision policy, and test changed assumptions. For consequential actions, also validate the current requirements and permissions at the point of action.