How do session and run ids relate to trace ids across a multi-turn LLM conversation?

## The three scopes An LLM conversation has more than one natural unit of work, and each needs its own identifier. - **Trace id** — created by the tracing layer, identifies one trace. A trace should cover an operation with a definite start and a definite end, short enough to be viewed as a whole. For LLM systems that unit is a turn: one user input and everything the system did in response. - **Session id (or conversation/thread id)** — created by your application, identifies a sequence of turns belonging to the same user interaction. It has no fixed lifetime: a trip-planning conversation may run 11 turns over 40 minutes, or be resumed the next day. - **Run id (or invocation id)** — identifies one logical execution of the agent for one turn. Usually it maps to a single trace, but not always: if the whole turn is retried after a transient failure, or resumed from a checkpoint, you get more than one trace for the same run. Keeping the run id separate makes 'this turn was attempted twice' expressible. ## Why not one trace per conversation It is the first thing people try, and it breaks in four ways. Traces are assembled by the backend and are typically only rendered well once complete, so an open conversation shows as a permanently unfinished trace. Backends impose limits on spans per trace and on how long they will hold a trace open for late arrivals; a long conversation exceeds both. Trace-level operations — a whole-trace view, a per-trace decision, a duration — become meaningless when the 'duration' is dominated by the user thinking for six minutes between turns. And latency analysis is destroyed: the p95 of a conversation tells you nothing about the p95 of a response. The inverse mistake is subtler: generating a fresh session id per turn, or never recording one at all. Then each trace is individually readable but nothing reconstructs the interaction — and most real LLM bugs are conversational. The answer was wrong *because* of what happened three turns earlier. ## Where the ids go Put them in span attributes. At minimum on the root span of each turn, because that is what most backends surface in trace lists and let you filter on. If your backend only indexes attributes per span — many do — put them on every span, which in practice means the harness stamps a fixed set of correlation attributes onto every span it creates. The set worth stamping: session id, turn index, run id, user or tenant id, entry point or feature name, and the app or prompt version. Version matters because the most common cause of 'it got worse overnight' is that something in the prompt or the model changed, and the only way to see that in a trace list is to have recorded which version served each turn. Also record the provider's own response identifier as an attribute on the model-call span. It is the id you quote when you need the provider to look at a specific request from their side, and it is not derivable from anything else you hold. ## Work that outlives the turn Some turns kick off work that finishes later: a long-running booking confirmation, a background summarization. Do not keep the turn's trace open for it. Emit it as its own trace carrying the same session and run ids, and add a span link back to the originating span so the two are navigable from each other. You keep both properties: each trace closes promptly, and the relationship survives. ## Practical payoff With these ids in place, three common requests become one query each. 'Replay this conversation' — filter traces by session id, sort by turn index. 'Did this regress with the new prompt version?' — group turns by version. 'A user says the assistant contradicted itself' — you get one session id from the application and read the turns in order, seeing at which turn the contradicted fact left the context. Without them, you are matching timestamps against user ids and guessing, which is exactly the state tracing was supposed to end. ## A note on identity hygiene Session id is not user id, and it is not the trace id. A user has many sessions; a session has many traces. Reusing the user id as the session id merges a year of interactions into one bucket. Reusing the trace id as the conversation id makes every turn its own conversation. And session ids are correlation keys that will end up in dashboards and links, so they should be opaque, generated values rather than anything derived from user data.