Erasure Requests Against Agent Memory

Write down the derivation graph, because that is what you are actually deleting from.

Teams answer erasure requests against the store they think of as "the data" — the conversation table. In an agent with memory, that table is the root of a tree, and every node below it is a separate copy with a different key.

• Raw turns. The conversation itself, keyed by user and session. This is the easy one, and it is the only one most runbooks cover.
• Embeddings. Vectors derived from those turns, usually keyed by chunk ID in a different system with its own backups. A vector derived from personal data is still personal data; it is not anonymisation, and treating it as such is the most common single mistake in this area. See embeddings for why the geometry does not launder the content.
• Extracted facts. The distilled semantic memory — "prefers metric units", "account upgraded on the 12th" — written by an extraction pass and no longer textually resembling the turn it came from. Search will not find it by name if the name was normalised away.
• Rolling summaries. Compaction output that folds many turns into one paragraph. Delete one contributing turn and the summary is unchanged, still asserting what the turn said. The write-path architectures essay covers how many of these paths a normal agent runs.
• Graph nodes and edges. Relational memory holds people as first-class entities with edges asserting relationships and validity intervals — the subject is quite literally a node, and the edges pointing at it were written by other subjects' conversations.
• Downstream corpora. Eval golden sets, few-shot pools selected by a prompt optimiser, fine-tuning extracts, and analytics warehouses. These are the copies that escape every deletion job, because nobody thinks of them as memory.

Key every derived artefact to its sources, at write time.

Everything else in this page is downstream of one decision, and it costs almost nothing on the day you make it: when a derivation runs, record what it derived from. Retrofitting this after a year of writes is an archaeology project; doing it at the write path is a column.

• Store source IDs on every derived record. Every embedding, extracted fact, summary and edge carries the list of turn IDs — and therefore subject IDs — that produced it. Deletion becomes a reverse index lookup instead of a semantic search, which is the difference between a job that completes and a job that plausibly completes.
• Carry the subject, not just the account. A support conversation is about a customer but may name their spouse, their doctor or their colleague. Third parties mentioned inside a conversation are data subjects with the same rights and no row of their own. At minimum, flag records where extraction identified a person other than the account holder, so a request from that person is answerable at all.
• Version the derivation, not just the output. Record which extractor and which prompt produced a fact. When you rebuild after a deletion, you need to reproduce everything except the removed source — and an unversioned extractor means the rebuild silently changes unrelated memories too.
• Make the memory layer's IDs yours. If a hosted memory product assigns its own opaque IDs, map them to your source IDs in your own database. Otherwise your deletion capability depends on a vendor's search working the way you hope on data whose shape you cannot inspect.

Make derived state re-derivable, then delete by rebuilding.

Surgical deletion from derived artefacts is mostly impossible. You cannot subtract one turn from a summary, and you cannot un-average a vector. The tractable move is to stop trying: treat derived memory as a cache over the raw layer, delete from the raw layer, and rebuild.

• Rebuild is the primitive; patching is the exception. Drop every derived artefact whose source set intersects the deleted turns, then re-run the derivation without them. This is boring, verifiable, and produces exactly the state that would have existed had the subject never spoken.
• Size the rebuild before you promise a deadline. Statutory response windows are measured in weeks, so a rebuild that takes hours is fine and one that takes a month is a compliance problem. Test it at production volume once, and know your number. If a full rebuild is infeasible, scope it: rebuild only the affected user's partition, which is an argument for partitioning memory by subject in the first place.
• Accept the collateral loss and design for it. A summary rebuilt without one participant's turns is a different, slightly worse summary — for everyone who shares it. That is the correct outcome, and it is a reason to prefer per-subject memory scoping over shared blobs wherever the product allows.
• Handle the shared-memory case explicitly. Memory blocks shared between agents, team-level knowledge and organisational scopes hold facts contributed by individuals who can each demand erasure. Decide in advance whether an organisational fact survives the departure of the person who supplied it, write the decision down, and make the answer visible in the product rather than discovering it during a request.
• Never rely on the model to forget. Instructing an agent not to mention something is a prompt, not a control. If the fact is retrievable, a sufficiently determined conversation retrieves it — the same reason memory poisoning defenses puts enforcement below the model rather than inside it.

