Your product team asked for an AI feature that remembers the user. Your engineers built it. Nobody wrote down what it keeps, who can correct it, or how it gets deleted, because AI agent memory arrived on the roadmap as a feature and features do not come with retention schedules.
AI Agent Memory Is a Retention Problem Wearing a Feature Label
A language model is stateless. Each call reads a fresh context and throws away everything when it returns, which is why an assistant that was helpful on Tuesday knows nothing about you on Wednesday. Memory is the layer teams bolt on to fix that: durable state the agent carries between sessions so it can pick up where it left off.
The feature request stops there. What ships is a store of things the agent decided were worth keeping about a named person: what they asked for, what they seemed to want, what it inferred about their role, their budget, their frustration. None of that was in your database before. All of it is personal data now, and your organization is the one holding it.
This is a different question from the one most teams have already asked. Our earlier piece on the two gates before your timeline is real covers what an agent can reach at build time, under whose permissions. Retention is the other end of the same pipe: not what the agent may read, but what it may keep afterward, and for how long.
The Research Has the Same Blind Spot Your Backlog Does
A June 2026 survey of always-on agents reviewed 435 works on persistent memory, state and governance. Its central finding is not that the field is immature. It is that the field is lopsided: the literature concentrates far more heavily on accumulating and retrieving state than on governing, recovering, or relinquishing it.
That asymmetry is worth sitting with, because it is the same one in your sprint plan. The authors lay out a nine stage lifecycle for a piece of agent state: writing, validating, organizing, retrieving, acting on, updating, forgetting, auditing, and rollback. Most teams build the first five well, because those are the ones a demo shows. The last three are the ones a regulator, an auditor, or an angry customer asks about, and they are the ones nobody scoped.
The survey also proposes an evaluation protocol that scores state mutation and recovery rather than answer quality alone. That framing is the useful import for a product team. Your acceptance criteria almost certainly measure whether the agent gave a good answer. They probably do not measure whether it can be made to forget one.
Six Questions Before Your Agent Keeps Anything
The survey examines each piece of durable state along six axes. Translated out of the paper and into a build conversation, they are six questions to answer before a memory feature ships, ideally in a table your team actually maintains.
Who said this was true?
A fact the user typed, an inference the model drew, and a record pulled from your CRM are three different things with three different reliability levels. Store the difference. An agent that cannot distinguish what it was told from what it guessed will defend a guess as confidently as a fact.
Who else can see it?
Decide whether a memory is scoped to that person, that account, that workspace, or the whole tenant, and decide it per memory rather than once for the store. The expensive mistake is a preference learned in one customer conversation surfacing in another.
Can it be corrected, and by whom?
People change roles, budgets and minds. If the only way to fix a wrong memory is an engineer running a query, it will not get fixed. Support needs a path, and the user usually should too.
Where did it come from, and can you show that later?
Provenance, the record of where a stored item originated, is what turns an awkward question into a two minute answer. Without it, explaining why the agent believed something means reconstructing a conversation from months ago.
If it is wrong, can you roll it back cleanly?
Memories compound. An early wrong inference shapes later ones, so deleting the original does not always undo it. Decide early whether your store supports removing a memory and everything derived from it, because retrofitting that is a rebuild.
Can the agent act on it without asking?
There is a real difference between a memory that colors an answer and one that authorizes an action. Mark which memories are advisory and which can move money, change a record, or send something out under the name of the person it belongs to.
What the Law Already Says About This
None of this is waiting on new regulation. Under the General Data Protection Regulation, the right to erasure in Article 17 covers personal data your organization holds, and an agent memory store holding inferences about a named person is personal data your organization holds. Deleting the source record does not satisfy it if the agent still remembers what the record said.
Article 35 is the one that catches teams by surprise. It requires a data protection impact assessment where processing is likely to result in high risk, and it names a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, as one of the cases that triggers it. An agent building a durable behavioural picture of a user across sessions is a reasonable candidate for that assessment, and the assessment is supposed to happen before the processing starts, not after a complaint. Read the text at Article 35 and make the call with your counsel rather than discovering it later.
Who Owns the Decision
Not engineering alone. The six questions above are half technical and half policy, and the ones that get skipped are always the policy half, because the person who would answer them was not in the sprint planning. Get the data owner and whoever handles your privacy requests into the room once, before the store exists. It is a short meeting that is very hard to hold retroactively.
Key Takeaways
- AI agent memory is durable personal data your organization retains, not a UX nicety, and it arrives without the retention schedule a database would have had.
- A 435 work survey found research concentrates on accumulating and retrieving agent state far more than on governing, recovering, or relinquishing it. Your backlog probably has the same shape.
- Of the nine stage lifecycle for agent state, the last three (forgetting, auditing, rollback) are the ones regulators and customers ask about and the ones teams rarely scope.
- Answer six questions per memory before shipping: who asserted it, who can see it, who can correct it, where it came from, whether it can be rolled back, and whether it can authorize action.
- GDPR Article 17 erasure reaches agent memory, not only source records, and Article 35 may require an impact assessment before the profiling starts.
Frequently Asked Questions
Can we just not store memories?
You can, and for some products that is the right answer. A stateless assistant is cheaper, simpler and carries almost no retention exposure. The tradeoff is that every session starts cold, which users experience as the product not knowing them. The honest version of this decision is to scope memory to the smallest set that delivers the value, rather than storing everything the agent observes because storage is cheap.
How is this different from the data we already hold about customers?
Two ways. The data is derived rather than supplied, so nobody explicitly gave it to you and your existing consent language may not cover it. And it is written by a system that decides on its own what is worth keeping, so the contents are not enumerable in advance the way a form is. Both make the governing and deleting harder than for a normal table, which is exactly why they need to be designed rather than assumed.
Does using a vendor memory product solve this?
It solves the storage and retrieval engineering, which is the part that was never the hard part. Scope, correction rights, provenance, rollback and the impact assessment remain yours, because your organization is the controller of the data regardless of whose infrastructure it sits on. Evaluate a memory vendor on what it lets you delete and prove, not on how well it recalls.
Sources
- Ding, Nannapaneni, Liu and Zhang, "Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents," arXiv, 2026. Link.
- General Data Protection Regulation, Article 17, Right to erasure. Link.
- General Data Protection Regulation, Article 35, Data protection impact assessment. Link.
Next Steps
If your roadmap has an AI feature that remembers users and no document says what it keeps or how it forgets, the retention decision is being made by default in code. Stable Solutions scopes agent memory as a governed store from the start, with provenance, correction paths and deletion that actually reaches derived state. Explore our App and Web Development services or contact our team to review a memory feature before it ships.