Agent memory refers to the mechanisms that let an agent retain and retrieve information beyond the context immediately available to the model, using resources such as notes, files, databases or vector stores. Depending on the design, this information may persist across steps, tasks or sessions and influence later behavior.
A language model keeps nothing between calls. Everything it knows about the current task arrives in its context window, and when the call ends, that context is gone. Memory is how an agent gets continuity anyway: it writes something down, and later retrieves it. That is what lets an agent pick up a long task, remember a user’s preferences, or avoid repeating a mistake. It is also what lets something written today shape what the agent does next week, which makes memory a governance question as much as an engineering one.
Kinds of memory
The research literature usually follows the CoALA framework, which describes a short-term working memory and several long-term memories: episodic memory of earlier experience, semantic memory of facts about the world and the agent, and procedural memory, held partly in the model’s weights and partly in the agent’s code. In practice, agent products implement these with ordinary storage:
- Conversation history and scratchpads, carried within a session.
- Notes and files the agent writes for itself, such as task logs or project notes.
- Databases and vector stores, searched by keyword or by similarity and brought back into context when relevant.
- Instruction files that an agent reads at the start of each session, and in some setups can also edit.
The kinds differ in how long they last and how they are retrieved. Retrieving only what a step needs is also cheaper than carrying everything forward in the context window, which every request pays for again (see context cost). What they share is the property that matters for governance: information written once can influence many later decisions.
Memory, context and instructions
Three things are easy to blur, and keeping them apart is most of the work.
| What it is | How it should be handled | |
|---|---|---|
| Context window | What the model can see on this call | Can be trimmed, summarized or compacted as the task runs |
| Memory | What the agent stored outside the window and may bring back | Written deliberately, with a record of where each entry came from |
| Instructions and limits | What the agent is asked and allowed to do | Supplied by the operator, not remembered by the agent |
The last row is the one most designs get wrong. When an agent’s objective and limits live only in its conversation history, they share the fate of that history: they can be summarized away, or overwritten by something the agent later wrote to memory. In an experiment we ran on context compaction, an agent whose mission arrived only as its first message lost the wording of its limits in every summary we recorded. A design that rebuilt the mission on every request kept it. We describe the experiment in The Price of Remembering.
Writing to memory is a governed action
Most discussions of agent memory are about retrieval: how to find the right memory at the right time. The governance question is about the write path:
- Who can write. The agent, the user, a tool returning results, another agent. Each source deserves a different level of trust.
- What is recorded with each entry. Where it came from, when, and under which task. Without provenance, a memory written from an untrusted web page looks exactly like one written from a user’s instruction.
- How entries are reviewed and retired. Memories go stale and contradict each other. A preference that was true last month may be wrong now, and “most recent wins” is not a policy.
- What may never be written. Credentials, personal data outside its permitted use, or instructions that would change the agent’s own limits.
Memory poisoning
Because memory persists, an attack on memory persists too. OWASP’s Top 10 for Agentic Applications lists Memory and Context Poisoning among the main agent-specific risks. A 2026 study of memory poisoning attacks found that a single adversarial memory write can exert long-term influence over agent behavior, that agents designed to write and retrieve memory more aggressively were more exploitable, and that existing prompt injection defenses did not cover memory poisoning.
The mechanism is prompt injection with a delay. An instruction hidden in a document the agent reads today is stored as a “fact” and retrieved weeks later, in a different task, where nothing about the original source is visible any more. Provenance on every write is what lets that chain be traced.
An example
The following is illustrative.
A support agent stores useful facts about customers between sessions. While handling a ticket, it reads a message that says the customer’s refunds should always go to a new account, and it saves that as a customer preference. Two weeks later, in an unrelated session, a different support request triggers a refund, and the agent retrieves the stored “preference” and sends the money there.
Every step was the agent doing what it was built to do. The failure was on the write path: a claim from an untrusted ticket became a trusted memory, with nothing recorded about where it came from.
How Sentience Governor relates
Sentience Governor keeps an agent’s declared intent and scope in its execution record, captured at the execution boundary and held outside the agent’s context and memory, so they cannot be compacted away or overwritten by what the agent stores. It recognizes writes to known memory locations, and one of its default rules expects such writes to carry a data classification and a retention policy, recording a finding when they do not. In the open-source release its view of memory is limited to a single session; it does not correlate memory across sessions.
Often confused with
Context window. The window is what the model sees on one call. Memory is what is stored outside it and can be brought back. Compaction moves material out of the window; memory decides what can return.
Knowledge base or retrieval system. A shared knowledge base is maintained by people for many users. Agent memory is written by or for a particular agent, often from its own experience, which is why its write path needs governing.
Where the concept stops
Agent memory makes information available to later decisions. It does not make that information true, current or trustworthy, and it does not record by itself where the information came from. Those properties depend on how the write path is designed, which is where memory stops being storage and becomes something an organization has to govern.