Agentic AI Foundation Logo
Illustration of an AI agent using multiple memory sources, including conversation history, files, documents, workflow checkpoints, and shared knowledge.

Agent memory: patterns, tradeoffs, open problems

Rohit Ghumare & Steve KearnsSeptember 8, 2026

Agent memory: patterns, tradeoffs, open problems

Teams building agents use the word memory for several different capabilities. Conversation history that survives another turn, a file of repository instructions, a searchable document corpus, a checkpointed workflow, and a shared store used by several agents can all be described as memory. They solve different problems and fail in different ways.

Here, agent memory covers information or execution state that persists beyond a single model call and can be made available to the agent later.

Current systems cover many of these needs. OpenAI can persist conversation state. Claude Code and OpenClaw use files for durable context. LangGraph separates thread checkpoints from cross-thread stores. Agent Library provides retrieval over a local corpus. Mem0 and LangMem extract information that can persist across sessions. Graphiti represents relationships that change over time. Recent research is also looking more closely at shared memory, stale information, deletion, and access control.

Those capabilities do not add up to a single solved memory architecture. A production system still has to decide what should be captured, how it is stored and retrieved, what authority it should have, how it is updated or superseded, who can access it, and how it is deleted after being summarized, indexed, or shared elsewhere.

The useful way to approach agent memory is therefore to separate the main patterns, understand what each one is good for, and look at the problems that remain when they are combined.

Conversation continuity

The simplest form of memory is preserving enough of an interaction for the next turn or session.

OpenAI's Conversations API, for example, provides durable conversation objects that can be reused across sessions, devices, or jobs. Conversation items can include messages, tool calls, tool outputs, and other interaction state.

This works well when the main requirement is continuity. An application can resume an interaction without reconstructing every previous message manually, and recent tool results or task context can remain available while the work continues.

Conversation history becomes less useful as a general store of durable knowledge when information changes. A user may state one preference and reverse it later. A project may replace an earlier decision. Both versions can remain in the transcript, leaving the application or model to determine which one should guide later behavior.

Larger context windows reduce some of the pressure to summarize or retrieve older material, but they do not resolve the lifecycle problem. Context remains finite, and systems still need to decide which information deserves to persist independently of the conversation.

Conversation continuity is useful for maintaining an interaction. Long-lived facts, project knowledge, policies, and preferences usually need more structure.

Summaries and compaction

Long-running sessions can accumulate more history than is useful to send to the model on every step. Compaction reduces that history by replacing older material with a smaller representation.

Anthropic offers server-side compaction in beta for long-running conversations and tasks on supported Claude models. OpenClaw similarly summarizes older messages while retaining more recent context. Before compaction, OpenClaw can prompt the agent to save important information into memory files so it is not dependent on the summary alone.

This can reduce context use and allow a session to continue for longer, but the summary becomes a lossy boundary. A detail omitted during compaction may no longer be readily available to the model. A mistaken conclusion can also survive after the supporting material has disappeared from active context.

Compaction and durable memory therefore need different policies. Compaction determines what smaller representation should continue into the next model call. Durable memory determines which information should remain available after the current context or session has ended.

Some projects now cover both areas. Headroom is primarily a context-optimization layer that compresses material such as tool outputs, file reads, logs, and RAG results before it reaches the model. Its current feature set also includes persistent memory and SharedContext for passing compressed context between agents.

The implementation can sit in the same product, but the architectural decisions remain separate.

File-backed instructions and memory

Files provide one of the clearest ways to give an agent durable context.

AGENTS.md gives coding agents a predictable location for repository instructions such as build commands, tests, conventions, and project-specific guidance. Claude Code uses CLAUDE.md for human-authored persistent instructions and supports auto memory, where Claude writes its own notes based on patterns, corrections, and preferences it encounters. OpenClaw also uses files as part of its persistent memory architecture.

The distinction between instructions and agent-written memory matters. A convention approved by repository maintainers has a different status from something an agent inferred while working through a task. Storing both without a clear distinction can allow an observation to acquire more authority than it should have.

Files have useful operational properties. Humans can inspect and edit them directly, project files can be versioned, and memory can remain independent of a particular model provider. Anthropic's memory tool takes a related approach at the API level by allowing Claude to create, read, update, and delete files in a memory directory while the application controls the underlying storage.

The main problem is accumulation. A memory file can gradually collect current guidance, old decisions, debugging notes, duplicated facts, and speculative conclusions. The format remains transparent while the contents become harder to trust.