Correction and erasure pull in opposite directions in a temporal graph.

Memory systems built on temporal knowledge graphs do the right thing for accuracy: when a fact changes, the old edge is marked historical rather than deleted, so the agent can reason about what was true when. That property is a direct conflict with erasure, and it is easy to ship without noticing.

• Distinguish the two requests at the API, not in a runbook. "This is wrong, fix it" is rectification and should invalidate an edge while keeping the history. "Remove me" is erasure and must remove the node, its edges, and their historical versions. A system with only one delete verb will quietly answer the second request with the first.
• Tombstones are evidence, and evidence about a person is personal data. A tombstone that says "the fact about subject X was erased on the 3rd" re-identifies exactly what you were asked to remove. Keep the deletion record in the audit log with a pseudonymous reference, not in the memory graph — the split between operational record and content is the one audit trails already draws.
• Edges asserted by other people still describe the subject. If another customer's conversation created an edge naming this person, deleting the subject's own turns leaves the edge standing. Erasure has to traverse inbound edges, and that traversal is only possible if step 2 was done.
• Graph rebuilds are not idempotent by default. Re-running entity resolution over a corpus missing one participant can merge or split entities differently. Pin the resolution model and prompt alongside the extractor, for the same reason and with the same failure if you do not — see graph RAG for how sensitive that step is.

The memory vendor holds copies you cannot see, and the trace is a separate problem.

Most teams do not build the memory layer. A hosted memory product is a processor holding derived copies of your users' data on its own schedule, and the boundary between it and the rest of your stack is where deletion jobs go to die.

• Require a delete API keyed by your subject ID, and test it. Not a support ticket, not a bulk namespace wipe. Then verify: write a fact for a synthetic subject, delete it, and query for it through every read path the product exposes — including the semantic search that does not match on the identifier.
• Ask what the deletion does to their derived state. A memory product that extracts, summarises and promotes has the same derivation graph you do. "Deleted" often means the record is gone while the summary that absorbed it is not. Get the answer in writing, because the obligation stays with you.
• Pin down backups, replicas and the vendor's own logs. Backup windows of a month or more are normal and defensible if documented — an undocumented one is a finding. The same applies to any region replication, which is also a residency question.
• Keep memory and traces on separate tracks. Traces are records of what the system did and are governed by preservation duties, statutory floors and legal holds; memory is content the agent will act on tomorrow. They need different retention answers and they conflict — retention and legal hold covers the trace side, including the case where a hold blocks an erasure you have already accepted.
• Put every memory store in the inventory. The store you forget is the store that fails the request. Memory backends belong in the agent inventory with a named owner and a documented deletion path, alongside the models and tools.

A deletion you cannot evidence is a deletion you did not perform.

The regulator's question, and the customer's, is not "did you run the job" but "show me". Erasure is one of the few operational capabilities where the proof is a deliverable, and it is far cheaper to build the proof into the job than to reconstruct it under pressure.

• Emit a per-request manifest. Which stores were touched, how many records in each, which derived artefacts were rebuilt, which vendors were called and what they returned, with timestamps. This is the artefact you hand over, and it takes ten lines in the job to produce.
• Run an end-to-end drill on a synthetic subject, quarterly. Seed a fake person through real flows until they appear in raw turns, vectors, an extracted fact, a summary and a graph edge. Then file a deletion request through the front door and search every store afterwards. Every organisation that does this finds at least one store nobody remembered.
• Search semantically, not just by key, when you verify. The whole premise of this page is that derived artefacts lose the identifier. A verification that greps for the user ID will pass while the summary still names them.
• Instrument the queue, not just the outcome. Time-to-completion against your statutory window, requests aged past half the window, and per-store failure rates. A deletion pipeline that silently fails on one store is indistinguishable from a working one until an audit.
• Write the impossible cases down before you are asked. If personal data reached fine-tuned weights, deletion of the source does not remove its influence, and the honest answer is a documented filter at the extract step plus a plan for the affected checkpoint. The unforgivable version is discovering this during the response.

Related: data governance for the classification this depends on, memory types for what each layer actually holds, delegated access & consent records for the permission that put the data there, and the memory-framework comparison for how four production memory layers differ on exactly this axis.