Your agent's delete button is a UI event, not a deletion

A guide published on dev.to opens with a line most teams shipping agents can check against their own schema in an afternoon: a delete button is easy to ship, and real deletion is much harder ^[1]. The gap matters because it is structural rather than sloppy, since one user action scatters data across prompts, traces, memory stores, vector indexes, tool logs, temporary files, model gateways, retry queues and analytics events ^[2], which is nine distinct surfaces before anyone writes a line of deletion code ^[17].

The guide's inventory of what a single agent run can produce runs to 19 record types ^[4][18]: raw prompt and rewritten prompt, retrieved documents, embeddings, cached model input, tool arguments and tool responses, browser snapshots, screenshots, uploaded files, generated artifacts, memory summaries, trace logs, billing metadata, support debug events, queue state, approval comments and eval replay packets ^[4]. Some are user visible. Many are not ^[4].

The failure pattern is specific. A user clicks delete, the app removes the conversation from the sidebar, the backend keeps traces, embeddings, prompts and tool logs for debugging, and then a restored pointer, a support export, an analytics query or a vector search can still reveal the old content ^[5]. Delete only the visible chat row and the user is gone from the interface while their data lives on in five backend systems ^[3]. Agents add indirect resurrection paths on top of that: a memory summary keeps the important facts, an embedding still retrieves the old document, a cached prompt remains in a gateway, a support trace carries the tool arguments, an artifact contains copied text, and a fine-tuning dataset picks up the run by accident ^[6].

The remedies in the piece are unglamorous, which is the point. First, enumerate every storage surface and keep the inventory in the repo rather than in someone's head ^[7], with a per-surface deletion action column, because not every record deserves the same treatment ^[8]. Billing may legitimately retain a non-content record that 12 model calls occurred while dropping the raw prompt; observability can keep latency, token count, model name and error code while discarding message text and tool payloads ^[9]. Each location is then deleted, redacted or tombstoned according to its risk and legal retention rules ^[15].

Second, joins. The author argues for a lineage ID on every user-owned object, carried by every derived record, linking root to descendants ^[10][11], on the grounds that foreign keys to the visible chat are not enough: a vector store, an object bucket and a model gateway do not know your conversation schema, but they can know a lineage ID ^[12]. The trace event type in the guide carries a redactionState with three values, raw, redacted and deleted ^[11], which makes deletion a state machine rather than a boolean ^[19].

Third, stop treating deletion as all or nothing, which either keeps too much in the name of audit history or destroys the ability to explain abuse, billing and incidents ^[13]. The split proposed is content, meaning prompts, responses, retrieved chunks, uploaded text, screenshots, tool arguments and memory facts, against metadata, meaning timestamps, actor IDs, token counts, model names, status codes, cost totals, approval state, policy decisions and deletion receipt IDs ^[14].

That last item is the one to watch in your own build. The guide frames this as a trust feature rather than a compliance chore, on the argument that users forgive slow answers faster than a system that says deleted while keeping enough context to reconstruct the conversation ^[16]. The testable version: after a delete, query the vector index and the gateway cache by lineage ID, pull a support export, and see whether anything comes back.