Trace-Based Evaluation: Testing AI Agent Reasoning Paths

Why Final Output Evaluation Is Not Enough

An agent can produce a correct final answer through flawed reasoning. Consider a research agent asked "What is the population of Tokyo?" that calls a search tool, gets back a page about Japanese demographics, correctly extracts the Tokyo population figure, and returns it. That same agent might answer "What is the population of Osaka?" by calling the same search tool, getting back a page about Tokyo demographics (because the search was poorly formulated), extracting the Tokyo population figure, and returning it as if it were Osaka's. The first query succeeds despite poor search formulation because the results happened to contain the answer; the second query fails because it did not. Output-only evaluation would pass the first case and only catch the second one, never revealing the underlying search formulation problem that causes both.

Trace evaluation catches this class of failure because it examines the search query the agent formulated, not just whether the final answer was correct. If the evaluation rubric says "the search query should specifically mention the city being researched," the first case would be flagged as a problem even though the output was correct. This is the fundamental value of trace evaluation: it catches unreliable reasoning patterns before they manifest as output failures, which is always a matter of when rather than if.

The practical impact is significant. An agent that passes 95% of output-only evaluations but has flawed reasoning on 30% of traces is fragile. Minor changes to the input distribution, tool response formats, or model behavior will expose those flawed reasoning paths and cause the output accuracy to drop suddenly. Trace evaluation provides the early warning that output evaluation cannot.

What a Trace Contains

A complete agent trace is a tree structure where each node represents one step in the execution. The root node is the user input, leaf nodes are the final output or tool responses, and intermediate nodes are LLM calls, tool invocations, and framework routing decisions.

Each trace node typically contains: a timestamp (when the step started and ended), a step type (LLM call, tool call, framework decision), input data (what was sent to the model or tool), output data (what was received back), metadata (token counts, latency, model version, temperature), and parent-child relationships (which step triggered this step and what steps it triggered).

For LLM call nodes, the input includes the full prompt (system message, conversation history, tool descriptions) and the output includes the model's response with any reasoning or chain-of-thought content. For tool call nodes, the input includes the tool name and arguments, and the output includes the tool's response or error. For framework nodes, the input and output describe routing decisions like "selected tool X because condition Y" or "entered retry loop because of error Z."

The richness of trace data depends on your instrumentation. Minimal instrumentation captures only the start and end of each step with basic metadata. Rich instrumentation captures the full content of every intermediate state, including prompt assembly details, parsing logic, and internal framework decisions. More data enables more thorough evaluation but increases storage costs and trace capture overhead. Most teams start with full content traces during development and switch to sampled or compressed traces in production.

Trace Evaluation Strategies

Step-count analysis is the simplest trace evaluation metric. Count the number of steps the agent took to complete the task and compare against a baseline or maximum threshold. An agent that consistently takes twelve steps on tasks that should require four has an efficiency problem, possibly caused by unnecessary exploration, poor planning, or repeated failed attempts. Track step count distributions by task category to set appropriate thresholds.

Tool selection path validation checks whether the sequence of tools called was reasonable for the given task. Define expected tool sequences for each task category (e.g., "customer lookup tasks should call the customer database tool first, then optionally the order history tool, never the payment processing tool"). Flag traces where the tool sequence deviates from expectations. Deviations are not always errors, sometimes the agent found a better path, but they warrant review.

Reasoning coherence evaluation uses an LLM judge to assess whether each step in the trace logically follows from the previous step. The judge reads the context at each decision point and evaluates whether the agent's choice was well-reasoned given the information available. This catches cases where the agent makes seemingly random decisions, ignores relevant information from tool responses, or contradicts its own earlier reasoning.

Information utilization scoring measures how effectively the agent uses the information it gathers. For each tool response in the trace, track whether the agent actually used the returned information in its subsequent reasoning or final output. An agent that calls three tools but only uses data from one has wasted two tool calls. Low information utilization indicates either over-enthusiastic tool calling or poor comprehension of tool responses.

Error recovery evaluation examines how the agent behaves when a step fails. Look at traces where a tool returned an error or an unexpected result. Does the agent retry with corrected arguments? Try an alternative tool? Inform the user of the limitation? Or does it hallucinate a response, pretend the error did not happen, or enter a loop? Grade error recovery on a rubric from "recovered gracefully and completed the task" to "failed silently and produced an incorrect result."

Context window efficiency measures how much of the context window the agent uses at each LLM call and whether it is using that space effectively. An agent that stuffs its entire conversation history into every call wastes tokens and may hit context limits on complex tasks. Track the input token count at each step and flag calls where the context is disproportionately large relative to the useful information it contains.

Implementing Trace Evaluation

Trace evaluation requires two components: instrumentation that captures traces during execution, and evaluation logic that scores captured traces against criteria.

For instrumentation, the standard approach uses OpenTelemetry-compatible tracing libraries. Most agent frameworks (LangChain, LlamaIndex, CrewAI) have built-in tracing support that emits spans for each execution step. If you use a custom framework, instrument it by wrapping each LLM call and tool invocation in a span that captures the input, output, timing, and metadata. Store traces in a backend that supports querying: Jaeger for self-hosted, Langfuse or Phoenix for managed, or a custom database for full control.

For evaluation logic, build trace evaluators as functions that accept a complete trace and return scores on one or more dimensions. A trace evaluator for tool selection might iterate through all tool call spans, check each one against an expected tool mapping, and return the percentage that matched expectations. A trace evaluator for reasoning coherence might extract the model's reasoning text from each LLM span and submit it to an LLM judge with instructions to check for logical consistency.

Run trace evaluation in two modes: inline (evaluating each trace as it is captured, suitable for development and low-volume production) and batch (evaluating a sample of traces on a schedule, suitable for high-volume production where evaluating every trace would be too expensive). Batch evaluation is more common in production because trace evaluation itself requires LLM calls for reasoning assessment, which adds cost and latency.

Trace Evaluation in Practice

Start with the highest-value trace checks and add more as you identify failure patterns. The three trace evaluations that provide the most value for the least implementation effort are:

First: Step count monitoring with alerts when step count exceeds 2x the median for a task category. This catches runaway agents, retry loops, and inefficient execution paths with zero LLM judge cost.

Second: Tool argument schema validation on every tool call span. This is a deterministic check (validate arguments against JSON Schema) that catches formatting errors, missing required fields, and type mismatches without any LLM overhead.

Third: LLM-judge reasoning assessment on a 10% sample of failed or low-confidence traces. Focus expensive evaluation on the traces most likely to reveal problems rather than evaluating every trace with equal depth.

As your evaluation matures, add targeted trace checks based on observed production failures. Every post-mortem should result in a new trace evaluation rule that would have caught the failure earlier. Over time, your trace evaluation suite becomes a comprehensive defense against the specific failure modes your agent is prone to, built from real-world experience rather than theoretical test design.