Evaluating an AI agent means checking whether it completes a clear user goal across the full run—not just whether its final answer sounds convincing. A practical workflow starts with a defined user journey, then tests realistic scenarios, reviews execution traces, controls run-to-run variation, and carries production findings into regression tests. Google’s evaluation guide, published October 15, 2026, lays out that progression.
A repeatable evaluation workflow
Use the stages as a connected process: define what success means, exercise the agent, inspect how it got there, and preserve the resulting checks so later changes can be compared against the same baseline.
1. Define success as a user journey
Start with a critical user journey (CUJ): a specific person’s goal, the constraints they face, and the conditions that would count as success. Turn each condition into a check. That makes it possible to catch an agent that produces a polished answer after missing a required tool call or skipping a necessary verification.
For example, Google’s guide sketches an operations analyst who must identify a disputed transaction, check its economics against an internal ledger, and translate internal trade IDs into a broker’s terminology. Each action becomes a separate evaluation point. The scenario illustrates how to define checks; it is not a reported result from an agent test.
2. Simulate scenarios, then inspect traces
Create a happy path and edge cases before relying on production traffic. A simulated user can provide incomplete details, make a typo, or respond over several turns. Those variations help expose where an agent asks for clarification, uses a tool incorrectly, or loses track of the goal.
Then review execution traces: records of the prompts, intermediate steps, tool arguments, and outputs associated with a run. Google recommends inspecting traces manually before turning observed failure patterns into automated checks. That order matters: a test is more useful when it targets a real failure mode rather than a guess about what might go wrong.
3. Make repeated runs comparable
One successful run may not tell you much when an agent’s path can vary or its external data changes. Braintrust recommends running multiple trials for each task and controlling dependencies with tools such as stubbed services or snapshot data. A stub stands in for a service; a snapshot preserves a known set of data. Both can help separate changes in the agent from changes in the systems it depends on. Braintrust also describes sandboxed simulations and fault injection, such as introducing timeouts or malformed responses, to exercise recovery behavior in a controlled setting.
Keep the task and conditions steady while comparing runs. Braintrust does not specify a universal number of trials; choose a repeatable approach that fits the task and record the conditions so the comparison remains meaningful.
4. Combine checks and calibrate LLM judges
Google groups evaluation checks into four complementary types: unit tests for individual components, deterministic metrics with fixed outcomes, rubrics scored by an LLM judge, and integration tests across connected parts of the system. No single score explains every failure. A tool-call check, for instance, answers a different question from whether the final response meets the user’s goal.
Where a judgment can be expressed clearly, Google recommends a yes-or-no rubric question rather than a fuzzy 1-to-5 rating. Compare automated judge scores with manually reviewed traces, too. That gives you a way to spot cases where the grader passes behavior a person marks as a failure.
IBM Technology presenter Zahra Ashktorab describes three possible LLM-judge biases: positional bias, in which the order of answers affects the choice; verbosity bias, in which a longer answer gets favored; and self-enhancement bias, in which a model favors an answer it generated. Swapping the order of two candidate answers can probe positional bias: if the judgment changes when their positions switch, the order may be influencing the result. That probe addresses position, not the other bias types.
5. Keep a stable baseline and gate regressions
Freeze the “golden” dataset—the fixed set of evaluation cases—while tuning the agent. If you change the test set at the same time as the system, a new score can reflect either change. Google also recommends changing one variable at a time and checking the same cases again.
Track operational behavior alongside answer quality: latency, prompt, reasoning and completion token use, API cost, and tool-call counts. These measures can reveal a costly or slow run even when its answer passes. For continuous integration and continuous delivery (CI/CD), Google proposes combining an overall pass threshold with a block on regressions in core metrics. The guide’s 95% threshold is an example, not a universal bar; teams need criteria that fit their own requirements.
When a human reviewer and an automated evaluator disagree, a Reddit discussion offers a practical suggestion: record the resolution and its rationale, clarify the scoring rule, and add the disputed case—along with contrasting examples—to regression tests. That gives future runs a clearer rule to apply and preserves the disagreement as a test case.
6. Feed production findings back into tests
Offline tests run against a controlled dataset; online evaluation examines live interactions. Microsoft describes using findings from production evaluation to update offline test data. Google likewise recommends turning missed production edge cases into new cases in the golden dataset. The loop lets the test suite evolve with real usage while keeping its existing cases available for comparisons.
Google’s guide also says its agent-eval approach standardizes OpenTelemetry traces using OpenInference conventions and supports Google ADK, LangGraph, and custom runtimes. That gives teams a stated route to evaluate traces across those frameworks without tying the evaluation process to one orchestration framework.
