Retention & Legal Hold for Agent Traces

You have already set a retention policy. Check what it says.

Trace retention gets configured once, during onboarding to an observability vendor, by whoever was setting up the pipeline. The dropdown offers something like thirty days on the cheaper plans, and thirty days is chosen because the bill is lower. Nobody records that a decision was made, because from inside engineering it did not feel like one.

• An agent trace is not an application log. A log line says a request happened. An agent trace contains the instruction the user gave, the evidence the agent retrieved, the reasoning it recorded, the tool calls it made, and the action it took in a real system. That is a record of a decision and of an act — the two categories every retention schedule already covers.
• The exposure is longer than the debugging window by an order of magnitude. Nobody debugs a nine-month-old trace. Everybody wants one when a customer disputes what your agent did nine months ago. Those two facts get resolved by a single TTL, and the TTL was sized for the first.
• There is now a statutory floor in at least one regime. The EU AI Act requires providers and deployers of high-risk systems to retain automatically generated logs for a period appropriate to the purpose and at least six months (Articles 19 and 26(6)), unless other law says longer — and other law frequently does, particularly in financial services and employment. The phase-in dates for standalone Annex III systems have already moved once, so treat the date as volatile and the floor as durable. See EU AI Act for agents.
• Thirty days can be non-compliant and over-retentive at the same time. Too short for the regulated decision path; too long for the ad-hoc internal tool that swallowed a support inbox full of personal data. One global TTL cannot be right for both, and setting it globally is how teams end up wrong in both directions simultaneously.

Three consumers, three schedules. Stop serving them from one store.

The reason a single number never works is that three unrelated stakeholders want the same data on incompatible terms, and they are rarely in the same meeting.

• Debugging wants everything, immediately, briefly. Full-fidelity spans including prompts and tool payloads, queryable in seconds, needed for days to weeks. This is the most expensive tier per byte and the one that should expire fastest. It is the tier described in tracing and observability.
• Evidence wants a defensible subset, for years, unaltered. Who asked, what the agent did, under whose authority, which model and policy version, and the approval if there was one. It does not need the token-level detail. It does need integrity — append-only storage and, ideally, hash chaining, which is the audit trail discipline rather than the observability one.
• Evaluation wants a curated, permanent, growing copy. A golden set built from real traffic is an asset that appreciates, and it is deliberately immune to expiry — which is precisely what makes it the hardest object in this whole subject. See production feedback signals for how traffic gets promoted into it.

Serve them from three tiers with three schedules, and make the evidence tier a deliberate projection of the trace rather than the whole trace. The projection is what makes long retention affordable and what makes it survivable — you are not keeping five years of raw prompts, you are keeping five years of a structured decision record that happens to be derived from them.

Enumerate the copies. This is where policy fails, not at the primary store.

Every mature agent stack fans the same trace out to somewhere between four and ten destinations, each with its own lifecycle, and a retention policy written against the trace store governs one of them. Write the list down; the first draft is always incomplete.

• The model provider's own retention. Your prompts sit on the vendor's side under the vendor's schedule, typically with a separate abuse-monitoring window and sometimes zero-retention terms you must ask for. That is a contract term, not a setting — negotiate it where it matters, per third-party model and vendor risk.
• The eval golden set. Promoted traces that intentionally never expire, usually in object storage owned by a different team, frequently with the personal data still in them.
• Fine-tuning and distillation extracts. Once traffic has been used to train weights, deleting the source record does not remove its influence. If personal data reached the training set you have a problem that retention policy cannot solve — the answer is a filter at the extract step, not a deletion at the end.
• Warehouse and BI exports. The nightly sync into the analytics warehouse carries its own retention, its own access model, and typically no awareness that the rows are agent decisions.
• Sub-processor telemetry. Gateways, guardrail services, vector stores and sandbox providers each see fragments of the same conversation and each keep them. The data governance map of the loop is what tells you which.
• Backups and incident snapshots. The store you deleted from has a thirty-five-day backup window, and someone's incident investigation copied a day of traces into a shared drive in March.

The operational rule that makes this tractable: tag every copy at creation with the retention class it inherits, and refuse to create untagged copies. A trace export without a retention class is the same category of defect as an untagged cost line — you will not find it later by looking.

Legal hold is a feature you have to build before you need it.

