[
  {
    "startMs": 12400,
    "text": "Hello, everyone. My name is Sofija Kovcevic. I'm a forward deployed engineer at Arize, and for those who aren't familiar, Arize is an observability backend that is designed to make AI work. Now, what does that mean? Building AI systems can be inherently intuitive in some sense, especially when a lot of that low-level abstraction is... a low-level programming is abstracted into the mind of an agent. Unfortunately, though, that mind can be a bit of a black box. When that black"
  },
  {
    "startMs": 42320,
    "text": "box is difficult to understand, it's difficult to predict and therefore difficult to debug, and that's where observability becomes essential. Observability helps you understand what your systems are actually doing. It's essentially shining a light in the black box. And once you understand what the system is doing step by step, you can then evaluate it, run evaluation metrics to track its performance, and then use that data to iterate and improve your agents over time. But I want to take this one step further because the biggest challenge"
  },
  {
    "startMs": 72240,
    "text": "isn't determining what broke. The biggest challenge is that when you do submit a fix, you want to make sure that you don't break ten other things along the way. Now raise your hand if you've had that exact issue before. You push... Yep, seeing a lot of hands. You push a simple change, you know, should be, it should be easy, no issues, and next thing you know, everything's on fire. So today we're going to discuss how you can use your observability as a way to build a robust regression process. Not only something that your"
  },
  {
    "startMs": 102220,
    "text": "engineers can do, but an automatic process that feeds into your CI/CD. We're gonna break this down to three parts. First, we'll discuss why agent regression is so different and difficult to detect. And the first thing we're gonna touch on is that agents don't fail at the code level, they fail at runtime. We're then gonna use this premise to build out our regression loop. It's gonna be a five-step process. We'll touch on it at a high-level overview, and then we'll move on to the Arize platform and show you exactly how you can do it today. Then we'll close"
  },
  {
    "startMs": 132260,
    "text": "off the session by closing that regression loop at agentic speed and touching on where we're seeing the next frontier of agent observability move to. And if you stick with me till the end, I'll introduce a paradigm shift that I hope you'll all find interesting. So let's get started, first with a concrete example. So imagine with me that you have a support agent and you have a security engineer that has approached you, and that security engineer has reviewed the policy of your support agent and determined that he wants to add one line, a simple one line to"
  },
  {
    "startMs": 162120,
    "text": "your agent that will ask your agent to confirm before it takes any action. Sounds simple, sounds harmless. Your security engineer says he has the intuition, and oftentimes we're quick to make this change. I'm not even gonna ask if you've done this before, 'cause I know everyone has pushed a one-line prompt change and just assumed everything will go well. And the reason we make that assumption is because we think that because it's written in natural language, that we have this intuition on how these agents are performing."
  },
  {
    "startMs": 192080,
    "text": "We're really coding on vibes, and we don't want to be. We want to be able to code with a numeric evaluation suite backed data. We want to have scores that prove that these changes are actually making a positive impact and not just crossing our fingers. But let's say in this scenario, you did push that one line change, and now you are running your evaluations on your production data a week after it's been submitted. And the first thing you notice is that you actually have a seventeen-point improvement on a action safety. So your security engineer"
  },
  {
    "startMs": 222060,
    "text": "was correct. Asking the agent to confirm before taking any action does improve its overall safety. But your observability engineers are continuing to evaluate, and they also check for task completion, and they notice a seventeen-point degradation. Now, this is occurring because if you have an agent that's confirming before every single action it's taking, now tasks are being uncompleted. If a user leaves the session, that session is never completed to the end. And now you have"
  },
  {
    "startMs": 251620,
    "text": "incomplete task, and you see this unlikely result. You may not have caught this initially when you were thinking about the project, but your evaluation suite has caught this. And ironically enough, the overall average of both is net zero. And what I want you to take away from here is just because you improve the dimension of one agent does not mean that you're improving the agent as a whole. The question I have for you is, would you have shipped this change? Many of us would have before the evaluation test. And this is why it's so important that we"
  },
  {
    "startMs": 281520,
    "text": "get these numeric results so that we're not shipping on vibes, we're shipping with backed data. So to understand where the mistake that we made is, is we made an unrealistic assumption, and that assumption is that the error is going to occur at the code, but the error rarely occurs at the code level. Instead, these agents are failing at runtime. What the code reviewer saw is here on the left-hand side. It was a one-line change in a system prompt Markdown file."
  },
  {
    "startMs": 311360,
    "text": "Easy change, simple to understand, simple to approve. But in reality, this code change was local, but the behavioral changes of this code change was in production. It was in the runtime. This one simple line has shifted how the agent operates. It's adding additional steps. It's changing how the agent works with other sub-agents. It's changing how the agent calls tools. All of these different trajectories, which could be thousands of possible trajectories, are not in your static code. They're only in your observability backend. They're only in your"
  },
  {
    "startMs": 341080,
    "text": "traces. And so what we are seeing here is that the diff tells you what changed, but the trace tells you what actually happened. And there's a shift here that traces are becoming the new source of truth. These structured logs of what your agents are actually doing actua-- is what truly represents what these systems are doing. In traditional software, logic was written down. It was very clear to determine what that runtime was before you ever pushed to production. But now the logic only exists at"
  },
  {
    "startMs": 370760,
    "text": "runtime. The observability becomes essential when we're looking at regression testing. This gap between what was written and what actually happens is filled with silent errors. So to capture that, we need to start our regression testing by looking at our traces. So let's build out this regression loop together. It's a five-step process. We're gonna start with our production traces. We're gonna build evals, run experiments, and then close it all up to be an automatic gate at CI. First, I'm gonna do a"
  },
  {
    "startMs": 400656,
    "text": "five-step high-level overview, and then we're gonna go into the actual product and show you how you can do it yourself. So step one is we're gonna select a dataset. Seems simple enough. We want to pull real production traces. We don't need to synthesize data if we already have real user queries, real inputs, real tool calls. We're pulling from that directly. It's important that our dataset is a representative workf-- is representative of the average workflow that our users are going to be pushing into our systems. But it's also"
  },
  {
    "startMs": 430516,
    "text": "important that we capture known failures. We filter out co-- m-moments where it often errors, often fails at eval metrics. Capture those into your data-- datasets. You also wanna capture edge cases, maybe not as common, but just as important. And one thing that we often see users forget is capturing successful workflows that we want to protect. Because, again, we're not just trying to make sure that the fix is gonna work, but we also want to test that we're not gonna break something that was"
  },
  {
    "startMs": 460296,
    "text": "already working. So it's important that we capture all four of these in our dataset. Once we have this production dataset, we can then build out the rest of our regression testing suite. The second step is we wanna have a scoring mechanism, and this is where we bring in evaluators. Now, show of hands, how many here are familiar with the concept of evaluating agents?"
  },
  {
    "startMs": 481536,
    "text": "I'm so happy to see so many hands. This is a core foundational part of agentic engineering. Evaluators allow us to take metrics and dimensions that are important to your engineers, your product team, and actually quantify them. What do I mean by that? Let's take some metrics that are important for your agents. Things like hallucination, accuracy, tool trajectory, step efficiency. All of these metrics are subjective in nature, and you may have a human that reviews them and can potentially determine"
  },
  {
    "startMs": 511376,
    "text": "whether or not something was hallucinated, whether or not the most efficient pathway was taken. But we wanna be able to automate this process. We wanna turn a subjective metric into a numeric score, and we do this by leveraging LLMs. We use a concept of LLM-as-a-judge, where we judge a span, a trace, some log data against an LLM. The LLM has a particular guide of how it determines whether or not something was hallucinated or factual, something was efficient or not efficient."
  },
  {
    "startMs": 541456,
    "text": "And now we've done essentially a binary classification. In this example at the top right corner, you can see a task completion eval where the LLM-as-a-judge is... has the task of determining whether or not something was complete or incomplete. Now we've taken a subjective metric, and we've essentially turned it into a binary score, zero one. You can translate the score across zero to five. You can have multiple different labels. But you've now turned a quantitative measurement into a qualitative score that you can measure against. You're not limited to LLM-as-a-judge. You can also use"
  },
  {
    "startMs": 571416,
    "text": "code-based evals or ML-based evals as well. Determine-- Based on what that metric is, a code evaluator is great for your deterministic checks, but an LLM-as-a-judge is good for your non-deterministic checks. So once we have a list of all of our metrics that are important to us, we build evals for each of them. Now we have a testing suite that we can go against. Step three is we're gonna run our baseline experiment, and what this experiment is, is we're going to take our agent and run it against all of our production traces, um, all of our production"
  },
  {
    "startMs": 601416,
    "text": "datasets. We're-- After we get the output of those production data, production datasets, we're then gonna run our eval testing suite on top of that, and that's what's gonna be our baseline. Now, you can do this in the SDK. It's just run experiment. You'll pass in that dataset, pass in that task, pass in your evaluation suite, and you'll get those results. We're gonna t-touch on how you can do this in the UI, as well as how you can do this with your coding agents. But once you have that baseline experiment, you're then gonna add your one change. Change that policy, rerun the evaluation."
  },
  {
    "startMs": 631496,
    "text": "What are the eval results? A simple process now that you can quickly iterate on, and not just with one policy change, but test multiple changes within your prompts. Test multiple models. If your team comes with y-- comes to you and says, \"We wanna switch to the new Fable model, it's five times more expensive,\" you're not gonna switch without proving that you're gonna get a good ROI. This is how you can prove that with a numeric set of measurements to det-determine whether or not it actually is improving your investment to switch to a more expensive model. And you can"
  },
  {
    "startMs": 661416,
    "text": "adjust this policy, rerun and compare. Rerun and compare how changing the prompt, changing handoffs, changing tools, changing models is all going to affect your overall output, all without having to deploy to production. And then we can automate this. We push this experiment into CI to complete this automation. Now, each time that you have a pull request, let's say you set this up in GitHub Actions, for example, each pull request, each PR is run through an experiment workflow against the evaluations that your team"
  },
  {
    "startMs": 691456,
    "text": "has deemed important, and you don't merge until it meets all of the regression criteria that you have listed. Now you're no longer pushing on vibes. You're pushing with confidence that you actually do have a positive impact on your performance. And if it is negative, you go back, you test, and you reiterate. So let's actually show how to do this in the platform. Let me switch over. Um, here we have, here we have the Arize platform, and I'm showcasing this exact refund agent. You can see in our baseline experiment"
  },
  {
    "startMs": 721476,
    "text": "what our scores were, and then you can see that plus seventeen points on action safety and minus seventeen points on task completion. Each one of these points, each one of these line items here is a different test that I ran with different prompt changes, potentially different model changes, and I'm evaluating each one of them to see which one has the best trade-off to get to where my end goal is. And I can see that overall, I'm gonna have a plus eighteen per-- eighteen points on action safety and plus six on task completion. Now, how can we build these individual points? Well, there's a couple"
  },
  {
    "startMs": 751316,
    "text": "ways. We'll do this first in the UI. I'm gonna jump into the playground here. I'm gonna create a new playground. We're gonna start with the Prompt Playground to test a single agent. Let's call this AIE NYC. Perfect. Once I'm in the Prompt Playground, here is where I can test a single agent. An agent, a single agent, all is essentially just a single prompt with a set of tools attached to it, a model, LLM configurations, and so we're gonna replicate that here. Now, I've already stored my"
  },
  {
    "startMs": 781200,
    "text": "prompt in my Prompt Hub, so I can pull it right here. I've got version one, and then I can pull up my dataset. I've already selected a dataset that I can use here and that I've gone through and pulled out those edge cases, those known failures, and those successful workflows that I want to protect, all listed in this one hundred-row dataset. I can test this right now, or I can test multiple prompts at the same time. So I'm actually gonna duplicate this, and I can change a line item directly in here, or I can load"
  },
  {
    "startMs": 810960,
    "text": "up a separate version right here and test side by side, so I can see just how quickl-- just how both of these prompts are affected. Now, of course, we have to add our scoring mechanism, so that's gonna be our evals. I'm gonna click here. I'm gonna add in my task completion, and then I'm also going to add in my action safety. And you can see here that there's a ton of other pre-built hallucin-- uh, pre-built evaluators you can select from, hallucination, user frustration, um, we've got some code templates,"
  },
  {
    "startMs": 840760,
    "text": "security checks, et cetera, and you always have the ability to customize your own. Once I run this, it's going to run on every single record, and then it's gonna pull out those eval scores. And then when I go into my datasets here, go into my"
  },
  {
    "startMs": 861500,
    "text": "experiment run flow, it'll pop up under here as well. And I can pull up all those metrics that are important for me. I can look at latency, I can look at my evals, I can look at my total costs and error rates and track that over time. So I can look this for PR changes, for playground runs. And there's one more other option that I wanna show here too, and that's if I go into Playground, I click here, and I do Agent Playground."
  },
  {
    "startMs": 886540,
    "text": "Call this AIE... Oh, there we go. Agent Playground allows you to not only evaluate at a single agent but at multiple agent levels. If you give us access to connect to your agent remotely, for example, through a HTTP call. If I go into remote agents here, you can connect your remote agent directly here so that you can change how different sub, sub-agents communicate with each other, all directly in your code base, and then we can call that. So each record in your dataset, we'll call against your agent,"
  },
  {
    "startMs": 916500,
    "text": "we'll test, we'll get the output, we'll run those evals, and then score it in the same mechanism. So you have two ways of running pl-- running these experiments within the UI. You can run them in the Prompt Playground, testing a single agent, or run them in the Agent Playground and test a very complicated multi-agentic system. Now, this is in the UI, but of course, you can do this programmatically with the SDK, REST, or CI, or CLI. But my favorite method to do this is actually with coding agents. How familiar is this group with the concept of agent skills?"
  },
  {
    "startMs": 947280,
    "text": "Oh, I love to see when people are saying advanced. Agent skills allows you to connect your coding agents with external databases in advanced contexts. Arize has a public repository of skills that allows you to connect to every feature available in the Arize UI. This means that you can close the loop between what your coding agents are producing in your IDE, the code that they're producing, with what is actually happening in your observability backend. So let's actually touch more on that closing the loop."
  },
  {
    "startMs": 975680,
    "text": "So how are we gonna close this loop at agent speed? We've got the same loop, but instead of running it by people, we wanna run it by agents. Now, I'm gonna highlight two key takeaways. We only have two minutes left here. And the first key takeaway I wanna touch on is what the engineers are doing. Today, engineers are the ones that are closing the loop. And to summarize what that loop is, is we have observability first. That is, as your systems are running, we are taking that log data, that tracing data, and we are tracking it for every run in production. We then take that, evaluate it, get"
  },
  {
    "startMs": 1005560,
    "text": "those scores. Then we can implement a change, and that could be a prompt change, model change, tool, skill, policy change. And then we test that change. We iterate on it with the experiments workflow. Finally, we improve it. If it passes, great, ship it. But if it fails, we close the loop. We take those failed cases, and we bring it back to the observability layer. These new production traces that failed then become new cases in our regression testing suite, and that's the first takeaway here,"
  },
  {
    "startMs": 1035500,
    "text": "is that every failure should become a test. Every failure should make your agent stronger and harder to break. Once you have these regression tests that are-- regression test suites that are constantly building on themselves, you have a more robust method of continuously iterating and improving. That's takeaway number one. Now, takeaway number two, going back to that loop, I have a question for the group, and that is, what if an agent could do the investigation and propose the fix? Because right now the manual"
  },
  {
    "startMs": 1064900,
    "text": "investigation is that-- that's the bottleneck. Humans are the bottleneck here. So what we're seeing is a shift from observability to self-improvement. The manual bottleneck here is that humans are still reviewing dashboards. They're still triaging and shipping those fixes and reviewing those PRs, and that is the ultimate bottleneck. So we wanna not only close this loop, but we wanna close it at agentic speeds. We don't wanna just give humans the ability to debug agents. We wanna give agents the ability to debug and understand themselves, and that's the"
  },
  {
    "startMs": 1094980,
    "text": "shift that we're seeing in observability, is observability is no longer about humans understanding agents. It's about agents understanding themselves, agents having the tools to improve themselves, agents having the tools to be accountable. Remember what we talked about in the very beginning. That is that traces is where the real runtime is. That's where the real logic is stored. If your coding agents are pushing PRs, and I know they are, they're pushing PRs without actually knowing what's happening in production. That means they're pushing PRs blind. They're reliant on the static code."
  },
  {
    "startMs": 1124880,
    "text": "They don't know what's actually happening in production. By closing that loop, by connecting your coding harnesses, your coding agents with what is actually happing-- happening in your production database, you are giving your agents the full understanding of what these changes are actually making. And that is the second and final takeaway. That is that the best agents don't just learn from failures. The best agents fix themselves. And that's the future of observability that we're seeing, is that agents can not only see, but they can evaluate and improve themselves on their"
  },
  {
    "startMs": 1154880,
    "text": "own. Thank you."
  }
]