Eval-Driven Development replaces subjective iteration with hypotheses, experiments, measurements, and decisions.
2
Agent evaluation should begin with end-to-end metrics and a small number of strong proxies tied to user goals.
3
Quantitative evaluation shows which cases fail, while error analysis and attribution analysis explain how to fix them.
Summary
Shahul presents Eval-Driven Development as a practical way to improve AI agents through experiments instead of subjective "vibe checks." He recommends starting with end-to-end metrics that reflect what users want, such as execution accuracy for text-to-SQL agents or goal success for conversational agents. Teams should prefer a few strong proxies over many weak measures such as helpfulness or coherence. Quantitative evaluation also covers consistency, cost, and latency, while qualitative evaluation explains why failures happen. Shahul describes error analysis, which labels failed outputs, and attribution analysis, which traces those failures back to particular tools, retrieval steps, memory mechanisms, or reasoning steps. He also explains how to align an LLM judge with human reviewers through prompt iteration, reviewed examples, and feedback. The talk ends with a preview of Ragas features for running experiments, storing results, and managing custom metrics across teams.
Eval-Driven Development gives teams a shared way to improve agents
Shahul contrasts Eval-Driven Development with iteration based on personal feeling. Vibe-based changes can look better to one person and worse to another, which causes problems when several engineers and stakeholders work on the same agent. His proposed loop follows the scientific method: form a hypothesis, test it, validate the result, and act on the evidence. A defined goal and agreed measures make it possible to discuss whether a behavior improved without relying on individual impressions.
Agent evaluation needs quantitative measures for performance and operations
Shahul separates quantitative evaluation into performance metrics, consistency, cost, and latency. Consistency can be measured by running the same agent on the same task repeatedly and comparing the results. For natural-language answers, this can involve an LLM judge or semantic similarity. Cost and latency apply to agent development and operation in the same way they apply to other systems, so they belong in the evaluation process even when the main focus is answer quality.
End-to-end success is usually a stronger measure than several generic quality scores
Shahul recommends beginning with end-to-end evaluation because it measures the whole system, which is what users ultimately experience. He warns against combining many weak proxies such as helpfulness, tone, coherence, and relevance. A text-to-SQL agent can instead be measured by whether its query produces the same output as the ground-truth query. A conversational agent can use goal success, while a deep research agent can use a judge with grading notes and a rubric.
An LLM judge needs to be aligned with human judgment
Using an LLM to evaluate an agent does not make the evaluation automatically reliable. Shahul says the judge should correlate with human annotations and understand the boundary between acceptable and unacceptable behavior. Teams can tune the judging prompt, add few-shot examples, and use another LLM to help improve the prompt. He recommends reviewing the judge's results on test data and feeding corrections back into the evaluation process. Dynamic retrieval of examples is another technique he mentions for improving alignment.
Quantitative scores show failure rates but do not explain failures
An end-to-end score can reveal that an agent failed 20 out of 100 samples, but it does not explain what happened in those cases. Shahul treats the failed samples as material for qualitative evaluation. The goal is to turn them into actionable findings. This distinction matters because a team cannot reliably change the system based only on a percentage. It needs to know whether the problem came from an incorrect answer, a reasoning mistake, a hallucination, or misuse of a tool.
Error analysis labels what went wrong in the final output
Error analysis starts by inspecting failed samples and recording the visible problem. For a deep research agent, an engineer might find that the report lacks depth or contains vague information. The review can also identify the stage where the failure appeared, such as a tool-calling step or a reasoning step. Shahul describes this as manual inspection that produces hypotheses about recurring failure types, which can then guide changes to the agent.
Attribution analysis traces a bad result back through the agent's steps
Agent failures are harder to debug because an autonomous system may take many steps before producing its final answer. Attribution analysis connects the observed failure to a component or sequence in that chain. Shahul lists possible causes such as faulty memory, bad retrieval, or incorrect tool use. In his shipping example, the agent used a math tool instead of a shipping lookup tool because the word "calculate" triggered the wrong function. That finding gives the next iteration a specific behavior to test.
Experiment management makes evaluation part of every iteration
Shahul describes an upcoming Ragas release built around datasets, experiments, and metrics. Teams can keep datasets in places such as a local file system, Google Drive, or Box, then associate an evaluation script with a project. After a change, the script can run locally or from the cloud, fetch the dataset, execute the evaluation, and store results for other team members to review. The release also addresses custom metrics, including their reuse and retrieval across projects.
Long agent traces make attribution expensive and difficult
In the question session, Shahul is direct about the limits of the method. Browser agents can produce traces with hundreds of steps, making it difficult to connect a known error to one part of the reasoning chain. He says attribution analysis for browser-use agents has sometimes taken him close to 30 minutes, especially when the agent runs for several minutes and produces hundreds of logs. The process can become tedious, and he says making it easier is an area of ongoing work.
"So if I look further or do some more analysis to understand where does this come from? I could understand that the word calculate actually triggered the math calculate function."18:49
Who should watch
You are building an agent and keep making changes without knowing whether the overall user experience improved.
Your team has an end-to-end score but needs a repeatable way to diagnose tool errors, retrieval failures, hallucinations, or reasoning mistakes.
You are setting up LLM-based judges and want a process for checking them against human reviewers.
