Deleting AI agent memory may leave bytes in SQLite files

A product promises “forget this user” after deleting an agent thread. An open LangGraph issue reports a narrower result for a tested SQLite checkpointer and store: live records disappear, while text or embeddings remain recoverable from database or WAL files. This is a version-specific report, not proof about every agent deployment.

Define what deletion must cover

List the thread checkpoint, long-term memory store, vector index, write-ahead log, backups and replicas. A successful API response or zero rows in a query establishes logical deletion in that view. It does not by itself establish physical erasure across those storage surfaces. Test with synthetic markers in a copy of the actual configuration.

Follow the storage engine’s rules

SQLite documents that secure_delete changes how deleted content is overwritten and that ordinary WAL checkpoints do not necessarily truncate the log file. Its WAL guide explains why the journal can persist while connections remain open. Choose a deletion procedure that fits the deployed backend and operational constraints, and verify it against database files and backups; do not blindly run maintenance commands on production.

Make the customer promise precise

Document what a “delete” request removes immediately, what expires on retention schedules and who can verify completion. Track library and SQLite versions because behavior can change. If a regulatory erasure claim is involved, have the data-governance owner approve the tested procedure.

Adovo’s view

Memory is a product feature until a customer asks to forget. Then it becomes a data lifecycle obligation. Design the deletion proof at the same time as the memory feature.