Group multi-turn conversations with sessions and users
The Currai team, Engineering — May 9, 2026
A single chat turn is one trace. But a conversation is ten turns, and a user has fifty conversations — and when someone reports "the bot got confused halfway through," you need the whole thread, not one isolated turn. Sessions and users are how you stitch traces back into the shapes your product actually has.
Pass a session id to group turns
Every trace that shares a session_id is stitched into one replayable timeline.
Add a user_id and you can slice every metric by the person on the other end.
Use a stable id you already have — your own conversation row id makes the best session id, because it ties the trace back to your database.
Why the session view matters
Bugs in multi-turn apps are rarely in a single turn. The model loses the thread because turn 3 dropped a fact, or the prompt blew past the context window by turn 7, or a tool call early in the conversation poisoned everything after it. Looking at one trace, you'd never see it. Looking at the session, the failure has an obvious "before and after."
Slice everything by user
With a user_id on every trace, your dashboards gain a dimension:
- Cost per user — find the heavy accounts before they surprise your margins.
- Latency per user — spot the customer on a slow region or a giant context.
- Volume per user — see who actually uses the feature you just shipped.
Keep ids consistent across services
The one mistake to avoid: generating a fresh session id in each service that touches the request. If your gateway, your worker, and your eval job each invent their own, the timeline fragments. Decide the session and user ids once, at the edge, and pass them down. Consistent ids are the entire trick — get them right and the conversation reassembles itself.
currai