Separating approved instructions, durable information, and temporary working notes helps preserve the main advantage of file-backed memory: humans can see what the agent is carrying forward.

Wiki-style knowledge

A maintained knowledge base extends the file pattern beyond a small set of instructions or notes.

Basic Memory stores knowledge in plain Markdown and maintains a searchable representation over those files, allowing humans and agents to work with the same underlying material. Andrej Karpathy's LLM Wiki proposal uses a related pattern. Source documents remain separate while an LLM maintains interlinked Markdown pages that synthesize the information over time. LLM Wiki v2 extends this pattern with lessons from building agentmemory, including confidence, supersession, consolidation, hybrid retrieval, temporal relationships, automation, and governance.

This approach can fit long-running research, technical documentation, project knowledge, or recurring investigations where the useful artifact is more than a collection of previous conversations. New information can update an existing topic rather than requiring the agent to reconstruct the same synthesis from raw sources on every query.

The maintenance problem remains. Generated pages can become stale or duplicated, and a summary can drift away from the evidence behind it. Two pages may end up containing different versions of the same fact.

Provenance is therefore important. A dependable knowledge base should make it possible to identify the source behind a claim, when a page was updated, whether it represents generated synthesis or approved documentation, and what happened when later evidence changed an earlier conclusion.

The storage format alone does not provide that discipline. Someone, whether human or automated, still has to maintain the knowledge.

Retrieval memory

Many agent systems need access to a corpus that is much larger than the active context window. Retrieval provides a way to search that material when it is needed.

Agent Library is a community project built by Arcade.dev engineers rather than an official Arcade.dev product. It provides a local knowledge index, supports semantic and keyword retrieval, and can work with text, code, PDFs, and images through an MCP interface. The canonical repository now sits under the arcadeai-labs GitHub organization.

This differs from memory systems that extract new facts from conversations. Retrieval can leave the original document as the evidence and find the relevant material later.

Retrieval still has failure modes. Semantic similarity can return something related without returning the exact information required. Exact identifiers, filenames, version numbers, and error codes can benefit from keyword or hybrid retrieval. Metadata such as document version, date, repository, owner, or status can also stop an obsolete source from competing directly with current material.

This is one place where successful retrieval and reliable memory separate. A system can retrieve exactly what was stored and still act on information that should no longer be considered current.

Extracted and profile memory

Instead of repeatedly searching old conversations, an agent can extract information that appears useful enough to retain separately.

Mem0 separates memory into conversation, session, user, and organizational layers. Conversation and session memory cover shorter-lived context, while user memory is intended for longer-lived knowledge tied to a person, account, or workspace. Organizational memory can provide shared context across agents or teams.

LangMem supports a similar class of use case through memory managers that can create, update, consolidate, and delete information as conversations continue.

This pattern can work well for stable preferences, recurring project constraints, account details, important decisions, or information that would otherwise have to be rediscovered from earlier interactions.

The difficult part is deciding what deserves to become durable.

A user choosing Python for one prototype does not establish a permanent language preference. A temporary project constraint can be mistaken for a standing requirement. An extracted fact can also be wrong before it reaches storage.

A useful memory system therefore needs a capture policy as well as a retrieval policy. It needs enough information to distinguish scope, source, observation time, explicit statements from inference, and current facts from superseded ones.

Headroom provides one example of making some of that lifecycle explicit. Its memory system has user, session, agent, and turn scopes, and supports supersession chains so changed facts can retain their history instead of simply replacing the earlier value.

Those mechanisms help, but the application still has to decide which new information is allowed to alter durable memory and under what conditions.

Workflow state and checkpoints

Workflow persistence is frequently described as memory even though its purpose is different from storing durable knowledge.

An agent may need to resume after a crash, pause for approval, retry a failed step, or continue a workflow that spans several external events. The runtime has to preserve enough state to know where execution should continue.

LangGraph makes the distinction clear. Checkpointers persist graph state for a thread and support conversation continuity, human review, fault recovery, and time-travel debugging. Stores persist application-defined information across threads, including user preferences, facts, and shared knowledge.

Keeping these concerns separate prevents workflow state from becoming a general-purpose memory store. A pending approval or retry counter matters because a particular run is unfinished. A repository decision or user preference may still matter after that run has ended.

The useful distinction is whether information exists so the current execution can resume or because it should influence future work. Those two purposes usually need different retention and access rules.

Graph and temporal memory

Flat memories become harder to manage when relationships change over time.

