Agent Observability: From Evals to Production Traces

There is now a standard shape for an agent trace. OpenTelemetry describes it as a top-level invoke_agent span with child chat spans for each model call and execute_tool spans for each tool invocation.

The conventions are recent and still settling, which explains most of the confusion in this area. Teams instrument something, they instrument it differently from each other, and few can answer the question that matters after an incident: why did the agent do that.

This article covers the three practices that answer it together, and how they connect: evals before you ship, tracing after you ship, and what both have to change once more than one agent is involved.

Agent observability is the practice of instrumenting an AI agent so that a completed run can be reconstructed from the outside: the model calls it made, the tools it invoked and with what arguments, what those tools returned, how control moved between agents, and what the whole thing cost in tokens and wall time.

The shift from ordinary application observability is in the unit of interest. A web service trace answers what happened to a request. An agent trace has to answer why a decision was taken, because the code path was chosen at runtime by a model rather than written in advance by a developer.

For the wider practice across AI systems generally, the guide to AI observability and its benefits covers the foundations this builds on.

The two terms get used interchangeably and they are not the same scope. The difference decides what you can debug.

If you only capture the model calls, an agent that chose a reasonable-looking but wrong tool produces a trace in which every individual completion looks fine. The fault is in the sequence, and the sequence is what the agent layer adds.

Start from the OpenTelemetry GenAI conventions rather than inventing a schema, because a convention that is still moving is easier to follow than to retrofit. The conventions define the agent span, the tool span, and the attributes that identify an agent.

invoke_agent {gen_ai.agent.name}        the whole task
  ├── chat {model}                       a model call
  ├── execute_tool {gen_ai.tool.name}    a tool the agent ran
  │     arguments, result, error, duration
  ├── chat {model}                       the model reading that result
  └── invoke_agent {sub-agent}           work delegated onward

attributes worth setting on the agent span:
  gen_ai.agent.id        stable identity across runs
  gen_ai.agent.name      human-readable, appears in the span name
  gen_ai.agent.version   so a regression can be tied to a change

Beyond the span tree, three things are worth capturing because they are the ones you will wish you had during an incident.

• Tool arguments and results, not just tool names - knowing the agent called a refund tool is far less useful than knowing which amount it passed.
• The decision context - what the agent had in context when it chose, since a wrong choice made on incomplete input is a retrieval bug rather than a reasoning one.
• A terminal outcome marker - an explicit record of whether the task ended in the action it was meant to produce, which is what lets you measure completion rather than absence of errors.

That last one has a second payoff. An agent that records what it did is dramatically easier to verify later, which is the same property that determines how much of its behaviour any test harness can confirm.

Note: Execution records only become useful once something aggregates them across runs. TestMu AI turns per-run results into trends, flakiness signal, and root cause leads. Try it free.

Teams often adopt one and treat it as covering the other. They sit at different points in the lifecycle and fail in opposite ways.

A team with only evals ships confidently against a case set that drifts further from production every week. A team with only tracing learns about every problem from a customer. The agent evaluation framework guide covers the eval side in depth, and the roundup of AI agent evaluation tools compares what is available to run them.

The value is not in running both. It is in letting each one feed the other, which most teams never wire up.

• Traces become eval cases - when a production run goes wrong, the trace already contains the inputs and the context. Promote it into the eval set so the next change is measured against it, and the same incident cannot recur silently.
• Eval failures tell you what to instrument - if an eval fails and the trace cannot show why, that is a gap in instrumentation rather than a gap in the agent. Add the attribute and the next failure explains itself.
• Production distribution reweights the eval set - trace data shows which intents actually arrive and in what proportion, which is the only honest basis for deciding what the eval suite should overweight.
• Agent version ties both together - tagging traces and eval runs with the same version attribute is what turns two separate dashboards into one answer about whether a release helped.

The fourth point is the cheapest and the most often skipped. Without a shared version identifier, a rise in production failures cannot be attributed to the change that caused it.

Adding agents changes the shape of the problem rather than its size. One logical request stops being a line and becomes a tree, often executed partly in parallel.

• Trace context must survive every handoff - if the identifier is not propagated when one agent delegates to another, you are left with several partial stories and no way to join them.
• Attribution replaces error rate - the useful question stops being how many runs failed and becomes which agent's decision caused the outcome, which only a joined trace can answer.
• Concurrency introduces write ordering - two agents acting in parallel can touch the same record, and without timestamps and identity on each tool call the last writer is invisible.
• Cost accounting needs a per-agent split - a rising bill is unactionable until it is attributed to the agent and the tool that produced it.
• Rollout has to be per agent - releasing one specialist at a time keeps the blast radius small and makes a regression attributable, which a whole-system deploy does not.

Deployment practice follows from that. Ship one agent at a time behind a flag, keep the previous version routable so a bad release can be reversed without a rebuild, and hold the eval suite as the gate on the way in. The methodology for that gate is covered in the guide to multi agent testing, and the routing patterns these deployments rest on are in the piece on agentic AI orchestration.

Instrumenting everything at once produces a large bill and a dashboard nobody reads. This order gets a usable signal quickly.

• Emit the agent span and tool spans using the OpenTelemetry names, so your data is portable if you change backend later.
• Add a stable agent id and version attribute before you add anything else, because they are what make every later comparison possible.
• Record tool arguments and results, with secrets and personal data redacted at the point of capture rather than in the backend.
• Mark terminal outcomes so completion is measurable, not inferred from the absence of an exception.
• Sample deliberately, keeping every failed and every adversarial-looking run while sampling the successful ones.
• Only then build dashboards, and build them around drift signals rather than raw volume.

On redaction, treat the trace as a system that will be read by more people than the agent's own logs. Tool arguments are exactly where account numbers and personal data end up.

Two parts of the TestMu AI platform map onto this lifecycle, and they sit on opposite sides of the ship line.

• Before shipping - Agent Assurance covers the eval side for both kinds of agent, grading conversational agents on the quality of the reply and autonomous agents on the truth of the effect, with scenarios generated rather than hand-authored. The conversational category is covered on the AI agent testing platform page; the autonomous category is pre-alpha at the time of writing.
• Across runs - Test Insights is the read side of the platform. It aggregates the execution records the other products produce and turns per-run pass or fail results into longitudinal signal: trend dashboards, flakiness and stability, error categorization, and agentic root cause analysis that localizes a likely cause as a lead to verify rather than a verdict.

The distinction worth keeping is that Test Insights is observability over testing rather than over production traffic. It answers which checks are chronically unstable and whether quality is improving across builds, which is the question your eval suite raises and your APM cannot.

Start by adding two attributes: a stable agent id and a version on every trace you already emit. Without them no comparison across releases is possible, and with them most of the other analysis becomes available later without re-instrumenting.

Then wire the loop in one direction before both: take the next production run that goes wrong, promote it into your eval set, and gate the next release on it. For background on where this sits in a wider QA practice, see the guide to agentic quality assurance, and for the pre-release half of the loop, end to end agent testing.

To put run history behind a dashboard rather than a spreadsheet, create a free TestMu AI account and start with the analytics dashboard documentation.