Agent memory is a new system of record, and it arrived as a feature flag

The change arrives as a line in a release note. Persistent memory is available on the assistant, it is off by default, and turning it on makes the thing noticeably more useful, because it stops asking for the same context every morning. Somebody with the right role in an administration console enables it for a pilot group. The pilot goes well, and a few weeks later it is on for everyone.

Nothing in that sequence resembles the creation of a data store. There was no schema review, no assessment, no entry added to a retention schedule and no named owner. The store exists anyway. It is written to on every conversation, and within a few months it holds an account of what people asked about, what they were working on, what they were worried about and what they were told.

The claim: persistent agent memory creates a system of record whose entries are written by the model rather than by an application, and it inherits the obligations of the material it summarises without inheriting any of that material’s controls.

A context window is a cache. Memory is a store.

The two are routinely discussed as the same capability, and the conflation is where the governance question disappears. A survey posted in August 2026, The Horizon Gap, separates them explicitly as part of its taxonomy: long-context models, which hold more of a conversation in a single pass, and persistent memory systems, which retain information across sessions. The first is a capacity that is discarded when the request ends. The second is retained data, kept deliberately, because keeping it is the point of the feature.

Retained data is the category that carries obligations. Under the General Data Protection Regulation, Article 5(1)(e) requires that personal data be kept in a form permitting identification for no longer than is necessary, Article 15 gives a person the right to know what is held about them, Article 16 the right to have it rectified, and Article 17 the right to have it erased. None of those articles contains an exception for data an organisation did not realise it was storing.

Where the controls go missing

Four properties of a memory write, each of which removes something a normal record has.

The write has no schema. An application write goes into a declared field, with a type and usually a classification. A memory write is a sentence the model decided was worth keeping. Nothing in the path declares whether that sentence contains a name, a health detail, a salary, or a fact about somebody who is not the user and never consented to be discussed.

The write is a paraphrase, so the lineage breaks at the moment of writing. If the material came from a document or a record in another system, the memory entry is not a copy of it and does not point at it. There is no foreign key, so there is no cascade to configure. Deleting the source record leaves the memory of it untouched, and nothing in either system knows the two were ever related.

Reading it back is retrieval without the permissions. This is the failure that enterprise search already has, with one difference that makes it harder. An index built from a document store drops access control lists that existed upstream and can, with effort, be reconstructed from the source system. A memory entry never had an access control list to lose. It was created inside a conversation, and the only thing scoping it is whatever partition key the platform happened to use.

Nothing evicts it. Retention requires a rule and a clock. Memory systems are usually built with relevance scoring instead, which decides what is surfaced, not what is kept. An entry that stops being relevant stops being read. It does not stop existing.

1. 01 Write The model decides what is worth keeping. No schema, no classification.
2. 02 Store Where provenance, versioning and a retention rule would have to be attached.
3. 03 Retrieve The entry re-enters context, carrying whatever scope it was given at write time.
4. 04 Execute The agent acts on it as though it were established fact.
5. 05 Share and propagate The entry reaches another user, another agent or another tenant.
6. 06 Forget and roll back Erasure and correction, which are only possible if the earlier phases recorded enough.

Those six phases are the framing used by a survey of long-term memory security in agent systems published in April 2026 and revised in June. Its conclusion is the part worth carrying away, and it is an architectural finding rather than a security one:

Robust Long-Term Memory security cannot be retrofitted at retrieval or execution time alone, but must be anchored in storage-time provenance, versioning, and policy-aware retention from the outset.

That sentence is the reason this is an architecture question and not a policy one. A filter placed in front of retrieval can suppress an entry. It cannot tell you where the entry came from, whether it was derived from a record that has since been corrected, or whether it should have been written at all.

What to decide before the toggle moves

There is a fifth property that belongs with the four above and sits awkwardly in a checklist, which is that a memory entry can simply be wrong. It is a model’s summary of a conversation, which means it can be a confident misreading, and once written it is read back as established fact on every subsequent turn. A correction right has a technical meaning here that it does not have for a database row. Somebody has to be able to find the entry, show it to the person it describes, and replace it.

All of these are decisions taken at the write and store phases. Each is close to free while the store is empty and expensive once it is not, because the cost of retrofitting provenance onto a year of unlabelled sentences is the cost of reconstructing where each of them came from, which is generally not possible at all.

What this does not tell you

This is not legal advice and it is not an assessment of your estate. Whether a particular memory store holds personal data, which lawful basis applies, and how storage limitation applies to a derived paraphrase rather than to a copy are questions for your counsel, decided against the text of the regulation. The ICO’s work on agentic AI is the place to watch for the UK regulator’s settled position, and it is not settled yet.

The research cited here is research about memory systems and their failure modes. It is not a measurement of how common these failures are across enterprise deployments, and this article does not offer one either. We do not certify anyone, and no review we run makes an organisation “compliant” with anything. What an architecture review can establish is narrower — where a property is applied in a running system, where it is lost, and which team owns the layer it is lost at.

The person who decides differently is whoever owns the assistant platform and has the memory setting in front of them, along with the data protection lead who has not yet been told the store exists. The decision is not whether to enable memory, which is a good feature and will be enabled. It is what the write path is allowed to keep and what it must record about the keeping — and that decision stays available for roughly as long as the store stays empty.