The Bottleneck Is Shifting
Early LLM applications had limited memory. State was stored in variables, logs or session history and it did not carry cleanly from one task to the next.
Agentic AI is changing this. Today agents use tools, pull information when needed to understand what has already happened in an ongoing task. This can play a huge role in what they do next. Today a system's response is more than just an answer to a user’s question. It works with details of past actions, choices and context.
This changes the nature of the engineering problem. Reliability is no longer only about the model. It also depends on how memory is handled across the system: which information gets reused, when it needs to be checked, and when it should expire or be removed. For teams building persistent agents, memory governance has to be part of the core architecture, not an optional feature.
- *Figure 1. Memory governance control plane for agentic AI systems. Persistent agents should not read from or write to memory directly. A governance control plane mediates memory selection, retrieval authorization, compression, expiration, isolation, provenance, auditability, and evaluation. Source: Author's synthesis.
From Prompt Engineering to Context Engineering
Prompt engineering used to be the primary control mechanism for applied AI. That discipline still matters, but it is no longer enough. In agentic systems, execution quality depends less on the prompt itself and more on the quality, structure, and lifecycle of the contextual information surrounding the model. Anthropic has described this shift as context engineering: curating and maintaining the right set of information so that an agent can operate reliably.
Relevant, well-organized context reduces how much burden the prompt has to carry. If the context is noisy or stale, even careful prompt engineering will not rescue the output.
Bigger Context Windows Do Not Solve Memory
One of the more persistent misconceptions in enterprise AI is that larger context windows will eliminate memory problems. They do not. A larger context window lets the model see more information at one time, but the system still has to decide which information to mark as relevant, stale or trusted. Research on long-context models shows that performance can show significant variances depending on where the essential information appears in the input.
Context should be treated as a limited budget, not a place to dump everything we have access to. When too much content is added we face an issue described as context rot: lower retrieval precision, outdated material reappears, and irrelevant details or reasoning mistakes can influence the answer we get. The goal is to give the agent enough context to complete the task without loading so much that the wrong context starts shaping the response.
Memory Is Not Storage
In traditional software, memory refers to data stored in defined paths that a system can read from and write to. In agentic AI, memory is a broader term that can include the current prompt, tool history, runtime state, retrieved documents, summaries and user preferences. Systems that try to treat all of this as simple storage have inconsistent performance.
A better approach is think about agent memory as a set of layers. Each layer has a different purpose which needs different rules. While some of these layers are visible to the model during inference, others are held by the agent runtime and never sent to the model. Some other layers live in external systems such as vector databases, document repositories, or APIs. In production, agents rely on this full stack to decide what to remember, retrieve, ignore, and act on.
|
|
|
|---|---|
| Active context | What the model sees in its current inference window |
| Runtime state | What the agent framework tracks during task execution (often not model-visible) |
| Tool history | Tool calls, outputs, errors, and intermediate results |
| Short-term memory | Session-level or task-level continuity across steps |
| Long-term memory | Information retained and recalled across sessions |
| Retrieval memory | External documents, vector stores, databases, and APIs |
| Reflective memory | Summaries, lessons learned, decisions, and preferences |
| Governance metadata | Provenance, sensitivity labels, freshness, owner, and confidence |
Table 1. Memory layers used in agentic AI systems. Source: Author.
These layers do not behave the same way. Some are short-lived, some persist across sessions, and some live outside the agent runtime entirely. They also fail in different ways and need different controls. Treating them as one generic memory layer, or ignoring some of them, is a common mistake in early agent deployments.
The Operating System Analogy
Traditional operating systems decide what stays in RAM, what moves to disk, what gets deleted, and which process can access which resource. Today agentic platforms face a similar problem, but with context. They have to decide what the model sees now, what it can fetch later, what gets compressed, and what access gets denied.
For example, MemGPT applies these ideas from operating system memory management to LLM context management which includes information transfer between fast and slow memory levels.
The practical lessons a practitioner could focus on are to keep hot and cold states separate, not mix workflows, remove outdated information, and enforce access limits. The mapping below shows where the comparison helps.
|
|
|
|---|---|
| RAM | Active context window |
| Disk | Long-term memory or external knowledge store |
| Cache | Recently retrieved high-value context |
| Scheduler | Agent orchestrator |
| Virtual memory | Context paging and retrieval |
| Garbage collection | Memory pruning and expiration |
| Process isolation | Agent boundary enforcement |
| Access control | Permission-aware retrieval |
Table 2. Operating system concepts and their closest matches in Agent Memory Management. Source: Author.
We do not need to start agent memory design with a blank page. Operating systems have been dealing with allocation, isolation, caching, removal, and lifecycle management for decades. Agent architects are now facing similar issues but related to context, memory and retrieval instead of files and processes.
Adaptive Context Management
Early RAG systems usually retrieved a fixed set of documents before generating answers. While that worked for simpler question-and-answer flows, it fails quickly when an agent runs longer workflows and the available information keeps changing.
Agent systems need context at the moment it is useful, not all at once, all the time. Instead of loading every possible document into the context, agents can fetch information as needed during execution using metadata, semantic search, file references and tool calls. This reduces token waste, improves reasoning and lowers the chance that old or irrelevant information will shape the answer.
For example, a policy document should only be fetched when the agent needs it for a tool call or decision. It should not remain in every step of the agent’s reasoning loop. While good context management is partly about retrieval, it is also about knowing when to drop information when it no longer helps the task.
Compression, Forgetting and Decay
Long-running agents eventually run out of useful context, however large the context window may be. At that point, the system has to compress, summarize or remove information. This is not just a performance issue. It impacts reliability.
The design problem is simple: What must be kept, summarized and equally importantly forgotten?
In this scenario, compression helps but far too often removes important details. For example, an agent handling a customer renewal might summarize the contract discussion and keep the renewal amount but drop a cancellation clause the customer invokes later. The agent then continues to process the renewal because the related constraint is gone from memory - not because it was evaluated and dismissed, but because it was summarized away.
Forgetting when done intentionally is not a flaw in the system. When used right, it is an important design tool that boosts performance and reliability. Systems that never forget build up a collection of outdated assumptions, and conflicting instructions and facts. Anthropic’s engineering guidance describes production agents that summarize message history, preserve open objectives and design decisions, while removing unnecessary tool outputs—like the older software patterns of classical cache eviction, log compaction, and garbage collection.
The hard part is learning how to forget safely. Teams need expiration rules, tests for compressed summaries and checks that important constraints still survive after several memory shortening events.
The tradeoffs are real. Too much memory adds noise and leakage risk. Too little memory breaks continuity in our interactions. Aggressive compression can erase important constraints, while loose retrieval design can expose information the agent should never see. Memory governance is how teams manage these tradeoffs directly instead of leaving them to user prompts or vector search settings.
Memory Persistence Creates Enterprise Risk
Persistent memory is important because it helps agents to "have a history" throughout a workflow. It also poses risks for teams to contend with. A long-running agent can continue to use old policy guidance or hold onto the sensitive information indefinitely. It can also extract irrelevant content into a task or get conflicting facts.
Security team members will know this by sight. These are all risks shared by OWASP's Top 10 for LLM Applications, particularly sensitive information disclosure, data and model poisoning and excessive agency. Supply-chain risk can also enter the picture when memory is populated from external tools, documents, or retrieval pipelines..
|
|
|
|
|---|---|---|
| Stale assumptions | Agent remembers an outdated policy | Freshness checks, TTL on memories, expiration policy |
| Poisoned memory | Bad retrieved content changes behavior | Provenance tags, trust scoring, ingestion-path validation |
| Sensitive state retention | Agent stores confidential information | Classification, retention policy, tenant-scoped storage |
| Contradictory memory | Agent stores conflicting facts | Versioning, conflict resolution, stale-memory evaluation |
| Cross-user leakage | One user’s memory affects another | Tenant isolation, scoped vector indexes |
| Privilege leakage | Agent retrieves data outside its scope | Permission-aware retrieval filters, retrieval allowlists |
| Audit gap | Agent acts on memory without traceability | Memory read/write logs, decision provenance |
Table 3. Memory risks and controls for persistent agents. Source: Author.
The examples above highlight how memory governance is more than an application design issue. It actually cuts across security, compliance, and data lifecycle management.
Thankfully, the NIST AI Risk Management Framework and its Generative AI Profile give teams a clear way to frame the work: Govern, Map, Measure, and Manage. For persistent agents – teams can now focus on the basic questions – What memory are we keeping? Where did it come from? How is it being used? How do we measure the risk? Who owns the controls?
Multi-Agent Memory Isolation
When multiple agents are part of the same task, memory boundaries become even more important. For example, just because we have 3 agents (research, planning and transaction) working on the same task, it does not mean that they have shared memory. We need to separately define permissions, trust levels, and operational roles for each of them.
Open sharing of context and memory creates problems that could have been avoided. It can forward poisoned information or low-quality material. It can expose data to the next agent that it is not supposed to see. For example, a research agent may need broad access to the knowledge base, while a transaction agent may only need approved customer records. Their memories should stay separate by default and should be shared only when policy allows it.
The safer pattern for teams to adopt is controlled handoff. Subagents should pass outputs, not their full working context. Orchestrators should get a short state summary, not every intermediate note. Shared memory should not be open by default. If one agent uses memory from another, that handoff should pass through policy checks first. The same principle applies in microservices design: keep responsibilities separate and avoid moving more state than needed.
The Memory Governance Stack
These risks suggest that there is a design issue with the agents wanting to read and write to memory without any controls in between. Below follows the mapping from those controls to the production failures that are covered by those controls.
|
|
|
|
|---|---|---|
| Context selection | Decide what enters the active context window | Attention dilution, token waste |
| Memory classification | Label sensitivity, source, freshness, and confidence | Uncontrolled sensitive data exposure |
| Retrieval governance | Control what the agent is permitted to retrieve | Privilege leakage, unauthorized access |
| Compression and summarization | Reduce memory while preserving decision-critical state | Critical constraint loss |
| Expiration and forgetting | Remove stale or unsafe memory according to policy | Stale-policy reuse, contradictory state |
| Isolation | Prevent cross-agent or cross-user memory leakage | Cross-tenant contamination |
| Provenance | Track where each piece of memory originated | Untraceable poisoned context |
| Auditability | Record memory reads, writes, and the decisions they informed | Unexplainable agent actions |
| Evaluation | Test whether memory improves or harms agent reliability | Silent reliability degradation |
Table 4. The Memory Governance Stack for Agentic AI Systems. Source: Author.
Rather than memory governance being managed within the application layer: Platform teams need to have rules to determine what to store in long-term memory. Filters and allow lists are important to security teams to limit what agents can see. In order to audit teams, there should be logs that reveal which memories were read, written and utilized in decision making.
A team doesn't have to have the complete stack set up on Day One. A good use case to begin with is adding a write policy to memory, adding provenance tags, adding TTL rules, adding permission-aware retrieval, and adding read and write audit logs. These controls provide a basic means for managing the storage, retrieval and traceability of memory when an action is impacted by memory.
Memory should be treated the same as the other discipline teams (logs, data access, model outputs) do over the years. It is not imperative that teams create these rules or that they use a tool that creates them; important is that teams have them and it is clear who owns them. The actual danger is to leave memory in an unmanaged state and have to contend with reliability or compliance problems in the future.
Closing Perspective
Although longer windows and better models are very valuable, they don't solve the fundamental problems of what should the agent remember, what should the agent forget. What should it look up again and What should it forget?
These questions demonstrate the criticality of thinking about memory governance from the outset of the design of production AI systems. It's right next to observability, security and evaluation. Memory is not only for storing context, agents become persistent. It impacts the system's operation, reliability, data it may reveal, and most importantly, the trust users can have in the system's decisions.
The best agentic systems will not attempt to store all the details. It will be up to them to remember the correct things, forget safely, and to explain why they used a memory.
References
- Anthropic Engineering. Effective Context Engineering for AI Agents(September 29, 2025)https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Liu, N. F. et al. Lost in the Middle: How Language Models Use Long Contexts(2024, arXiv:2307.03172)https://arxiv.org/abs/2307.03172
- Packer, C. et al. MemGPT: Towards LLMs as Operating Systems(2023, arXiv:2310.08560)https://arxiv.org/abs/2310.08560
- Anthropic Engineering. Effective Harnesses for Long-Running Agents(November 26, 2025)https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
- OWASP. Top 10 for Large Language Model Applications (2025 Edition)
https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/ - NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
https://doi.org/10.6028/NIST.AI.600-1