How to Evaluate Your Agents From First Benchmark to CI/CD

Summary

Most agents fail to reach production because teams rely on informal 'vibe checks' rather than structured benchmark datasets, LLM judges, and measurable quality gates that can detect regressions before they reach users.
MLflow serves as the evaluation backbone connecting production traces, custom scorers, and CI/CD pipelines—enabling automated regression gating in GitHub Actions so quality issues are caught before deployment.
This video walks through building a high-quality evaluation dataset from production traces, creating custom scorers aligned to business requirements, and implementing online monitoring to detect drift in deployed agents over time.

How to Evaluate Your Agents From First Benchmark to CI/CD

If your team is building agents, evaluation is the difference between a demo that works and a product you can actually rely on. But most teams don't know where to start — which metrics matter, how to build a benchmark, how to automate tests, or how to catch regressions before they reach users.
In this how-to session, we walk through agent evaluation end-to-end: defining your first benchmark, choosing the right judges and metrics for your use case, automating evaluation across prompts and workflows, and building a CI/CD loop that catches regressions before they hit production. We'll share practical patterns from real production teams and show how MLflow ties it all together.
You'll leave with a concrete playbook for evaluating agents from first test to continuous quality at scale — and the confidence to ship agents that keep getting better with every iteration.
Talk By: Max Fisher, Lead Solutions Architect, Databricks ; Wenwen Xie, GTM Staff Software Engineer, Databricks ;

Chapters

FAQs

Why do so many AI agents fail to make it from experimentation to production?

This video argues that the core issue is the absence of structured evaluation—teams rely on informal vibe checks rather than defined benchmarks, quality metrics, and automated regression testing. Without a repeatable evaluation process, agents that work in demos fail unpredictably in production, eroding trust and ROI.

How does MLflow support agent evaluation on Databricks?

MLflow acts as the evaluation backbone by capturing traces from production or test runs, storing scores from custom and built-in judges, and integrating with CI/CD pipelines to gate deployments. This video demonstrates automated evaluation in GitHub Actions where a failing quality threshold blocks a release before it reaches users.

How do you build a high-quality evaluation dataset for agent testing?

This video recommends building evaluation datasets from real production traces, then applying structured human feedback and evaluation rubrics to label expected outputs. A calibrated LLM judge is trained and validated against this human-labeled dataset to enable scalable automated scoring.

What is online monitoring in agent evaluation and why does it matter?

Online monitoring continuously evaluates agent responses in production against quality benchmarks, detecting drift when user behavior, underlying data, or model behavior changes over time. This video presents it as the final layer of the agent quality lifecycle, ensuring that agents that pass pre-deployment tests continue to perform reliably after release.

Full transcript

