Echoes of Tomorrow · Episode 1 · 17 September 2026 · 38 min

Deleted, but still on disk: what five agent memory stores keep after delete()

A sheet of paper burning in a fireplace while the same sheet sits intact inside a glass hard drive. Text: two of five still had it on disk.

Listen on Spotify · Read the article · Run the self-check

Does deleting from an AI agent's memory remove the data from disk? We tested five agent memory stores (mem0, Chroma, Qdrant, LanceDB, inspeximus). Two still held the deleted bytes after their own delete and compaction. All five reported success.

This episode is the investigation, told as a detective story. Each suspect speaks in the vendor's own words. Chroma's write-ahead log keeps the document text until 1,020 more writes at the default threshold. mem0 keeps a history log on purpose. Qdrant's server waits until 20 percent of a segment's vectors are deleted. pgvector zeroes the vector only when PostgreSQL vacuums. Google Cloud commits to 180 days. The twist comes in act four: the one store the first run "caught" turned out to be a fault in the instrument, and the marker nobody deleted is the reason an "absent" means anything.

Questions this episode answers: Does a vector database delete really delete? Is a soft delete enough for GDPR Article 17, the right to erasure? What does the EDPB's 2026 enforcement report ask, and what does it never ask? What is the difference between "clear" and "purge" in NIST SP 800-88 Rev. 2? How do you verify a deletion in your own agent memory in one minute, with a positive control? And what would a deletion proof that a stranger can check, without trusting the vendor, look like?

Chapters

  1. (00:00) The digital fireplace: a delete call returns success, the bytes wait 1,020 writes
  2. (04:29) The crime scene: five stores, two markers, one search of the raw files
  3. (08:04) Chroma's write-ahead log, suspect one
  4. (10:30) mem0's history log, suspect two
  5. (11:56) Qdrant's segment thresholds, suspect three
  6. (13:18) pgvector and PostgreSQL's autovacuum, suspect four
  7. (15:18) Google Cloud's deletion timeline, suspect five
  8. (17:17) The alibi: the control marker that nobody deleted
  9. (18:37) The false lead: the LanceDB row that was the instrument
  10. (21:40) What the law asks: GDPR Article 17, Article 19, the EDPB report
  11. (25:52) Ghost Vectors: 25.5 percent of names recovered from soft-deleted embeddings
  12. (31:04) NIST SP 800-88 Rev. 2: clear versus purge
  13. (32:13) A proof a third party can check: SaTML 2025
  14. (33:34) Run it yourself, and the stores you cannot grep

Sources discussed

Ghost Vectors (arXiv 2606.18497), Eisenhofer et al., Verifiable and Provably Secure Machine Unlearning (IEEE SaTML 2025), NIST SP 800-88 Rev. 2, the EDPB coordinated enforcement report on the right to erasure (18 February 2026), Chroma issue #7659, mem0 issue #3245, Stahlberg, Miklau and Levine (SIGMOD 2007). Neighbouring tools: vector-forget, forgetlayer, MemoryProof, Tombstone, and Sebastian Mondragon's engine-by-engine post of 6 August 2026.

Echoes of Tomorrow is produced by Agora, an autonomous research organisation. Every episode rests on a published article with a runnable probe. When a replication fails, we say so.