Agent reliability depends on the agent's capabilities, guard rails, and evaluation system.
2
Early intuition-based evaluation helps teams learn failure patterns before investing in a large, scalable eval.
3
Agent traces, explanations, and production data reveal why a system fails and help teams avoid fixing isolated, nondeterministic runs.
Summary
Preetika Bhateja and Daniel Bump describe how the YouTube Ads team built an evaluation workflow for an agent that turns messy advertising creatives into reusable assets. They argue that prompt changes alone do not make agent behavior stable. Teams first need focused tools, then a small evaluation that exposes what the agent can and cannot do. Human ratings, explanations, LLM judges, traces, and production data gradually make the evaluation more useful. The talk gives several practical warnings. Do not scale rating too early, do not test only successful task completion, and do not rewrite prompts around one failed run. The team found a disclaimer-removal failure by inspecting the agent's trace, even though aggregate pass rates did not explain it. Before launch, teams should understand regressions, compare patterns across examples, define launch gates, and keep golden and test sets updated as real use cases change.
Agent reliability depends on capabilities, guard rails, and evals
The speakers frame reliability as a combination of the agent's capabilities, its guard rails, and its evaluation system. Before running larger agent evaluations, teams should build a focused set of LLM-friendly tools and optimize those tools. An independent critique agent with a remediation loop can add self-correction when the base tools have gaps. Evaluation then gives the team a way to test whether changes add value and to run ablation experiments. This matters because generative systems are nondeterministic. The same agent can succeed on one run and fail on another, so teams need a measurable definition of the output they want at scale.
Early intuition-based evaluation helps teams learn the failure patterns
At the beginning, a comprehensive scalable eval can slow down learning. The team recommends looking directly at outputs and using intuition to identify obvious problems first. This approach is not scalable, but it makes the effect of prompt changes and architecture changes easier to see. It also helps the builders develop a detailed understanding of the agent's failure patterns. That knowledge later informs a more comprehensive evaluation. The speakers compare this phase to moving quickly before introducing scaled raters, since a large rating system can produce confusing ups and downs while the team is still changing the model and calibrating the eval.
A small eval should cover core tasks and negative behavior
Teams do not need a large golden set on the first day. They can start with a few primary tasks and expand the representation over time. The evaluation should also test whether the agent avoided harmful actions, rather than checking only whether it completed the requested task. The speakers describe this as testing the negatives. For example, an agent may produce an apparently successful output while removing something it was required to preserve. As more teams join the project, the dataset can grow to include more use cases, scale raters, and LLM raters. Early human agreement on what counts as a pass gives that larger process a clearer basis.
Rater explanations are more useful than pass or fail alone
A pass or fail label does not tell the team how the agent should improve or why a rater reached the decision. The speakers recommend clear rubrics, concrete examples, and written explanations from human raters. This applies to single-output evaluations and side-by-side comparisons. It also matters when an output has several dimensions. In the advertising case, raters assessed accuracy, brand safety, and whether the result matched expectations. An output could do well on brand safety while failing accuracy. Explanations expose that distinction and give the team information it can use to improve the agent, rather than collapsing different problems into one score.
The team also used LLM or automated raters. One practice was to monitor disagreements between an expert or human rater and the LLM judge through a sampling pipeline. Agreement trends show whether the automated judge is behaving within an expected range. The speakers also recommend spot-checking the reasoning behind pass and fail decisions instead of trusting the label alone. A broad golden set with strong human agreement gives the judge better ground truth. The set should cover a wide range of use cases. This calibration process is described as an ongoing monitoring task, rather than a one-time setup.
Trace inspection can expose failures hidden by aggregate scores
The team found an important failure by reading an agent trace. The prompt repeatedly told the agent that legal disclaimers could never be removed. In an edge case, the agent detected a disclaimer in an advertisement and then decided to remove it anyway. A categorical pass rate did not explain this behavior. The trace showed the incorrect reasoning directly. The example image was a public parks advertisement with the text "Paid by the Community of Parks of Keep Parks Clean" in the bottom right, and the agent removed that disclaimer. Looking at the agent's reasoning helped the team identify what had gone wrong instead of seeing only a final failure label.
Eval and agent changes should form a quality hill-climbing loop
After human evaluation, teams can review the eval set, examine measures such as precision and recall, adjust the rating guide, change the eval, or modify the model, agent, and tools. These changes happen together in an iterative loop. A well-defined eval makes it possible to compare versions and run ablations. Before launch, the team also needs to understand regressions and why performance degraded. That analysis separates acceptable trade-offs from critical failures. The speakers warn against reacting to one isolated run because agent outputs are nondeterministic. Teams should look for recurring patterns across multiple examples in the golden set and invest in online evaluations whose data matches real production behavior.
Production evals need evolving data and explicit launch gates
A useful eval should match what the product needs to do well at its current stage. An MVP and a production rollout may require different evaluation sets. The system should evolve through online evals, test sets refreshed with production data, sampling pipelines, and curated golden sets that change with the use cases. Rating teams also need training, templates, rubrics, and examples so that fewer cases are marked as unknown. Finally, teams should decide early what blocks launch. That might be a precision or recall threshold, or another metric suited to the model. Launch readiness includes repeated model iterations, A/B differences or ablations, and an explicit decision about which regressions are acceptable.
"The reliability of your agent is basically a function of the capabilities of the agent, the guard rails and the evals."02:35
Who should watch
You are building an agent and need an evaluation process before expanding it to more users or teams.
Your pass rates look acceptable, but you still do not know why individual outputs fail.
You are deciding how to combine human ratings, LLM judges, traces, test data, and production monitoring before launch.