A system may record that one person manages a team, then later learn that they moved to another role and someone else took over. Retrieving every historical statement leaves the model to work out which relationship is current.

Graphiti addresses this with temporal context graphs that represent entities and relationships while retaining temporal information and provenance. This allows applications to work with current and historical relationships rather than treating every fact as equally current.

This can be useful when the application needs to reason about relationships, sequences of events, historical state, or point-in-time questions. It adds additional machinery as well. Entities need to be resolved correctly, relationships need to be extracted, and changes need consistent temporal handling.

There are still implementation edge cases. A user-reported Graphiti issue, #1166, filed in January 2026, describes a limitation where relationships are temporally versioned but node attributes can be destructively updated, which can prevent some historical node-state queries.

That does not make temporal graphs unsuitable. It shows that representing change introduces its own design problems. Applications that mainly need current documentation may be better served by retrieval with strong metadata. Temporal graphs become easier to justify when the history of relationships is itself part of the information the agent needs.

Shared memory

The harder governance questions become more visible when several users or agents can write information that others later retrieve and act on.

Several recent preprints have begun to formalize these problems. Margalit et al. identify four foundational failure modes in Governed Shared Memory for Multi-Agent LLM Systems: unauthorized leakage, stale propagation, contradiction persistence, and provenance collapse. The authors implemented governance mechanisms in MemClaw and evaluated them against a live production multi-tenant service.

That work also provides a concrete example of the kinds of failures that can survive an apparently sensible architecture. Tenant isolation held, but the researchers found that one direct GET-by-ID path initially bypassed a narrower sub-tenant scope check for agent-scoped credentials. They also found an ordering conflict where duplicate detection could reject a contradictory write before the contradiction-handling process had an opportunity to supersede the earlier memory. Both were identified through testing the live service.

The authors are explicit about the limits of the result. MemClaw is their own service, and the study measures one production implementation rather than establishing a market-wide baseline.

The GateMem benchmark from Ren et al. examines the broader problem. It contains 91 multi-party episodes and 2,218 hidden checkpoints across medical, office, education, and household settings. The benchmark evaluates legitimate utility, access control, and active forgetting together. None of the evaluated approaches performed strongly across all three.

Rezazadeh et al. describe Collaborative Memory, with private and shared memory tiers governed by asymmetric, time-changing access controls and provenance attached to stored fragments.

The evidence here is still stronger on research and early systems work than on broadly established production practice. It does, however, give teams a clearer set of requirements. A shared memory layer needs to account for:

  • who owns a memory and which scope it belongs to;
  • who is allowed to read or change it;
  • which user, agent, source, or tool produced it;
  • how a later memory supersedes an earlier one;
  • how conflicts between authorized writers are handled;
  • where updates are allowed to propagate;
  • what deletion means after a memory has been shared or derived elsewhere;
  • whether operators can reconstruct how a memory was written, changed, retrieved, or propagated.

A shared vector store with team namespaces may provide part of this. It does not by itself provide the governance model.

What belongs in durable memory?

Persistence should be selective.

Stable preferences, durable project constraints, approved repository conventions, recurring workflows, important decisions, and verified facts that are likely to matter again are reasonable candidates. Where possible, those memories should retain enough provenance to identify the source material behind them.

Transient errors, raw tool output, speculative conclusions, stale assumptions, secrets, private keys, and untrusted content are much weaker candidates. The same applies to information the system cannot later inspect, correct, supersede, or delete.

The distinction between source material, memory, and instruction is particularly important. A retrieved web page is a source. An extracted note based on that page may become memory. Neither should automatically gain the authority of an approved instruction simply because it has persisted.

A useful test is whether retaining the information will help a future task and whether the application can still manage it when circumstances change.

Freshness and forgetting

Information that was useful when written does not remain correct indefinitely. Preferences change, repositories are refactored, policies are replaced, project decisions are reversed, and roles move between people. Later evidence can also invalidate an earlier memory without containing a direct contradiction.

Memora, from Uddin et al., evaluates this part of long-term memory rather than static recall alone. Its FAMA metric penalizes systems that rely on obsolete or invalidated memories. The study evaluated four LLMs and six memory agents and found recurring problems with reusing invalid information and reconciling memories as circumstances changed.

The STALE preprint examines a related problem called implicit conflict, where later evidence makes an earlier memory invalid without explicitly negating it. Its evaluation covered 400 expert-validated scenarios and 1,200 queries. The strongest model tested, Gemini-3.1-pro, reached 55.2 percent overall accuracy. The results also showed a gap between recognizing that information had become outdated and applying that change correctly in later behavior.

