Agentic AI · Quality & Reliability

Correct answer.
Wrong way there.

An agent may accurately call every tool, arrive at the correct final answer, and still end up making fifteen LLM calls instead of three, or rely on a lucky guess after hallucinating a tool result. Only evaluating the end result masks the underlying issues that will become apparent in terms of cost and reliability when scaled up.

See how trajectory scoring works → Compare evaluation frameworks
SLIDE 01 : AGENT TESTING & EVALUATION
Cover slide: Agent Testing and Evaluation
Quick answer

Agent testing and evaluation Evaluation in production-grade considers not only the correctness of an agent's final answer, but also the entire process it followed to reach that answer, including the chain of reasoning, tools used, and intermediate steps. This is crucial because two runs of the same task can have different paths and both be either correct or incorrect, highlighting the limitations of a single output-only score. end-to-end (did the task succeed), trajectory-level (was the path efficient and sound), and component-level (what exact tool, retriever, or sub-agent malfunctioned) : evaluated based on five key aspects: task completion, precision, error rate, expenses, and speed/dependability.

SLIDE 02 : WHY AGENT EVALUATION IS DIFFERENT
Why evaluating an agent differs from evaluating a single LLM call
One output vs. a whole trajectory

A single score can't see what actually happened

Assessing a basic LLM call is straightforward: input, output, score, done. In contrast, an agent generates a trajectory involving a series of reasoning steps, tool calls, and intermediate actions spanning numerous turns before arriving at a final solution.

This alters the definition of 'good'. Two attempts at the same task may follow different paths and still yield the same result, or both fail for completely different reasons. An agent can provide the correct answer after making excessive tool calls, or fail despite correctly reasoning through the problem. Output-only scoring does not consider these nuances.

SLIDE 03 : THREE LEVELS OF EVALUATION
End-to-end, trajectory-level, and component-level evaluation
Zoom in when something breaks

End-to-end, trajectory, component

End-to-end Poses the most basic inquiry: has the task been accomplished? Task completion serves as the most evident indicator of the agent's performance, but it is contingent on how 'finished' is interpreted within the context of the task.

Trajectory-level questions if the route taken was both effective and sensible, rather than just focusing on the final destination. Component-level Goes even deeper by pinpointing the exact retriever, tool, or sub-agent in a chain that caused the failure, instead of leaving the team to speculate, trace-based evaluation links a failing score to the specific span responsible.

What to actually measure

Five dimensions, defined before you build a single scorer

Before creating automated scoring, it is essential to establish a clear metric and corresponding threshold for each evaluation, as they will serve as the foundation for all subsequent decisions.

SLIDE 04 : FIVE CORE EVALUATION DIMENSIONS
Five core agent evaluation dimensions: completion, accuracy, hallucination, cost, latency
Set thresholds before you automate

What's the target for each one?

What is considered an acceptable task completion rate? At what cost per task does the agent become economically feasible? How much latency will your users be willing to endure? Addressing these questions in writing before implementing automated scoring ensures that an evaluation program remains grounded in tangible criteria rather than a subjective assessment of 'seems okay.'

01
Task completion

Was the goal requested by the user successfully accomplished by the agent?

02
Accuracy

Did the agent produce accurate facts, values, and outputs?

03
Hallucination rate

How often does the agent state something ungrounded as fact?

04
Cost

How many tokens and tool calls does it take to complete one successful task?

05
Latency / reliability

What is the average time it takes to complete a task, and how reliable is its success rate?

SLIDE 05 : SCORING THE TRAJECTORY
Trajectory evaluation: scoring tool calls, loops, and recovery
What output-only scoring can't see

Did it wander, loop, or recover cleanly?

Trajectory evaluation captures the complete nested trace of model and tool calls, and then evaluates it against a reference path, considering tool-call accuracy, step count compared to the minimum required, any looping or backtracking by the agent, and how well it recovered from incorrect turns.

This is the root of cost and latency issues. An agent that completes the final task with excessive steps may appear satisfactory in a pass/fail dashboard, but the truth is revealed in the monthly bill or the p95 latency chart.

SLIDE 06 : LLM-AS-JUDGE: STRENGTHS & FAILURE MODES
LLM-as-judge evaluation: how it works and its known biases
A useful judge, with known blind spots

Calibrate it, don't just trust it

LLM serves as the primary evaluator on most assessment platforms, allowing models to assess factors such as helpfulness, tone, and the coherence of explanations that are difficult to score using automated methods.

The model has clear biases, favoring longer answers and specific answer positions, and preferring outputs similar to its own style. It is also non-deterministic, making a full model call per judgment too costly for every production turn. Research suggests that a 0-5 scale with explicit criteria aligns best with human judgment compared to binary pass/fail or a 10-point scale. Use it offline, calibrated on a sample, rather than relying on it unquestionably for every decision.

SLIDE 07 : BUILDING A GOLDEN DATASET
Building and growing a golden dataset for agent evaluation
Quality over quantity, from day one

Start at 50–100, grow toward 500+

Start with 50 to 100 test cases that include positive scenarios, critical edge cases, and any known failure modes. Continuously expand the test suite by incorporating any issues found in live production, with a goal of reaching 500 or more cases by the end of the first quarter.

