The retention question nobody asks

Somebody asks how long agent transcripts are kept. The answer comes back as “we keep them”, said in the tone of a feature. And it is a feature: users like their history, support needs it to reproduce a complaint, the eval team wants a corpus. Everyone in the room hears an answer, and the meeting moves on.

“We keep them” is not an answer. It is missing a number, and this lesson is about why the number is almost never there, why that is an ordinary engineering outcome rather than negligence, and why the law reads it as a gap anyway.

The correct causal direction

The tempting sentence is that transcripts are kept forever by default. It is close to true in practice and it is not a claim any source supports, so here is the version that is defensible.

Nothing has to decide to keep data. Something has to decide to delete it. A transcripts table accumulates because writing rows is the feature and deleting them is a separate piece of work that no user story asked for. Until somebody writes that job, the store grows, and that is not a default anyone chose — it is the absence of a decision, which looks identical from the outside and is a very different sentence in a meeting.

The law then arrives from the other direction. Article 5(1)(e) requires that personal data be:

“kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed” (GDPR, Article 5(1)(e))

Read what that does and does not say. It does not describe what databases do when unattended; regulations do not make claims about engineering defaults. It imposes an affirmative, ongoing obligation to have decided on a period, tied to a purpose, and to keep data no longer than that. Unbounded retention is not the state the law describes as normal. It is the state the law describes as non-compliant.

Two systems that get conflated, constantly

The fastest way to lose this argument is to mix up the model vendor’s logs with the product’s own database. They are different systems, with different defaults, different owners and different retention periods, and the conflation runs in both directions.

• The model vendor’s API-layer logs. Bounded, documented, and measured in days. OpenAI, documenting its own platform, states a default retention window of 30 days for chat completions for abuse-monitoring purposes (OpenAI data controls — a vendor documenting its own product, cited here only to draw the contrast). Whatever the number is for the provider your team uses, it is a published number belonging to a system your company does not run.
• Your product’s transcript store. Not bounded by anything unless someone bounded it, because it is a table your team wrote. There is no vendor page to check. There is a schema and a cron job that either exists or does not.

Cite the first as evidence about the second and you are wrong in a way that will be corrected immediately. The model vendor’s 30 days says nothing about your chat history sidebar, and a team that answers “30 days, it is in the provider’s docs” has answered about the wrong database. That substitution is the specific thing to listen for.

There are more than two stores, which is the part that makes this awkward rather than merely unanswered. The trace backend from the trace-view lesson has its own retention. So does the session-replay vendor. So does the error reporter, and the analytics warehouse, and whatever the eval team copied into a bucket in March. Each has its own period and its own owner, and an erasure request has to reach every one of them.

Policy text is not a retention control

OWASP’s 2026 entry on sensitive information disclosure states the engineering version of the same point in its first tier of mitigations: technically enforce no-train and no-retain commitments rather than policy text alone. A retention policy in a document, with no mechanism that carries it out, is a statement of intent. The store keeps growing exactly as fast as it did before the document was written.

That gives your flag its second question. Not just “what is the period?” but “what enforces it?” A named job, on a schedule, with a way to tell whether it ran, is a control. A paragraph in a policy is a paragraph.

The commitment a UI makes on someone else’s behalf

Here is where this stops being a backend concern. A chat history sidebar is a promise. “Your conversations”, listed by date, scrolling back to the beginning, is a product statement that these persist and will be there tomorrow. Users read it that way, correctly, because that is what it says.

Nobody wrote that promise down as a retention decision. It was a layout choice, made in a design review, by someone thinking about whether the sidebar should be collapsible. But it now constrains what a deletion period can be, because shortening retention becomes a visible product regression rather than an internal cleanup. The person who will have to answer an erasure request, and the person who will have to defend a retention period to an auditor, both inherit a constraint set by a component.

A few more of these, all of them layout decisions with retention consequences:

• Infinite scroll on history. Implies no horizon. Pagination with a visible end implies one.
• Search across all past conversations. Implies an index, which is a second store with its own retention and its own deletion path.
• “Restore” or an undo on a deleted thread. Means deletion is a flag, not a deletion. Anything downstream reading the raw table still sees the row.
• Exporting a transcript. Creates a copy in a place with no retention policy at all, usually somebody’s downloads folder or a shared drive.

None of these is wrong, and the point is not to remove them. The point is that each one is a retention commitment made in a design review by someone who did not know they were making one, and you are now the person in that review who does.

What this does not cover

This module has produced a stack of observations and no owners. Every flag in your log now has a “what I saw” and a “why it matters here”, and empty columns after that, which is the state the log was designed to reach at this point rather than a gap in it.

The module on raising it properly fills the rest in, and it opens on the thing that makes a telemetry choice a governance question rather than a preference: the SOC 2 lesson, and the mechanism by which a vendor a front-end team installed ends up inside somebody else’s audit scope. After that comes naming the single role that can close each flag, raising it with a severity that does not block a release, and writing the pass condition that lets you stop carrying it.