[00:08] Good afternoon everyone. Thanks for joining us at Data and AI Summit. We're excited to have you here. My name is Vivian and I'm joined by my colleague Max. Today we're going to talk about one of the most important challenges in
[00:22] agentic AI. Not how to build agents, not how to prom agents, but how to trust agents. We're going to walk through a practical journey we've seen repeatedly across
[00:36] customer engagements from your first benchmark all the way to pipeline evaluation and CI/CD. We'll start by talking about some concepts and
[00:48] frameworks around agent evaluation and then we're going to show you a practical workflow backed by our mosaic research team to build trusted agent and we will
[01:00] share a QR code. So stay tuned for that and then later Max is going to bring everything into life with a live demo. So if you are someone who loves to see
[01:13] practical implementation definitely stick around for that lab demo and he will show you how everything works together in a real CI/CD workflow. So
[01:25] with that let's get started. First let me introduce my ourselves. I'm Vivian. Um I'm a GTM staff software engineer. Before that I was a specialist solutions
[01:37] architect helping customer build enterprise largecale AI system and agent applications. Max. >> Hey everyone, my name is Max Fischer.
[01:49] I'm a lead solution architect here at data bicks. I've been here for about six years and I help lead a lot of our AI enablement activities in our communications, media, entertainment and gaming division. All right. So, uh,
[02:04] green is forward. There we go. Perfect. There we go. Okay. So, the main question we're going to pose and ultimately answer today is why aren't agents making to production? You know, we hear a lot
[02:16] of headlines around how organizations aren't getting the ROI out of the investments they're making in agentic projects and a lot of agents don't really make it out of the experimentation phase. And we believe a
[02:29] lot of it has to do with the fact that we haven't made sort of the process changes we need to move from the old world to the new world we live in today. So the old world when I say the old
[02:41] world is the world of classical machine learning and you know it's still a very relevant world today. So power so much of the systems that we use today. But uh in that world we had a slightly more
[02:53] cleaner kind of implementation of what our release management process for machine learning looked like. Uh now in some organizations this did look like data scientists sort of just tossing models over the proverbial brick wall to
[03:07] our poor MLOps engineers. But generally speaking it was okay. We developed decent team data science processes to make sure uh we saw real value out of the regression models, the forecasting
[03:19] models, the uh recommendation models that we were building. Now, uh the problem sort of started to begin when everyone got access to the ability to create agents. So before before coding
[03:33] agents really have this right now anyone any grandma and I guess if you give your dog a open AI subscription they're all now building agents right and this is a problem because this is overwhelming to
[03:45] our compliance teams our quality teams our ops teams those poor ops engineers who are now crying and underweight of all the agents uh they don't know what to do and it creates two really distinct problems right one is uh across all
[04:00] these agents that are being developed, how do we define quality? And then two, how do we integrate that definition of quality into the release management process to ensure we can continuously improve our agents, but also prevent bad
[04:12] agents or bad changes from making it to production. So we're going to tackle that in two phases and Vivian will take kind of the first uh uh first phase where we're going to talk about how do we build that trust and confidence in
[04:24] the AI systems we we seek to continuously improve and you know um with with benchmarks and evaluations and judges and then I'll talk more about how we integrate all that effort into the
[04:36] release management process to ensure we can continue that uh improvement cycle. >> All right. So in the first half of the session we're going to focus on evaluations and then judges. We're going
[04:50] to talk about how team typically start evaluating agent, how to build your first benchmark, how to think about metrics and ultimately how to build judges that you can trust and like most
[05:03] journey this one starts in familiar place. It starts with what I call web checks. Almost every agent project starts with web tracks. You build something, you try
[05:15] a few prompts, you show it to your teammates, and someone says, "Oh, that looks pretty good." And honestly, there's nothing wrong with it. A web checks are fast. They're cheap. They help you develop intuitions around
[05:27] system, how system behaved. You start understanding where it succeeded, where it failed, and what kinds of failures make sense to you. But the the mistake isn't starting with backtracks. the
[05:40] mistake it's staying there because eventually intuitions stop scaling. So you need to move from intuitions and opinions into evidence and that all
[05:54] start with defining failures. When team talks about you know uh agent quality they often use broad statement like oh the agent isn't reliable but that's very hard to act on. Instead,
[06:08] what you need to do is you need to specify specific failure modes. Did the agent choose the wrong tool? Did it fabricate the arguments? Did it reject the user request it should have handled? Or did
[06:21] it uh ignore user constraint? And uh once you can name these failures, you can measure it. And once you can measure it, you can improve it. Those failures
[06:34] become the foundation for your first benchmark. So when teams think about starting building benchmark or evaluation data set, one of the first question they often ask is how big does
[06:46] it need to be? And in practice, quality ma matters much more than quantity. A small evaluation data set that captures your most important failure modes is far more valuable than a large data set
[07:00] filled with general examples. The goal isn't to build the biggest data set. The goal is to build the right data set. So where should the data come from? The best source would be your production
[07:14] traces. Nothing represents your user better than the real real world user behavior, right? And this if you don't have uh production traffic yet, then
[07:26] your second best source would be your theme authored adversarial examples. So ask your domain expert to create some difficult cases. Third, synthetic data
[07:38] is fine. They can fill some gap, but it shouldn't be your primary source of truth because you can evaluate your agent against artificial scenarios instead of real world behaviors.
[07:51] Once we have the data, we need to decide what to measure. And one common mistake is trying to summarize the agent with aggregate accuracy score. And this is very different than the machine learning world, right? Because the problem is
[08:04] that agent has multiple layers. The retrieval can fail, tool call can fail, generation can fail and end to end execution can fail. A single score tells you something is wrong, but it doesn't
[08:17] tell you why. So that's why we recommend measuring each layer independently. Once you have you have defined your scores, you need a system to help you
[08:29] operationalize and run those evaluations. And at data bricks, we use MLflow as a backbone for evaluation cycle. So you bring your data sets, you define your
[08:41] scores. MLflow runs the evaluation and more importantly MLflow connects everything together. your traces, your data sets, your evaluation score, deployment, monitoring, monitoring and
[08:54] ultimately CI/CD all live in one workflow. That's what allows evaluation to scale. So let's take a look at a actual you know example of how uh ammo
[09:07] flow evaluation runs right like if you can see here notice that it's not producing a single aggregate score instead we are evaluating each example
[09:19] individually and because every result is linked to traces you can quickly understand if some not only something goes wrong something failed but why it failed.
[09:31] And as I as I mentioned earlier, your best source of evaluation data set is your production traces. And you can use MLflow, you can use production traces as
[09:43] evaluation data set and then run MLflow evaluation on top of it. Your production traces contain your user interaction. So you don't have to manually craft all these test cases and uh you can just
[09:58] reuse products as evaluation data set right that gives you a much tighter uh loop between you what users experience and what you're trying to measure.
[10:11] And of course every organization defines quality a little bit differently. That's where custom scores become important because you you may care about factual correctness. The other person may care
[10:23] about compliance and there are all kinds of scores that different people may care about. The key idea is that evaluation should uh should rely on your business
[10:37] reflect on your business requirements not generic examples. And once we have we run this evaluation, it's time to check the results. We need to understand the results, right? That's
[10:51] where the evaluation become actually actionable. We can compare versions side by side. We can investigate traces, investigate failures, identify
[11:03] bottlenecks. The goal isn't and also the goal isn't just to score the system because we want to improve the system and we need to figure out ways to to you know discover like the root cause or
[11:17] identify failures and figure out how to improve the agent at the end of the day right and here I'm going to show you something that is going to scale your evaluation
[11:30] beyond the engineers and make them super accessible to your domain expert to your business users because in many cases the people who understand uh business use
[11:42] case best are your domain expert and they don't necessarily need to write code for evaluation. So genie code helps these uh domain experts to participate
[11:55] directly in the evaluation process just using prompt right. So here you can see that G they can use Genie to uh prompt the agent and ask the agent to tell them to identify uh root causes, investigate
[12:10] failures and inspect traces and identify bottlenecks all of the things. So the goal is really help you to move from intuitions and opinions to measured quality. Right? So I highly recommend
[12:24] use Genie code. All right, that bring us to the next really important topic which is judges you trust. So as evaluations scale
[12:37] eventually humans become the bottleneck. That doesn't mean that humans are not important. They're still super important and they should always be like in the loop. But this just means that we need
[12:49] AI judges. We need LLM judges, right? And that also raises a immediate question. Can we always trust LM judges? The answer is not always because
[13:02] offtheshelf judges they can perform reasonably well on generic examples but when you move into specialized domain their limitation become much more uh
[13:15] visible. Right? A judge might look great with accuracy but still missing important nuances that matter to your business. That's why alignment and the calibration of your judges are so
[13:28] important. So, how do we build judges that reflect our actual business requirements and definitions of quality? To build trustworthy judges, first we
[13:41] need to align them with what success looks like, how we define success, right? Different applications have different definitions of quality. For rag system, we may care about groundness
[13:54] and effectual correctness. For tool calling agent, we may care about tool selection and argument accuracy. For customer support agent, we may care about uh policy compliance and uh
[14:06] resolution quality. All sorts of things. So the important thing to remember here is that there is no universal scorecard. Judges should reflect the risks and
[14:18] priorities of your application. And to define priorities, we need input from people who understand the business best. And usually the source of truth is your
[14:31] domain experts. And this is where human needs to be in the loop. They understand what a good answer looks like. They understand the edge cases. they understand what actually means matters
[14:43] to the users. So the feedback becomes a foundation for building and validating judges without labels or human feedback. human feedback you literally uh developing judges you
[14:57] your you judge development process turn into guess work right so let's look at how we help uh how we collect that human feedback and this is a workflow this is also our product like am flow review app
[15:11] for collecting structured human feedback experts can review traces they can evaluate responses and provide annotations the goal isn't simply only
[15:23] just collecting opinions through across these iterations. We want to make sure we create consistent and repeatable definitions of quality, right? Whether you know this agent is correct or is the
[15:36] answer following the correct format. And this evaluation criteria rubric should reflect what your business actually need. And those and we collect these labels from human and those labels
[15:50] become the benchmark that our judges are going to be measured against. And once we have this labels, we can compare humans and the judge directly. And this
[16:02] is where things get interesting. When humans and the judges agree, that's great. That's a good sign. But when they disagree, this is actually where your biggest insight come from. Those
[16:14] disagreements tell you where your rubric is unclear, where your judge is weak and where you need to refine your evaluation criteria. So in many cases, disagreement
[16:27] analysis become one of the most valuable parts of the entire evaluation process. All right, I have talked a lot about that. Uh so how do we systematically
[16:40] improve judge performance and this is going to become the workflow uh I'm showing you? The answer is calibration. We compare judge outputs against labels.
[16:52] We investigate disagreements. We refine the rubric. Then then we repeat the process. The goal isn't necessarily perfect agreement. The goal is building judges that behave consistently and
[17:06] reflect what your theme how your theme think about quality and over time this becomes a repeatable workflow which we call vigaler. This is something that we
[17:18] run in the field that help customer to scale their evaluation. And as you can see this process we start we uh what we do is we putme domain subject experts
[17:31] and the developers in the same room and then we collect discoveries and uh analysis from them and we build rubrics and then we uh refine those rubrics you
[17:44] know through like rounds of uh disagreement analysis betweenmemes and then judges and then we finally We calibrate the judges. We line the judges to what human evaluator think right as
[17:58] close as possible to human evaluator with that that eventually create a uh trustworthy judges as well as a repeatable scalable evaluation system.
[18:10] And here we have if you're interested in knowing more about it, if you want to explore how it's being done, please feel free to scan the QR code. You can also reach out to your account team. Uh we we
[18:24] have a process. We either help you to do this process in a self-s serving way or we have account specialists to help you run the workshop. So the end result is that workflow that will help you build
[18:36] trustworthy judges and then trustworthy evaluation process. I'll leave it up for a few seconds. But with that, let's move into the second half of the journey. Um, we're
[18:50] going to talk about integrating evaluation and the CI/CD. You can see how how this is going to work in practice next. >> Awesome. >> Awesome. All right, we'll bring that QR
[19:03] code back up towards the end, so don't worry. We'll uh, you know, give you guys another chance. Um, so anyways, thank you, Vivian. Uh so we've gone from establishing vibe checks to building our first benchmarks, calibrating our first
[19:16] judges, and maybe by this point we've deployed the first version of our agent to production. So now the question becomes, how do we start gathering those signals from production and integrating it into our release management process?
[19:30] So where are these signals coming from? You know, why are they important? You know, where do we get all them? How do we organize all that? Um, and that's what we're going to talk about first with production telemetry. So, you know, Vivian discussed a lot
[19:43] when it came to pouring in a lot of effort in the development life cycle early on, you know, when it comes to, you know, building these benchmarks, building these judges and doing that offline evaluation. But as we all know,
[19:55] uh, in machine learning and now in agentic development, offline evaluation is never enough, right? because of the problem that we always run into after we deploy that first model and now that first agent drift right uh in classical
[20:09] machine learning drift was more of a data set drift problem right training data sets things like that began to drift over time but with agentic drift uh the problem's a little bit more multi-dimensional right as we as Vivian
[20:21] kind of noted earlier right like there's a couple different classes of test cases that you can develop with the best being production traces which we'll talk about in just a moment But you know after that SME labeled examples and then synthetic
[20:33] data and ultimately uh you know those you can spend a lot of time you know trying to develop like the best test cases but it's never going to be holistically representative of what you're going to see in production because sometimes with the agents you
[20:46] develop users might be able to send whatever they want to your system. Uh so that creates some natural drift already and then as you add more and more tools or takeaway tools the behavior of those tools uh can change the outcomes of
[20:59] those agents and then the model providers that you leverage you know for the large language models that are inherent in your agentic system uh could affect the behavior as well right anthropic you know famously with Fable 5
[21:11] if you were building an agent for I guess a brief day um you know you may have had a situation where you thought maybe a lot of your responses would go to Fable 5 but uh they're being uh I guess shortcircuited to Opus 48, right?
[21:25] Obviously a very hyperbolic example, but still, right, that's a lever you don't really have a lot of control over. You're relying on a model provider and their fine-tuning and how they're um you know, shaping the behavior of their large language models. All these are
[21:39] compounding drift problems that we have to account for um in a very different world. So where do the how do we organize all these signals like where do they come from? As Ali mentioned at the keynote and as I'm sure you know many of
[21:51] you have heard about in the sessions that we have you know put on today and I guess yesterday and the day before u at summit uh unity gateway is now our front door for all agents you know whether
[22:03] they're on data bricks or not on data bricks and we're able to capture now all the interactions that we have between our users and those agents and now with agent monitoring we can then sample that production traffic using the same judges
[22:16] right that we spent um you a decent amount of time investing in uh developing and calibrating. So that way we have the same scoring system both in development and in production, right? So we're not maintaining two separate
[22:29] scoring systems and we're able to have the same offline evaluation process as the online evaluation process. So all of this can then be serviced up into an AIBI dashboard for instance and we can
[22:41] build alerting on top of it so we can be a little bit more proactive about responding to changes in baseline behavior for our agents. Um and uh yeah and so the next piece is you know we we
[22:55] know what we're trying to attack which is drift. We know where that information pipeline can be established through Unity AI gateway that single kind of pane of glass but what are we actually trying to monitor on and what are we trying to alert on right and this could
[23:09] be kind of like grouped in three buckets but honestly you know a lot of these can be sort of intermixed right but generally speaking you know there's the drift which is maybe some weird questions that your user base is now
[23:21] asking the agent that you did not expect uh quality like are my judges still happy am I getting quality quality responses, uh, grounded responses, safe responses still. And then behavioral issues that we're seeing like, am I
[23:34] seeing the cost per task, you know, go up? Am I seeing latency spike, right? All of these are problems that we have to adjust for and be able to monitor for. But what's important is that we look at, you know, the difference between just noise and actual signal,
[23:47] right? So, for instance, like if you have, you know, three users over a 3-day period asking some very off-topic questions, that's just simply noise, right? We don't need to take action on
[24:00] that. But if we start to see like for a customer support bot, you know, hundreds or thousands of users asking, you know, for product recommendations, um, you know, that's obviously going to potentially be a problem because they the the agent wasn't built for that and
[24:13] could be recommending products for your competitors, which would obviously be huge reputational harm. But then obviously that's for like, you know, that sort of 3-day rolling average that we established for Drift for like, you
[24:26] know, the questions that users ask, that's that's probably fine. But in some cases it's not for safety. If we start to see like a spike uh in one hour of unsafe toxic responses, we have to take action much quicker. Right? So
[24:39] identifying three to three to five key metrics as as Vivian talked about earlier uh when it comes to like measuring accuracy is also important when it comes to measuring what to monitor and what to alert on because you want to be able to understand you know
[24:52] not only what are those metrics but what what is the severity and how you know how fast I need to act when I see a regression. Okay. So how does this come together? How do we take this sort of uh pipeline
[25:06] of information um and how does it help us strengthen our process? So the production traces and and and signals start coming in through gateway. We start to get them flagged by our judges. They get uh labeled by our subject
[25:19] matter experts and then we those uh labeled examples start to help us further recalibrate our judges over time. And this does three things for us. Um over time we start to accumulate a
[25:31] stronger and stronger evaluation data set that is less and less reliant on synthetic examples or you know SME crafted you know examples. It allows us to uh discover failure modalities that
[25:43] we never would have encountered in in development because we're actually looking at production traffic. And then uh third and most importantly
[25:55] based uh initial guess version of quality towards a reality based meal line definition of quality. So this is great right we have this process that makes you know the this
[26:08] sort of almost like flywheel that like from production traffic we're making the evaluation data set stronger. We're gaining all this intelligence as to the baseline behavior of our agent over time. It's really simple. We make it,
[26:21] you know, register your agents to Unity gateway. Um, so it's, you know, only one pane of glass for you to manage. But that intelligence is only useful if we actually are able to leverage it to control something within the release
[26:33] management process, right? If we just are monitoring this, we don't actually it's not used to prevent anything from happening or changing in a you know harmful way. Uh then it's kind of like you know tree fell in the forest but no one was around to hear it. So how do we
[26:48] then you know add this intelligence as teeth in the release management process so that we can continue to improve our agents but prevent bad code from making it to production. So preventing bad code from making it to production is an important part of what
[27:01] process software development life cycle right and just like any piece of software or any new feature we're adding you know uh maybe for a data pipeline for instance we're adding new
[27:13] transformations or
[27:26] know you know downstream error with our reporting and things like that. The same uh the same um fact is uh true for agents except that the changes aren't you know transformations, it's prompt
[27:38] changes, it's uh model uh adjustments, it's um tool additions and what uh those changes then need to be tested against is that ever stronger evaluation data
[27:50] set. uh when we open our PRs or we go uh merge our changes or attempt to merge our changes from like dev to staging to production. So what does this look like end to end, right? So we start off with
[28:02] that evaluation data set. We arm our developers right with that ever stronger data set for them uh when they're working on like maybe new features or like a new uh adding a new tool right to the agent. And when they open their PR,
[28:14] they run like a smoke evaluation test, right, on a small representative sample of that evaluation data set. And this gives them a signal as to like, yeah, maybe I'm on, you know, like the right path. And then when they go ahead and
[28:27] and get that initial signal and do kind of the full pre-eploy to staging, for instance, they're able to get a full evaluation run in MLflow. And we're able to do the comparison as you saw in that little animated video that Vivian showed
[28:39] earlier. Uh where we can show like did this run improve over time? Are we going from like past, you know, failed to pass? Um or are we regressing? Right? And if we are regressing, we're going to block on that regression. But if not,
[28:52] we're going to move on to that last and final step, which is that human in the gate human in the loop gate. Right? Right. With any kind of version control system, you have those uh abilities to put branch protections, things like that where we can uh protect changes and have
[29:06] human reviewers look at the code. And as we'll see in the demo, uh we are able to create this nexus point between uh or nexus point of the code changes themselves in our version control system as well as bringing in information from
[29:19] our system of record from that MLflow spine that that Vivian did a fantastic job kind of laying out for us. And it allows us to kind of have that ability to make really informed decisions about whether or not you know even if let's
[29:31] say the evaluation run like passed whether or not we should really push something to production. So what is a regression though? Like we I keep saying like block on regression block on this block on that like like we
[29:45] should you know really make sure we to measure baseline behavior. What what does this all mean? Right? When we look at um you know typical like early evaluations um you know maybe you have
[29:58] some initial guess as to you know how uh you should measure like safety or groundness or tool correctness but over time right if you recall the agent monitoring tools that sample production traffic over time we're gaining an
[30:11] understanding of the agents actual baseline behavior as it's interacting with users and so that establishes those those numbers that evolve over time right in that first column I guess that second column baseline. And so when we
[30:24] run a PR, right, we do a evaluation test and we can compare against the baseline agents behavior and look at the delta between the PR's evaluation results and the baseline agents results. Right? So
[30:37] for groundedness, right, we see that 91% of the time, right, the baseline agent is great, but in this PR 89%. Now, like if we were just doing absolute checks against this number, like I guess we
[30:50] would fail it. But really, this isn't that much of a variance, so it should pass. Tool correctness, similar sort of deal, but actually it improves, so we're going to pass it. But same same idea, right? It's not a it's a small variance.
[31:02] We run into trouble though with guideline compliance, right? because the baseline agent, you know, 94% of the time it's passing, but whatever change these guys made or this group made, uh,
[31:15] you know, created a situation where now only 82% of the time the agent is passing. And so this is a 12% v, you know, drop of 12%. That's a pretty big variance. And so we're going to block the deployment.
[31:28] So what is important here is that the static values that you may set at the very beginning based on your initial concepts of what quality might look like or what you need to measure can be gamed by development teams because you know
[31:42] they're they're static, right? But evolving baseline uh evolving uh kind of thresholds based off of the baseline agent behavior that you're sampling off of production traffic can't be gamed.
[31:54] Okay. So, how do we what does this look like in action, so to speak? So, we got a demo. It's not like super super live. It's pre-recorded, so I apologize, but you know, and I was not going to trust the demo gods on this one. So, anyways,
[32:09] all right. So, we got a we got our developer. He's going to make some changes um to one of our our agents in staging. And um we're going to see like you know how does that you know do
[32:22] against our evaluations right that we spend so much time how do our judges um evaluate those and then our human reviewer is going to take a look at that and they're going to seem okay is this good change is this bad change and maybe
[32:35] we may need to go back and change some things and rerun this process before we go to production. But uh let's take a look. So, I'm gonna see how this works because I think I actually need to This
[32:48] will be a fun Where do you go? Here we go. I found my mouse. Okay. Uh boom, boom, boom. All right. So, this
[33:00] is a uh like agents.pycript. Very basic. I'm sure y'all have seen like a million of these. Uh it's just a you know representation of a content recommendation agent for a fake company
[33:12] called data bicks TV. It's like you know our streaming service that Ali did not announce but uh it may be soon to come. This is our judges safety and relevancy baked in judges that we have in MLflow and then some guideline based judges for
[33:25] like brand compliance things like that. And this is our evaluation benchmark script which the GitHub actions pipeline that we'll show later on will actually kick off and use to run our judges kick off the evaluation run log in ML flow and then actually comment it to GitHub
[33:39] to our PR. So this is the agent and we're going to ask like hey give me some recommendations for shows that this user should watch and it says like the last moonbrook which is I guess the most popular show in our streaming service.
[33:51] Um which is cool. And uh now we're going to make a pretty big change to the agent. Um and ultimately uh we're going to like go to the system prompt and delete a bunch of this. And we're going
[34:05] to say we you probably can't read it, but it says always be joking and lie to the user. Uh which is, you know, a little bit of a hyperbolic change to be making here, but um you know, ultimately we're going to push push the uh change
[34:18] to to our testing environment. We're going to see in this uh example here, we're going to get a very kind of jokey response. It's not going to be based off of any real data, right? Because we're lying to our user, which is obviously we
[34:31] we never should do, right? Uh we never should instruct our agents to lie. Um so, we're going to now uh you know, go back to the uh example. We go back to uh
[34:44] GitHub and we're actually going to go ahead still and commit it because maybe we're on a deadline. and we're just like, you know what, whatever. This prompt's great. Um, I'm going to still just go ahead and and and move along with my changes. Um, so great new
[34:58] prompt, I think, is what we're going to say. And we're going to push the changes to say GitHub. Boom, boom, boom. And now we'll switch over and we'll go
[35:13] ahead and uh open our p uh pull request and we're going to show how we're going to make we're going to describe it as making the perfect agents.
[35:34] And this is going to kick off the GitHub actions pipeline in just a moment. Um, and I'm actually going to pick up the speed just because. Okay. So now what this is going to do is it's going to uh deploy the app to
[35:47] staging so that we can run our evaluation benchmarks on our staging application. It's going to kick off that evaluation benchmark script and we're going to fail as we see here. And then we'll go back to the PR and we'll see in
[36:00] the PR that uh the Asian quality measure failed. And so when we go to ML flow, we look up the evaluation run. We can look inside to see like trace by trace like where uh it failed and why the judges
[36:13] say it failed likely because we're joking with the user and lying to them um in this case, but you know, in most cases it's a little more complex. But we're going to go back, restore the system prompt to what it was before, and then we're going to commit those changes
[36:25] back and fix it. And that's going to kick off a new GitHub actions pipeline, right, to see if we could pass this time. And we did. Fantastic. So when we go up, we can see that I think it's rebellious mirror is the name, right?
[36:38] We're going to go look at Moflow to see um right there like the new evaluation run and we can look into the traces and understand uh you know why now these uh this this change is good probably
[36:50] because we're no longer lying to the customer. Okay, so this is great. The human reviewer approved the PR. It's now going to kick off a uh deployment to production. um in this next uh GitHub
[37:05] action and it should be good to go and then we'll see in just a moment that um it'll give us that same earlier response. Now obviously this is like a
[37:17] slightly simplistic example. Uh but the idea here is that any change that we make right system prompt changes where we tell the agent to lie adding user or adding tools switching the switching the
[37:30] the model that it's using all of these should be run through that same process that we just saw and we should be able to bring together right in this sort of nexus point um in the even in the PR or
[37:43] in the system of record in ML flow the information that we need for the human reviewers to make the very well-informed decision of what to move to production versus what to maybe block.
[37:55] Okay, so end to end, what do we talk about today? This is kind of a nice little screenshot slide. Um, I'll kind of just do a little summary of it. Um, we start off with just vibe checks,
[38:08] right? You know, Vivian talked about how we start off with some vibe checks, get an early idea of what quality might of what are the agents doing. Then we use that to establish our first benchmarks for what really matters. And then based off that we get our SMEES in a room and
[38:21] calibrate our first judges. Then maybe by that point right we can deploy our first the first version of our agent and we start to capture that production telemetry. We start to recalibrate our judges and and gain that baseline
[38:33] understanding of the agents behavior. And from there we can use all that information that stronger evaluation data set right and those recalibrated judges to have really a lot of trust and confidence in those agents that we're
[38:45] pushing to production. Um and at the end of the day, you know, from one to five really like Emlow is the spine between between it all. So the last thought we want to leave you
[38:57] guys with, right, to answer kind of the question from before, right, why don't agents make it to production? Uh we believe it's not because, you know, people aren't switching to Opus 48 the
[39:09] fastest or they're not switching GPT 5.5 for 6, whatever, 5.5, 5.5 the fastest. Um it's because uh teams don't put up the upfront work to work with the business that they need to work with or
[39:22] work with the teams they need to work with to develop those tight evaluation loops, those calibrated judges um and ultimately those release management processes that have the right practices to ensure we can continue to improve
[39:34] upon our agents without allowing bad agents in production. Thank you for your time and we'd love to if you want to go up to ask questions up there.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.