An execution trace is the internal record of a run: every routing decision, tool call, handoff, and correction, in order. It answers "how did we get this answer", which the conversation history deliberately cannot.
Two different records
This distinction causes more debugging confusion than anything else in multi-agent systems:
| Session history | Execution trace | |
|---|---|---|
| Contains | User message + final answer per turn | Every internal step |
| Includes tool calls | No | Yes |
| Includes handoffs | No | Yes |
| Purpose | What was said | How it was produced |
Session history follows a strict two-line-per-turn contract — the user's message and the final answer, nothing else, no matter how many handoffs and tool calls occurred internally. If a run is cancelled before producing any output, nothing is recorded for that turn at all; you will never see an orphaned user message with no matching answer.
So when a session looks suspiciously quiet given how much clearly happened, that is by design. The activity is in the trace.
Reading routing events
Trace rows carry an event type and a from/to sub-agent pair. Two patterns worth recognising:
route_errorfollowed by the same sub-agent taking another turn — this is usually a nudge-and-retry, not a failure.- The root agent never appears as the from/to party for a model-generated answer. Responders are always real sub-agents. If you are looking for the root in the timeline, you will not find it.
What to check first
When a run misbehaves, read the trace before the prompt. Most "the model did something strange" reports turn out to be a routing problem — an ambiguous edge, an unreachable specialist, or an exhausted budget — all of which are visible in the trace and invisible in the conversation.