What your agent remembers, and for how long

Version 1.0 · Published 2026-09-07

Most teams running a customer-facing agent can say what it knows. Far fewer can say what it keeps. Those are different questions, and only one of them has a regulator paying attention to it.

This piece is about the second one. By the end you will have four questions to put to any agent vendor, including us, and a sense of what a real answer sounds like next to an evasive one.

What the regulator actually said

On 20 July 2026 the French data protection authority, the CNIL, published a joint note with France’s AI and Digital Council, CIANum, on what agentic AI does to personal data. Covington’s write-up, French CNIL Publishes Note on Agentic AI and Data Protection, is the clearest summary in English.

Start with the caveat, because a lot of vendor commentary will skip it. The note is exploratory. It states no definitive regulatory expectation, it announces no forthcoming guidance, and it names no vendor. Nobody is compliant with it and nobody is in breach of it. It is a regulator thinking out loud, which is exactly why it is useful.

It flags four risk areas: opaque multi-service processing chains, persistent memory, error cascades, and unclear controller and processor roles. The second one is the subject here, and the reason it leads is simple. A person cannot tell you what an agent kept about them, where that sits, what has been done to it, or when it goes away.

Why memory drifts if nobody decides otherwise

Persistent memory is rarely a feature somebody chose. It is what you get when nobody chooses.

The easy build appends every interaction to a store, gives each agent instance its own copy, and inherits retention from whatever the storage layer happens to do. Nothing in that is negligent. It is the path of least resistance, and it produces a system where nobody has ever looked at what is held about any individual person.

Then the second-order problems arrive, and the note names them. A wrong fact written into memory propagates to the next system that reads it, which is how an error becomes a cascade. Retention periods multiply until no one can monitor them. The note’s technical suggestions follow directly from that diagnosis. Partition memory by agent and by process. Put size limits and automated expiry on it. Run detection and filtering every time a model is invoked, rather than only on the first prompt. Classify actions by risk, so the higher-risk ones need a human.

Read that list again and notice what it is. Those are product decisions. Every one of them is something a vendor either did or did not do, months before any of this was written down.

The four questions

Which gives you the questions. They are deliberately boring, and boring is the point: each one has a factual answer that a vendor either has or does not.

What is retained? Not “we store conversation history”. Which fields, for which purpose, and what was deliberately not kept. A good answer is short and specific and mentions something the vendor chose to throw away. An evasive answer describes a capability instead of a decision.

Where does it live? Which store, in which region, and separated by what. A good answer names the boundary between one customer’s memory and another’s without being asked.

What can read it? This is the one most likely to surprise you. A memory that any component can read is a memory with no access control, and the answer should distinguish between what the system can read and what a person at the vendor can read.

When does it go? The strongest answer is a number and a mechanism. “Retention is 365 days, expiry is automatic, and derived copies expire with the original” beats any amount of language about commitment to privacy. A vendor who cannot answer this is telling you that nobody owns it.

The common mistake is accepting an answer about the first question as though it settled the fourth. Knowing what a system stores tells you nothing about when it stops storing it, and the second question is the one a data subject will eventually ask you.

Our answers, and they are ours

Unless answers its own four this way, stated as our design calls rather than as compliance with a note that requires nothing.

Living Memory holds what serves the customer relationship and is private per customer, which is the separation question answered at the architecture level rather than by configuration. Personal data is kept in EU regions, and our retention is no longer than 365 days, with continuous database backups on a thirty-five day cycle. Both are written down on our data subject rights page rather than being something you have to ask for.

On what can read it: raw identifiers are filtered and tokenized at the gateway before any call to a third-party generative model, so the model that phrases an answer receives placeholders rather than names. We should be precise about the limit of that claim. It is best-effort minimization of detectable identifiers, not anonymization, and the PII-detection step itself reads raw input by design, which is why it appears as a sub-processor in your DPA rather than being quietly excluded from one.

And on when it goes: the controller runs access, rectification, erasure and portability from the dashboard, with a human confirming before anything changes. Tokens are orphaned when the underlying value is deleted or changed. That is the operational point, and it is the one worth leading with: there is a mechanism you can run, and a record afterwards that it ran.

The part where a human has to be real

The note also raises delegated decisions with significant effects, which is Article 22 territory, and with it the question of whether the human supervision in the loop is genuine or decorative.

We have argued this at length in approval is not oversight, so the short version will do here. A person clicking approve on something they cannot inspect is not supervising it. What makes oversight real is that the approver can see what they are approving and could plausibly have said no. Memory is where that gets decided in practice, because an approver who cannot see what the agent remembered cannot evaluate what it concluded.

Worth reading alongside this: the lethal trifecta covers memory as one leg of an exfiltration risk. That is a different problem from this one. This piece is about opacity and retention; that one is about what an attacker can pull out.

What to do this week

Send the four questions to whoever runs your agent, including your own team if you built it. Ask for the answers in writing, because the act of writing them down is what turns an assumption into a decision.

If the answers come back describing capabilities rather than choices, you have learned the thing the CNIL was pointing at. Not that anyone broke a rule. That nobody decided.