Why isn't deleting an AI memory as simple as deleting a database entry?
Because modern memory systems do not store a fact once. They connect it to other facts, summarise it, and sometimes use it to generate further conclusions that get stored separately. Research on machine unlearning in agentic memory names the problem directly: "derived artifacts in memory (e.g., summaries, knowledge graph entities) may aggregate multiple sources, requiring dependency-aware deletion to avoid destroying shared artifacts."
In plain terms: if a fact was folded into a summary, or used to infer something else that was stored on its own, deleting the original does not undo what was built on top of it.
Is there a deeper problem than "we forgot to delete the copies"?
Yes, and it has a name in current research: information backflow. Researchers studying this in AI agents describe it precisely: "even after information is removed from the agent's memory, this parametric residue can then be used to regenerate the forgotten content during subsequent interactions, which is written back into memory and reverses the unlearning."
A system that successfully deletes something from its explicit memory store can, in some architectures, reconstruct that information later from patterns the underlying model already learned elsewhere — undoing the deletion with nobody intending it. The same work describes this as making "isolated unlearning strategies fundamentally insufficient" on their own.
Does that mean right-to-be-forgotten requests are impossible to honour?
Not impossible, but harder than most people assume, and better treated as an engineering commitment than a checkbox. What works, per the research, is designing for deletion from the start rather than retrofitting it: tracking dependencies between stored facts and anything derived from them, removing an original and everything meaningfully built from it together, and being explicit about the scope of what "delete" covers rather than implying a blanket guarantee the architecture cannot back.
What does deletion actually cover in Closer?
The specific answer, because a vague one is worse than none:
- > The unit of deletion is a client, not a memory. Closer has no route or button that deletes one individual stored memory. If a single fact needs to go, the options are to delete the whole client or to correct the record going forward.
- > Deleting a client erases their memory scope in the vector store first, then cascades every owned row in one database transaction: notes and transcripts, pending actions, memory rows, and the knowledge-graph entities and relationships derived from those conversations.
- > The cached transcript for a recording goes too — unless another client's note still references the same recording, in which case that shared cache entry survives so the other client's record is not collaterally damaged.
- > Deletion is admin-only. A non-admin user on the account cannot erase a client.
- > The vector-store erase is best-effort by design. If that store is unreachable at that moment, the database delete still proceeds and the failure is logged rather than swallowed — which means an operator has to check the logs and re-run the erase. We would rather tell you that than let a failed delete block the rest of the cascade silently.
- > Closer does not train or fine-tune any model on your data. It calls hosted provider APIs; there is no in-house model carrying your conversations in its weights. What the providers do with a request they receive is a separate question, covered in our post on sending conversations to an LLM provider.
Does anything expire on its own?
No, not unless someone turns it on. Closer ships with the age-based retention sweep disabled. When an operator enables it, it deletes stored transcripts, cached transcripts and the memory audit log older than the configured cutoff — and it deliberately does not touch the vector store, because that store exposes no created-at filter to sweep on. That gap is documented in the code rather than papered over.
The practical consequence: if you want a client's data gone, delete the client. Do not assume time will do it.
What should you ask any product that claims deletion?
- > What is the unit of deletion? A single fact, a conversation, a person, or an account — the answers are very different.
- > Does it reach the derived artifacts? Summaries and graph relationships are the hard part, not the original row.
- > Has any of the data ever been used to train or fine-tune a model? That is a fundamentally harder deletion problem than removing something from a retrieval store.
- > What happens if part of the delete fails? A system that cannot tell you is a system that has not thought about it.
Key takeaways
- > AI memory deletion is a live research problem: derived summaries and graph entities do not disappear when the original fact does.
- > "Information backflow" describes a model regenerating deleted content from what it already learned, reversing an unlearning step.
- > In Closer the unit of deletion is a client: their memory scope, notes, transcripts, actions and knowledge-graph rows all go together.
- > Closer cannot delete one individual memory in isolation, and deletion is admin-only.
- > Nothing expires automatically — the age-based retention sweep ships off, and it never purges the vector store even when enabled.