When litigation or an investigation becomes reasonably foreseeable, the duty to preserve attaches, and it overrides your deletion schedule. Observability systems are built on the opposite assumption — they delete by TTL as a design property, and a TTL is not something you can retroactively un-fire. Everything below has to exist in advance.

• A hold must suspend expiry, not copy data out. Exporting to a share drive is what teams do when there is no hold mechanism, and it creates an uncontrolled copy with no chain of custody. The mechanism you want is a flag on the records that the reaper honours.
• It must be scoped by something you can actually query. Holds arrive as "everything relating to this customer between these dates". If your traces are not indexed by a stable subject identifier — tenant, account, case — you cannot scope a hold and you will end up holding everything, which is both expensive and its own liability.
• Held records must become immutable, and the transition must be logged. Who placed the hold, when, on what scope, and under what matter. A hold you cannot evidence is a hold you cannot rely on.
• It has to reach the copies. A hold that suspends the trace store's TTL while the warehouse export quietly ages out has preserved the least useful copy. This is why step 3 comes first: the hold mechanism can only be as complete as your inventory.
• Release has to be as deliberate as placement. Holds that are never lifted turn into permanent retention by accident, which reintroduces every exposure the schedule existed to bound. Review open holds on a calendar.
• Rehearse it once. The first time you exercise a hold should not be the time it matters. A tabletop against a fabricated matter finds the missing subject index in an afternoon.

Erasure, hold and the golden set: the three-way conflict.

A data subject asks you to erase their data — under GDPR you have a month to respond. The same records are under legal hold, or have been promoted into an eval set that your regression gate depends on. Three legitimate obligations, pulling three ways, over one object. This is the case that decides whether your policy is real.

• Hold generally wins over erasure, but you must be able to say so. Preservation duties and legal claims are recognised grounds for retaining data against an erasure request. What you cannot do is invoke that informally: you need a record of which matter covers which subject and the ability to erase the moment the hold releases. An unstructured "we might need it" is not a ground.
• The eval set is not a ground. "Our regression suite would get weaker" carries no weight whatsoever against an erasure right. Anyone who has built a golden set out of raw production traffic containing personal data has built an obligation, not just an asset.
• Which is why promotion must launder the record. The step that moves a trace into an eval set is the right place to strip or pseudonymise identifiers — substituting consistent surrogates so the task stays coherent and the subject does not. Do it at promotion, because doing it later requires finding every copy, which is the problem you were avoiding.
• Pseudonymise the evidence tier at write time where you can. A decision record that references an account by stable internal ID, with the personal data resolvable only through a separate mapping table, gives you a record you can retain for years and a single place to honour an erasure without destroying the audit trail. This is the same design that makes long retention affordable in step 2.
• Log the resolution of every conflict. When you decline an erasure because of a hold, that decision, its basis and its expiry are themselves records. The regulator's question is never "did you delete it" — it is "on what basis did you decide, and can you show me".

Write the schedule, and make the default deliberate.

The deliverable is short and it belongs to a named owner. One page, four columns: tier, contents, duration, and the legal basis or business reason for that duration.

• Raw debugging tier — days to weeks. Full prompts and payloads. Shortest thing you can operate with, because it is the highest-risk and highest-cost data you hold. Redact at ingest.
• Evidence tier — years, set by the schedule you already have. The structured decision record, pseudonymised, append-only. Do not invent a number here: your company already has a retention schedule for business records and for the regulated processes this agent touches. Inherit it.
• Eval tier — indefinite, but only for laundered records. Pseudonymised at promotion, with an owner and a periodic review that removes tasks no longer representative of what you ship.
• Hold overlay — orthogonal to all three, with scoping, immutability, an audit log, and a review cadence for release.
• Regulated overlay — the floor, not the target. Where the six-month AI Act floor or a sectoral schedule applies, it sets the minimum for that surface; your own exposure usually argues for longer on the evidence tier and shorter on the raw one.
• Review it when the architecture changes, not annually. A new sub-processor, a new export, a new memory store — each is a new copy, and the schedule is only as current as the inventory behind it.

Related: audit trails and provenance for what the evidence tier must contain, data governance for agents for mapping the flows, data residency and sovereignty for where the copies physically sit, and the cost of human review for why the approval records are part of this too.