Freshness therefore involves more than ranking recent memories higher. The newest information is not always the most authoritative. A recent speculative note should not override an older approved project decision simply because its timestamp is later.

Depending on the application, durable memory may need metadata for its source, scope, writer, observation time, verification status, current or superseded state, and access policy. The exact schema can vary, but the system needs a way to establish which information should currently guide behavior.

Deletion also has to account for derived state. Removing an original conversation while leaving its contents in an extracted profile, summary, graph relationship, cache, or shared downstream memory does not fully remove the information from the system.

Memory as a security boundary

Persistent memory creates an additional route for untrusted information to influence later behavior. Several recent preprints have tested how those risks can persist across later interactions.

Dash et al. identify four memory-write channels and nine structural vulnerabilities that can make memory poisoning possible. Their experiments found that agents configured to write and retrieve memory more aggressively were also more exploitable, and that existing prompt-injection defenses did not cover the full memory-poisoning threat model.

A related threat is sleeper memory poisoning. Pulipaka et al. describe how adversarial material in an external document, webpage, or repository causes an assistant to save a fabricated memory that remains dormant and affects later conversations. The attack is persistent because the malicious content can continue to influence the agent after the original source has left the active context.

The MemPoison benchmark from Gao et al. covers persistent memory threats. It contains 1,227 hand-validated cases spanning four attack types, three injection channels, and three representative memory architectures. Its results identify weaknesses in defenses that operate only when the memory is first written, particularly when apparently benign memories become harmful through later combinations or triggers.

The practical issue is authority. Untrusted content should not become trusted simply because an agent decided to store it. Provenance, write controls, retrieval authorization, and review of sensitive durable memories all become relevant. Shared memory raises the stakes because one problematic write can be available to several later agents or users.

Evaluating memory

A recall test can show that an agent found something it was told previously. It provides much less information about whether the system behaves correctly after that information changes.

Useful memory evaluation should span sessions and alter the state between them. A user preference can change, a project decision can be reversed, a stored fact can be deleted, or one agent can be given access to information that another agent must not receive. The evaluation can then test whether the current information is used, whether access boundaries hold, and whether deleted information remains recoverable.

The newer benchmarks reflect this shift. Memora tests invalidation as part of long-term personalization. STALE evaluates implicit conflicts. GateMem evaluates usefulness, authorization, and forgetting together. All three expose failure modes that ordinary retrieval accuracy would miss.

Debugging also depends on visibility into the memory path. When stored information influences a bad result, an operator needs to know what was retrieved, where it came from, when it was written, and whether another memory had already replaced it.

File-backed memory provides some of that visibility naturally. Hosted, extracted, graph-based, and shared systems need equivalent provenance and history if teams are expected to understand failures after they occur.

Choosing a memory pattern

The practical choice starts with the type of persistence the agent needs:

  • Use conversation state when the agent needs to continue an interaction.
  • Use retrieval when it needs to find relevant material from a larger corpus.
  • Use checkpoints when a workflow needs to pause, recover, or resume.
  • Use extracted memory when selected facts or preferences should persist across sessions.
  • Use graph or temporal memory when relationships and historical state need to be queried directly.
  • Use shared memory when several users or agents need access to common knowledge, with explicit rules for scope, provenance, updates, and deletion.

A coding agent may use several of these patterns at once. It can maintain the active conversation in session state, read approved repository guidance from AGENTS.md, search code and documentation through retrieval, checkpoint a long-running task, and retain a small set of useful project information across sessions. There is little reason to force all of those requirements into a single memory mechanism.

This is where claims that agent memory is already solved become difficult to sustain. Individual parts have working implementations, some of which are already useful in production. The remaining problems appear when stored information has to stay correct over time, honor deletion, resolve conflicts, retain provenance, enforce access boundaries, and work across several agents or users.

For teams building now, the useful starting point is to decide what information genuinely needs to survive and what authority it should have. The next decisions concern updates, supersession, access, deletion, and the evidence needed to debug mistakes. The choice of file, vector index, graph, database, or framework-specific API follows from those requirements.

For readers who want to examine these tradeoffs in a working open-source system, agentmemory provides a persistent-memory implementation for AI coding agents and brings several of the patterns discussed here into one project.

Sources

Share

Authors

subscription section bg
Subscribe

Subscribe to the AAIF Briefing

Weekly signal on standards, governance, and the people building the future. No fluff. Just what matters.

About AAIF