Utilize a meticulously selected set of one hundred cases with clear projected outcomes over a larger, randomly generated set of a thousand cases with uncertain results. Implement the golden dataset for each pull request, evaluating task completion and accuracy automatically when feasible, and resorting to a calibrated LLM-as-judge only for dimensions that truly require a subjective evaluation.

Tooling

The 2026 evaluation framework landscape

Most teams often combine a general-purpose evaluation harness with a specialized tool for trajectory scoring, as no single tool can cover all aspects.

SLIDE 08 : EVALUATION FRAMEWORKS COMPARED
Comparison of agent evaluation frameworks and benchmarks
General harness plus a trajectory specialist

Pick a harness, then add trajectory scoring

Multi-purpose harnesses like LangSmith, Braintrust, Phoenix, and DeepEval support LLM-as-judge, structured-output checks, and daily app evaluations with pre-set configurations. Tailored trajectory tools are available for agent-specific scenarios. MLflow's tracing records the complete execution history and evaluates tool selection, plan quality, and efficiency. Established benchmarks such as AgentBench, tau-bench, and SWE-Bench provide benchmarks for comparison, though they focus more on overall capabilities rather than specific production tasks.

Quick reference

What each tool is actually for

Tool / benchmarkBest forCoverage
LangSmith / Braintrust / PhoenixEveryday LLM-app evals, CI integrationGeneral harness
DeepEvalPrebuilt evaluators, consistent scoring harnessGeneral harness
agentevalsTrajectory-specific scoring against a reference pathTrajectory specialist
MLflow (Agent GPA)Full trace capture, tool selection, plan qualityTrajectory specialist
promptfooCI-gated evals plus red-teaming for 50+ vulnerability typesRed-teaming / CI
AgentBench / tau-bench / SWE-BenchExternal capability benchmarks, not production-specificReference benchmark
SLIDE 09 : CATCHING SILENT REGRESSIONS
Production monitoring: per-turn classifiers and cost tracking catch silent regressions
Before it shows up as a support ticket

The initial indicator is typically a user grievance, unless you are observing.

A sudden improvement in task A may inadvertently disrupt task B. If the full test suite is not run with each release, these issues can go unnoticed until user complaints start to increase.

Inexpensive classifiers can quickly label production traffic in less than a hundred milliseconds, significantly more affordable than a complete LLM-as-judge call for each turn. These labels are then used to refine the evaluation set, improve data tuning, and optimize reward signals. By prioritizing cost-per-task and comparing accuracy to cost for each agent version, you can proactively address cost increases before they occur.

SLIDE 10 : EVALUATION AS A CONTINUOUS PIPELINE
Summary: treat agent evaluation as a continuous CI pipeline, not a one-time benchmark
The mindset shift that matters most

Shipping an agent without evals is shipping code without tests

A pre-launch benchmark run provides insight into the agent's performance on familiar tasks, but it may not accurately predict how it will handle unseen traffic, such as looping before responding, using the wrong tool before recovering, or leaving a user frustrated after multiple attempts.

Teams that prioritize agent reliability approach evaluation like experienced engineering teams approach testing: they use a valuable dataset that is executed with every pull request, as well as trajectory and component-level scoring in addition to the final result. They also implement production monitoring to detect any deviations before they escalate into a support issue.

Frequently asked

Agent testing & evaluation FAQ

An agent's ultimate solution may appear correct even if the journey to reach it involved wasteful, risky, or fortunate elements such as unnecessary tool calls, a serendipitous tool outcome, or a looping process that eventually resolved. Only when issues such as cost, latency, or reliability arise at scale does the impact of these factors become apparent due to output-only scoring.

Trajectory evaluation assesses the agent's path towards a solution by examining tool-call accuracy, step count compared to the minimum required, instances of looping or backtracking, and the agent's ability to recover smoothly from errors, instead of solely focusing on the final answer.

Calibration is necessary for dimensions that defy deterministic scoring, but it comes with biases favoring longer answers, sensitivity to answer position, and self-preference. Additionally, there is non-determinism and actual per-call cost involved. It is recommended to use it offline on a calibrated sample with a clearly defined 0-5 rubric instead of relying on it as an infallible tool for every production turn.

Begin with a selection of 50-100 meticulously chosen cases that encompass various scenarios such as successful paths, extreme cases, and anticipated failures. Gradually expand this collection by incorporating genuine production issues, with a target of reaching 500 cases or more by the end of the first quarter. Quality trumps quantity, as a hundred well-defined cases with specific expected outcomes are more valuable than a thousand generic, automatically generated ones.

Running the complete golden test suite on each pull request, monitoring cost-per-task and accuracy-vs-cost curves for each agent version, and utilizing affordable per-turn classifiers to label live production traffic and incorporating those labels into the evaluation set promptly rather than waiting for a support-ticket surge to uncover any issues.

Common benchmarks such as AgentBench, tau-bench, and SWE-Bench evaluate overall agent performance based on a predetermined task set, serving as a useful external benchmark. However, they may not accurately represent the demands of your specific production environment. To truly assess performance, it is crucial to utilize a customized dataset derived from your own tasks and observed failures.

Get started

Ready to build an evaluation pipeline for your agent?

Establish your five main metrics and thresholds, create a golden dataset with 50 cases by the end of this week, and integrate trajectory scoring into all pull requests prior to the next release.

Revisit trajectory evaluation → Back to the five dimensions