Unify Logo Footer.svg
AI Governance
Logo
Reading a Trace

Reading a Trace

Logo

4 mins READ

Introduction

A trace is one run of an agent, opened up. It is the only place that shows what actually happened rather than what was configured — which model was called, which tools ran, what came back, and where the time and money went. Every incident investigation ends here.

Where to find it

AI Governance > Agent Registry > open an agent > Observability > Traces. Selecting a row opens the trace over the list.

You can also arrive from an incident: the incident drawer's View trace link opens the exact run that raised it. That is usually the better entry point, because it starts you at a run that is already known to be interesting.

Sessions, traces, spans

Observability offers three lists, and they are three zoom levels on the same telemetry:

Level

One row is

Read it when you are asking

Sessions

A whole conversation

"How did this interaction go overall?"

Traces

One run of the agent

"What did it do on this turn?"

Spans

One step inside a run

"Which call was slow, expensive, or wrong?"

For a fuller treatment of how the three relate, see Sessions, Traces & Spans.

How to read a trace

  1. Start with the shape, not the content — A trace is a timeline of steps. Before reading any text, look at how many steps there are and how long each took. An unexpected shape — a retry loop, a tool called five times, one step holding most of the duration — usually finds the problem faster than the transcript does.

  2. Find the model calls — These are where cost and latency concentrate, and where the agent's reasoning is visible. Each carries its input, its output, and its token usage.

  3. Find the tool calls — A tool call is the agent acting on the world rather than talking about it. For governance purposes these matter more than the model calls: they are what a Tool input or Tool output control is watching.

  4. Read the step that failed, then the step before it — The visible failure is rarely where the cause is. A tool that errors on a malformed argument is reporting a problem created one step earlier.

  5. Check the cost against the work — Cost is on the trace. A trace that cost far more than its peers for the same task is a finding — usually retries, an over-large context, or a loop.

What a governance trace deliberately does not carry

Traces in AI Governance are not identical to traces elsewhere in the platform. Two things are held back here:

  • End-user identity. Governance responses omit the user and the last-message content that other surfaces show.

  • The conversation link. A governance session has no "view the conversation" path, because a governance session is a telemetry record rather than a support case.

Note: This is a deliberate minimisation, and it has a consequence for you. Governance gives you what the agent did without handing every governance reader the identity of who it did it for. Where you genuinely need the person — an incident on a chat surface — the incident record carries the user separately. Read that as the boundary it is: broad observability for the many, identified detail on the specific incident.

From an incident to its trace

This is the path that matters most, and it runs in one direction:

  1. The incident tells you what was caught — Check type, action taken, severity, the matched snippet.

  2. View trace tells you what surrounded it — What the agent was doing, what it had been asked, what it did next.

  3. The trace decides whether the incident is real — A PII match inside a document the user themselves pasted is a very different finding from the same match inside a tool call to an external service. The incident cannot tell those apart. The trace can.

"The incident tells you a rule fired. Only the trace tells you whether it should have."

One limit worth knowing before you plan around traces

Telemetry does not live forever. Records older than thirty days have aged out of retention — the online evaluation backfill states this explicitly when you ask it to score past traffic.

So a trace is evidence of an incident for a limited window. If a run needs to survive as evidence beyond that, the durable record is the incident itself, not the trace it points at. See Evidence & Export.