# Your Agent Evolved. Your Evals Didn't. Ameya Bhatawdekar, Braintrust | AI Engineer World's Fair 2026 | 24:13 Source: https://www.youtube.com/watch?v=nxokqOq1imY Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/your-agent-evolved-your-evals-didnt Published: 2026-08-20 Tags: agents, evals, reliability, workflows ## TL;DR - Model improvements arrive as step changes that often require teams to rearchitect their AI systems instead of swapping in a new model. - Each architectural generation creates new failure points, so evals must cover parsers, retrieval, orchestration, node contracts, retries, and peripheral components. - For agents with variable trajectories, pass at k measures capability while pass^k measures reliability, and production data must keep expanding the eval set. ## Summary Ameya Bhatawdekar describes five generations of AI application architecture, from a single prompt through chains, ReAct loops, workflow graphs, and newer agent systems with memory, sandboxes, MCP, and skills. Each model capability shift changes what the application can do and what can go wrong. Older systems often contain workarounds for model limitations, so adopting a stronger model usually requires rearchitecting rather than replacement. Evals have to move with those changes. A simple answer-quality eval is insufficient once parsing, retrieval, branching, node contracts, retries, and external components enter the system. For agents that can reliably loop, repeated runs can produce different trajectories for the same input. Bhatawdekar separates capability from reliability with pass at k and pass^k. He argues that production data should continually update evals, including through clustering that finds failure modes the team did not anticipate. ## Key ideas ### Model progress forces replatforming because old systems encode old limitations [02:08](https://www.youtube.com/watch?v=nxokqOq1imY&t=128s) Bhatawdekar says recent model releases have introduced major capabilities in tool use, long context, code execution, and memory. These are step-function changes rather than small improvements. Earlier applications were built around limitations such as weak tool calling, so dropping in a new model does not automatically expose its capabilities. Teams have to restructure the application architecture, then update the evals that define reliable behavior. His sequence is direct: models change, architecture changes, and evals must follow the architecture. ### A single model call needs an eval focused on the final answer [05:34](https://www.youtube.com/watch?v=nxokqOq1imY&t=334s) The earliest application pattern was one input, one model call, and one output. Evaluation could therefore focus on answer quality. Teams checked accuracy, factuality, hallucinations, and whether the model relied on outdated knowledge instead of current information. A golden dataset and scores encoding what good looked like were enough to get started. Bhatawdekar calls this approach narrow because there was no retrieval, tool calling, or orchestration to inspect. ### Retrieval chains add failure points before the answer is generated [06:40](https://www.youtube.com/watch?v=nxokqOq1imY&t=400s) A typical retrieval-augmented chain parses information from the user input, retrieves material, builds context, and passes it to the model. The final answer still matters, but earlier steps can fail independently. The parser may extract the wrong information, the retriever may return the wrong context, or the model may struggle to reason over a large context window. Context stuffing was a particular problem for early models. Evals therefore had to inspect more than the generated answer, even though the chain still followed a fixed sequence. ### Early ReAct loops gave models flexibility before they could control themselves reliably [08:12](https://www.youtube.com/watch?v=nxokqOq1imY&t=492s) The ReAct pattern put a model in a loop where it could reason, call a tool, inspect the result, and choose the next step until the user intent was satisfied or the iteration budget ran out. This removed the rigid workflow and let the model organize its own actions. Models in that period often called the wrong tools, supplied bad arguments, struggled with orchestration, and lost track of long context. The idea was attractive, but those limitations kept it from delivering the intended reliability. ### Workflow graphs restore predictability by moving orchestration into the application [09:42](https://www.youtube.com/watch?v=nxokqOq1imY&t=582s) When models could not reliably orchestrate, teams built graphs or state machines that controlled planning and execution. Models operated inside individual nodes while the surrounding system selected the path. This improved reliability and predictability for known intents. It also made the system brittle outside the distribution it was designed for. Teams added special branches and handling for more intents, increasing the complexity of the graph and creating more places where behavior could fail. ### Graphs expand eval coverage from the final result to the whole execution system [11:18](https://www.youtube.com/watch?v=nxokqOq1imY&t=678s) A graph introduces failures in branch logic, consistency between branches, contracts between nodes, and nodes built for narrow use cases. Classifier nodes can silently choose the wrong path. Retry loops and other complex behaviors also need checking. Bhatawdekar says evals must cover the overall orchestration as well as individual nodes. The evaluation surface grows because the application now contains explicit control logic that did not exist in the single-call design. ### Stronger models make free-running loops practical again, but trajectories vary [13:07](https://www.youtube.com/watch?v=nxokqOq1imY&t=787s) Bhatawdekar points to newer capabilities from Anthropic and OpenAI, including more reliable tool calling, better planning, long-horizon task handling, and course correction. These improvements allowed teams to use reliable model-driven loops again, making some graph-based systems unable to take advantage of the newer behavior. The same input can now produce dramatically different trajectories across runs while still reaching the correct answer. That variance changes what one eval run can tell you about the system. ### Pass at k measures capability while pass to the k measures reliability [15:00](https://www.youtube.com/watch?v=nxokqOq1imY&t=900s) For a repeated eval, pass at k asks whether at least one of k attempts succeeds. Bhatawdekar treats that as a measure of capability. The stricter pass^k measure asks how many of the k attempts succeed, which gives a view of reliability. A system can succeed on at least one attempt while failing often across the rest. Running the same case repeatedly exposes that difference and gives a better signal than judging a single trajectory. ### Production data keeps evals current as agent systems gain peripheral components [16:13](https://www.youtube.com/watch?v=nxokqOq1imY&t=973s) Newer agent products add memory across and within sessions, code execution sandboxes, MCP, and skill directories. Reusing an eval from an earlier generation gives only partial coverage because these components create new ways for the system to fail. Bhatawdekar argues that teams need a production-to-eval flywheel. Braintrust's Topics feature clusters production data to surface failure categories the team did not anticipate, helping expand datasets beyond known failure modes. ## Notable quotes - "Architecture follows model updates and your evals have to follow your architecture." (04:01) - "What do you do when your model can't be controlled? You take the control and you bake that control into the system that you're building around the model." (09:42) - "Pass at K is like if you take that eval and you run it K times, does it succeed at least once, and that is a measure of its capability." (15:22) - "Ultimately it's the evals that are sort of your durable asset that describe how your system is supposed to work." (18:00) ## Tools & references mentioned - Braintrust - Anthropic - OpenAI - ReAct paper - MCP ## Who should watch - Your agent has moved from a chain or graph to a model-driven loop, and one result per test case no longer describes its behavior. - You are replacing models and need to decide which old workarounds, branches, and node-level checks still belong in the application. - Production failures keep exposing cases that your static eval set never covers.