Useful evals let a team respond to user complaints, assess new use cases before launch, and ship a new model within 24 hours.
2
Evals need ongoing engineering: real user data, custom scoring functions, and context designed around what the model needs to see.
3
Teams should optimize the full evaluation system and keep their architecture flexible enough to benefit when a new model changes what is possible.
Summary
Ankur Goyal argues that evals should guide product development rather than merely catch regressions. A useful eval system lets a team turn user complaints into selected test cases, judge whether a new feature is viable, and test a new model quickly. The datasets need to be reconciled with real user behavior over time, while scoring functions should express the product's own specification instead of relying only on generic scorers. Goyal also says prompt engineering now includes the full context sent to an agent. Tool definitions and tool outputs can dominate the model's token budget, so they need to be designed for the model rather than copied directly from existing APIs. Finally, teams should optimize data, tasks, tools, prompts, and scores together. His examples show that a new model can make an ambitious feature viable, provided the product and eval architecture can change quickly.
Useful evals make model updates and user feedback actionable
Goyal gives three signs that an organization is getting value from evals. When a new model appears, the team should be able to incorporate it into the product within 24 hours, as Notion has done for several releases. A user complaint should have a clear path into the eval set so the team can test and improve the problem instead of losing the information. Evals should also help the team decide which use cases it can solve before shipping. They should provide an estimate of how well a new product might work, rather than only checking for regressions after the fact.
Goyal says synthetic datasets and random LLM-as-a-judge scores do not produce great evals by themselves. For most real-world tasks, a dataset created in advance will not match what users actually experience. The useful dataset is one the team can continuously reconcile with reality as new cases appear. That makes dataset design an engineering problem. He contrasts this with narrow tasks such as solving competition math problems, where an existing dataset may already align well with the use case. The team must keep refining its tests as it learns what users are trying to do and where the application fails.
A scoring function is a specification for the application
Braintrust has an open-source library called AutoEvals, but Goyal says sufficiently advanced companies write and continually modify their own scoring functions. He compares a score to a specification or product requirements document for an AI application. A generic scorer encodes the requirements of someone else's project, so it cannot fully describe the behavior a particular product needs. This is why scoring deserves deliberate investment. The score should capture what good performance means for the application, including the cases the team has learned from real users.
Goyal says modern agent prompts contain much more than a system prompt. An agent usually loops through model calls, tool calls, tool results, and new iterations, so most tokens in an average prompt may come from sources other than the system instructions. Tool definitions and outputs therefore need careful design. A tool should be shaped around what the model needs to see, rather than exposed as a direct reflection of an existing API. In one internal project, changing a tool output from JSON to YAML made a significant difference because YAML was more token-efficient and easier for the model to analyze. The same structured data formats are not equivalent from the model's perspective.
New models can turn an impractical feature into a viable one
Goyal recommends building ambitious evals for use cases that current models may not handle yet. Braintrust had an eval for a feature that remained impractical at about 10 percent performance. GPT-4.1 improved on GPT-4o, Claude 3.7 Sonnet improved further, and Claude 4 Sonnet crossed the threshold that made the feature viable for users. Claude 4 Sonnet had launched two weeks earlier, and the team was shipping the first version of the feature at the time of the talk. Because the eval already existed, the team could test the new model and act on the change quickly.
Model-agnostic infrastructure makes model comparisons cheap
Goyal says teams should be able to plug new models into their evals without changing application code. Braintrust's Braintrust Proxy is one way to work across model providers, though he says similar tools can be used. He mentions testing models from OpenAI, Anthropic, and Google, along with the possibility of testing a company's own model or a fine-tuned model. The point is to make model comparisons routine. A new model may reveal that an ambitious feature now works, but the team can only learn that quickly if the application can switch providers and run the existing evaluation.
Prompt optimization should include data, tasks, tools, and scoring
Goyal describes an experiment that optimized a prompt in two ways. In one run, an LLM received only the prompt and was asked to improve it. In another, it received the prompt, dataset, and scores and was asked to improve the whole system. The second approach produced a dramatic difference, moving the example from unviable to viable. Braintrust's Loop feature is designed around this workflow. It can work with a prompt, dataset, and scores, then suggest changes such as missing test cases, reasons for high or low scores, or a harsher scoring function. Goyal expects this to reduce some of the manual work in eval iteration.
In the question period, Goyal addresses the risk of overfitting when user feedback becomes part of an eval dataset. He says he is more worried about fitting to a dataset that excludes user feedback than about updating it to reflect reality. Braintrust does not automatically add every user comment to a dataset. Instead, a person with judgment about the product selects interesting cases. A thumbs-down signal may mean the answer is wrong, but it may also mean the user dislikes a correct answer. The human reviewer can decide whether a case describes behavior the product should support and add it to the dataset.
"The most important thing about a data set is not the state of the data set at any point in time. It is how well you are equipped to reconcile the data set with the reality that you want."15:12
Who should watch
You are building an AI product and your evals only run after a feature is already in production.
Your team needs to turn user complaints into test cases and decide whether a new model makes an ambitious feature viable.
You are exposing existing APIs as agent tools and need to understand why tool schemas and outputs affect model performance.
