How should you handle hidden reasoning traces in logs, retention and multi-turn calls?

## The scenario that makes it concrete A customer-facing support chat runs on a reasoning model. Product wants the reply clean — no deliberation in front of the customer. Compliance wants a record of how answers were produced. Legal wants personal data purged on the same schedule as the rest of the conversation. Engineering wants the multi-turn loop to keep working. Those four requirements pull on the trace in different directions, and the interview question is whether you can separate them. ## Exposure: a trace is conversation data The reasoning pass was generated from the prompt, which included the customer's message and whatever context you retrieved. So it contains the same personal data, account details and third-party content the conversation did. It also contains things the transcript does not: hypotheses the model rejected, half-formed accusations, speculative diagnoses, occasionally blunt characterisations of the user. That extra material is exactly what makes traces attractive for debugging and dangerous to spread. Practical rules: - **Classify the trace at the same level as the transcript**, and put it behind the same access controls. A common mistake is emitting reasoning into an observability platform with far wider read access than the conversation store. - **Run the same redaction pipeline over it.** If you scrub card numbers from transcripts, scrub them from traces; the model may have restated them while working. - **Delete on the same clock.** A deletion request that clears the transcript and leaves the reasoning is an incomplete deletion, and "we only kept the model's scratchpad" is not a defence. - **Never render it to the end user**, and be careful about internal support tooling too — an agent reading a rejected hypothesis aloud to a customer is a real incident shape. ## Evidence quality: what you retained may not be what happened Two separate reasons to be modest about a stored trace. First, **you may not have the real one**. Depending on the provider and mode you may receive the raw pass, a shorter model-written summary of it, or an encrypted block you can return but not read. A summary is a generated description of the reasoning, so it is tidier and more coherent than the underlying tokens — which makes it comforting and slightly misleading as a debugging artefact. Second, even a raw trace is not a guaranteed account of what determined the answer. It is text produced on the way to a reply, not an instrumented record of the computation. Keeping it for debugging and pattern-spotting is entirely reasonable. Presenting it as the model's justification to a regulator, an auditor or a customer is over-claiming, and a senior candidate should say so unprompted. What traces *are* good for: spotting that the model misread the input, that a retrieved document was ignored, that a tool result was misinterpreted, or that the same wrong turn recurs across a class of tickets. That is high-value debugging signal, and it is why keeping them under proper controls beats discarding them. ## Protocol: what you send back on the next turn This is where handling gets mechanical and provider-specific, so keep the claims at the level you can defend. The general shape as of mid-2026: reasoning is returned as its own block type alongside the answer, and providers specify whether that block must be sent back on subsequent requests. In tool-use loops — where the model reasons, calls a tool, receives a result, and continues — several providers require the prior thinking block to be returned **unmodified** so the continuation is coherent and any integrity signature still validates. Outside such a loop, prior thinking is commonly dropped by default, which is deliberate: carrying every turn's scratchpad forward would consume the context window for no benefit. The operational failure modes follow directly: - **Editing or truncating a returned thinking block** to save tokens can cause the provider to reject the turn, or degrade the continuation. - **Dropping a block the loop required** breaks tool-use continuity mid-task, often surfacing as the model restarting its reasoning or losing the plan. - **Rewriting history** — normalising, re-serialising, or re-ordering prior blocks — changes the prompt prefix, which can miss a cached prefix and turn a cheap continuation into a full re-read of the context. On long agent conversations that is a substantial and easily overlooked cost. The defensible engineering stance is to store the provider's message objects verbatim and replay them, rather than reconstructing conversation history from your own pretty-printed representation. ## Putting it together A workable design: capture the trace server-side into the same store and retention class as the transcript, redacted the same way; expose it only to a narrow debugging role; never send it to the client, so no bug can render it; replay provider message objects byte-for-byte across turns; and document internally that traces are a debugging aid, not an explanation of record. That set of decisions is what the question is really testing.