A single event tells you what an agent did. It rarely tells you why. The refund only makes sense next to the lookup that preceded it and the email that followed it — one run, read start to finish. That's what the Sessions page is for: the tape, regrouped into stories.
Actions come in runs, not in isolation
Agents don't take one action; they take sequences. A support request arrives, the agent looks up the order, checks the policy, issues the refund, writes the note, sends the confirmation. Five events on the tape — one decision in reality. Judging any single event without its neighbours is how misunderstandings start: "why did the agent email this customer?" has a very different answer when you can see the three steps before it.
This is also where agent behaviour differs most from ordinary software. A service endpoint does one thing per request; an agent chooses a path — which tools, in which order, stopping where. Two runs that end in the same outcome can tell very different stories about judgement, and the story lives only at the session level. Review the events alone and you'll grade the steps; review the session and you grade the decision.
Correlation you don't have to build
Every event an agent emits carries its run's trace identifier, so the grouping comes with the record instead of being reconstructed afterwards. This is the quiet advantage of recording at the source: in most logging stacks, tying a model call to the tool calls it caused is a data-engineering project with timestamps and good intentions — and it produces answers like "probably these eleven, give or take." Here the session is a fact the events themselves state, and the Sessions page simply reads it back. There's no correlation job to build, no window heuristics to tune, and no "probably" in the answer.
Reading one run
Open a session and you get the run as a narrative: the events in order, each with its outcome and duration, each still carrying its own signature and chain state. The properties that make a single event trustworthy don't dilute at the group level — a session is simply a verified sequence read together.
Walk our support example through it: the session opens with the inbound request, then the order lookup (200ms, success), the policy check (allowed, under the refund threshold), the refund itself, the CRM note, the confirmation email. Read as six rows on the Events page, it's activity. Read as one session, it's a judgement you can assess: the agent checked before it spent, and every step is signed. For the reviewer, the question shifts from "did this happen?" to the one that actually matters: "was this run, taken as a whole, the right behaviour?"
Where sessions earn their keep
- Dispute resolution. The customer says the agent acted strangely; the session shows the whole exchange, in order, with proof. Most disputes end at "here's the run."
- Behaviour review. Sampling whole sessions — rather than random events — is how you evaluate whether an agent's judgement is sound, not just whether its individual actions succeeded. A practical habit: pick a handful of sessions per agent per month and read them like case files. It's the cheapest agent-quality process you can run, and the material is already organised for it.
- Incident reconstruction. When something went wrong at 3am, the session is the difference between a timeline you assemble and a timeline you read. The run that produced the bad outcome is one click from the event that alerted you.
Sessions sit between the tape and the census: events are what happened, agents are who did it, sessions are the story each run tells. Questions about how your runs group? Ask us.