Your Agents Need a Save Button - Hamza Tahir, ZenML

[00:00:00]Have you ever looked at your agent execution and asked yourself the question, why did it do that?

[00:00:06]What if it had done a different thing?

[00:00:08]Would it have been cheaper? Would it have been faster?

[00:00:11]Well, you can do all these things if your agents have a save button.

[00:00:20]We've had the save button for documents for decades now. Since the 1980s, people have been used to pressing control S, command S uh or auto saving while you're working to have a persistent state.

[00:00:34]But agents, they don't have that today.

[00:00:37]The only thing we have which is closest is a trace. A trace gives you the emitted telemetry data of how an agent calls tools in the input and output of that state. Now, while this is a good start, it is actually very disconnected from the runtime in which these agents actually execute. So, all the variables that are in state, all the file system that is in in flight, um the decisions that it makes in the code, uh the actual code itself, all of that is lost and it is only stamped as a read-only trace by the end, which is sitting in another tool far away from where the actual code is.

[00:01:16]And I think this is what's missing today in the industry is that we don't have a clear connection between the observability spans that are emitted with Odel and the execution.

[00:01:28]And maybe at this point you might be wondering, but why even bother? Why do I need to have a save button?

[00:01:35]Well, save allows you to replay. You can go back in history and ask the what if question.

[00:01:41]What are the types of questions you might want to ask? Well, you might want to swap the model. Maybe you use a an open-source model that is cheaper.

[00:01:48]Maybe you mock a tool and you override the what it returns. Maybe you degrade it intentionally to see what would happen if things are wrong.

[00:01:58]And these sorts of questions are only possible if you have that state.

[00:02:03]And there is a category of the stack emerging which actually allows that. And this sit on top of the harness sit on top of the frameworks that allow you to create agents.

[00:02:16]And put a durable runtime below that. Um and augments the traces that are emitted with actually the code execution and the things that are around it to actually complete the state of this of the of the system.

[00:02:31]And the good news is that once you have such a system in production, you already have the information you need to ask those questions that are relevant to making your system better, cheaper, and faster.

[00:02:46]Production already has the traces. It already has these state checkpoints ideally from the runtime that can allow you to go back in time and ask those questions. For example, let's take an agent example which does a customer resolution and refunds after a chargeback dispute.

[00:03:06]Well, you can then see if the order status is changing languages or whether the request should have been escalated or maybe a smaller model would have handled it if the runtime is checkpointing each of the state as it goes along.

[00:03:19]Almost like an auto save, a command S, a control S in your agent.

[00:03:24]And once you have that, you can even close the loop.

[00:03:28]Uh this conference is all about loops.

[00:03:30]So, this is nothing different. You have a cohort of runs that you think maybe matter because maybe they're too expensive, they took too long. You replay a change, you diff it, you see what would have happened when you have the baseline, which you know what happened in the first place, and then you decide and you route and you ship back.

[00:03:51]That's closing the loop on your e-vals.

[00:03:54]It's It's It's basically evaluating using your production traces.

[00:04:01]So, it's basically evaluating using your production checkpoints.

[00:04:08]So, checkpoint replay diff decide. And this is really the methodology that that I've seen and I've seen others do, uh which has really scaled.

[00:04:18]For example, DoorDash. DoorDash has a a blog post on the 1st of June where they talk about having a simulated environment where they replayed customer bots. And they've done what-if scenarios and seeing how they could have made it better. And where And where it used to take them hours and hours to to do this, now they've reduced it to 5 minutes uh with hundreds of simulations, have 90% less hallucinations, and they're still two points within what they've seen in production. So, the simulations are pretty good because they're grounded in what's already happened.

[00:04:54]So, we're going to just walk through this um in an example, and we're going to see how this works.

[00:05:02]Uh for this demo, we're going to be using a tool called Kitaru. Kitaru is a very new tool that is launched by the team at uh ZenML. ZenML is has been around for many years and is a player in the orchestration space. I'm one of the co-founders.

[00:05:19]And Kitaru is something we've launched recently, which allows you to have a runtime layer below your harness layer, and also connect to your traces.

[00:05:27]Um and do all the checkpointing that we were just talking about and then running replay scenarios.

[00:05:33]So, you can see here I have all of my I have a support uh agent which looks at my customer requests and escalates it when it needs to to humans.

[00:05:44]You can see various things as you might expect. Um, every tool call uh can see a timeline view if I wanted.

[00:05:51]And here the difference is that if I if I click on a particular um um checkpoint like a tool call, I can see the configuration, where it ran, uh the code it it took um and the artifacts which came in and out of it.

[00:06:08]Um and this combination of code and the artifacts that it created and the environment in which it ran in, whether it was a Docker image or a sandbox, those are all snapshotted in state here between the checkpoints.

[00:06:20]And you can see that here in this particular example, there was a few tool calls every time it went to the LLM, and I can actually see um you know, how long it took.

[00:06:30]But imagine I wanted to do something different. Imagine I wanted to change the model if I maybe at this point I wanted to use a cheaper model. Would it have done the same stuff afterwards?

[00:06:42]So, to do this in Kitaro, it's quite easy.

[00:06:45]All you have to do Now, to do this in Kitaro is quite easy.

[00:06:50]All you have to do is you have to take your execution and replay it at a particular point.

[00:06:58]So, I'm just going to copy this over and I'm going to put it in my terminal and see what happens.

[00:07:04]So, here what I'm doing is essentially I am saying, "Okay, after this particular tool call, change the model to GPT-5 Nano, which is obviously a bit cheaper." Um and then what's going to happen here is there's going to be a new execution that's launched from 71 and you can see the first three checkpoints are skipped. So, they're all skipped because Kitaro already has the state of all the checkpoints before that. All it needs to do is just change this particular checkpoint and then execute start executing from here. And this is really cool because now I can see what would have happened in this scenario if there was a cheaper model. So this looks pretty similar to me, but what if I had wanted to do a even different change? What if I wanted to mock a tool or or or if I wanted to change a tool call?

[00:07:57]Well, in order to do that, you can mock up for example the lookup policy tool.

[00:08:02]And here it's also very easy. I can just go back here.

[00:08:08]Replay. And this time, rather than changing the model, I am changing the lookup policy. And I'm mocking it with another function in my code base, which returns a different lookup policy.

[00:08:20]And I'm just trying to understand if the policy had changed, what would have happened. This time I'm holding the model constant. Now, the interesting thing here is that because I have the code, it's very easy for me to do tool calls and to change these particular things and do more experiments than I would have had if I was completely disconnected from the code base.

[00:08:40]And here you can see that the code base is a little bit different, so I see my logs here.

[00:08:45]They look a little bit different.

[00:08:47]And here you can see that I got a slightly different artifact maybe from the tool call, and it published the thing. So now again, I have three runs.

[00:08:54]I have the original run and I have the two replays. Now, what if I wanted to see them side by side, right? So Kitaro actually has this very handy diff command that lets me give an original ID of an execution and then allows me on the other side to actually see them side by side. So I can see what happened.

[00:09:18]So there's a few warnings here about some artifacts, but in a second it will go and give me a URL.

[00:09:27]I can copy this URL and I can actually put it directly here.

[00:09:31]And now I have a very nice um comparison of the original and the two forks.

[00:09:39]Um I can see a bunch of things here, but I think what's really interesting is this view. So, in this view, you can see that the first part of the the baseline is the same, right? So, these things were skipped. They were exactly as it is. The state is exactly where it was.

[00:09:52]Um but now, right after that, in the third replay, it's a little bit different, right? The tool call happened a bit differently because we used a different policy, and then something changed after here.

[00:10:01]Um here, it took a little bit longer.

[00:10:04]And you can really start looking at the final result. And if I click on the final result, I can actually see the artifacts side by side. I can see what decision um it actually ended up making.

[00:10:15]So, you can see that it uh here, it restricted the count charge. Here, it also restricted it. Here, it also restricted it. In the first two, it actually needs review. In the third, because we changed the policy, it's safe to answer. So, this might or might not be good in your scenario, but if is this is what you expected to see? Well, maybe.

[00:10:35]Because the these two were cheaper at the end of the day. For for for the number of tokens consumed, uh they were cheaper.

[00:10:43]Input and output. And you can see a bunch of detail here uh in the in the UI, which might be useful for these for these analyses.

[00:10:52]Okay, but this is just one point, right?

[00:10:54]What if I wanted to do this across a cohort? What if I wanted to have a bunch of runs, right? Which actually um maybe sorted by cost. So, maybe I took all of my expensive ones. Then I wanted to do one change across the entire cohort. So, change the change all the tool calls that happened uh that happened for this particular set of configurations across the cohort. Or change the model itself um and use a cheaper model across the cohort. So, this gives me a bigger distribution of information and replays that I can use.

[00:11:30]Um and now, I can just this.

[00:11:33]Um, and the way you would replay it is you can use the replay mini command where you actually um, start from a particular point and you do the same as you did before just across the cohort.

[00:11:47]Um, this is going to take a while, so I'm not going to do it now. But once you execute it, in this particular case, I just emitted it to JSON, so I have a very nice, uh, JSON here, and this JSON gives me a bunch of things. So, this is a bit hard to do the UI, right? So, there's a lot of things going on. You can't just do the many, many, many comparisons here.

[00:12:09]Um, but what you could do, and what I love to do personally, is use the Kitaru MCP server.

[00:12:16]And here what you do is you can just say, "Hey, read this you read this JSON report and do an analysis on what you think I should be doing across the cohort."

[00:12:28]And I think this is what What is really important is to be using agents and LLMs to analyze these cohorts across a plethora of data because at some point uh, I mean, 10 is probably easy to do, but what if you have thousands?

[00:12:43]Um, and doing thousands and thousands is hard, and this is where skills and MCP servers get really relevant and having the runtime be queryable and go into your execution and fetch the artifacts is very important.

[00:12:56]So, it's going to be it's going to be uh, doing a lot of things. So, it's it's it's trying to, you know, um, run an analysis around these decisions and it's going to flag any um, red flags that that happen.

[00:13:10]So.

[00:13:12]While this is going on, um, maybe we can go back and continue our presentation. So, um, Here you can see, yeah. Yes, if you change the model, it can get very cheap.

[00:13:29]And of course, you don't want to do it across just one sample, but across many because then you can see a bigger variation. I think one thing which is important here is and to be very honest is that while we've been doing it this with our users and customers, what I've personally seen is that having a naive model swap usually or often times doesn't work. So just changing for example to a cheaper model and just looking at the cost one single dimensionally, obviously it could be that you're you're spending a lot less money, but what happens if your support board is not resolving the requests, right? So this is a study from BrainTrust. Excellent study where they actually looked at that and they saw that there could be a false economy if you do a naive model swap because it might look on paper that you're faster and you're cheaper, but at the end of the day you have to look at the value created, right? So it's a trade-off between how much money you want to spend and and yeah, the result.

[00:14:26]And also, if you look at the towel bench, what we must understand is that a model that passes 60% of the time is only self-consistent about a quarter of the time. So which basically means that one replay is just an anecdote and having a cohort analysis is way way way better.

[00:14:47]Um and because then you can really see across a population and across scale what would have happened not just looking at one estimate.

[00:14:57]This can get very expensive of course and this is where you have to be really smart about what you replay and have tooling that really helps you.

[00:15:05]And this you can really bake into your production process as well, right? So again, if you if you take a step back and look at the playbook, you can start from real runs, not synthetic, but real runs, real production uh state.

[00:15:23]Build cohorts that matter.

[00:15:25]Um maybe take the expensive ones, maybe take the long ones, maybe take the risky ones.

[00:15:29]Um never ship anything by just replaying one or two things.

[00:15:33]Um and just do this at scale and uh ship, route, and hold, and try to automate that loop as much as possible.

[00:15:39]Maybe there's an agent that's doing that for you. Um that's even better.

[00:15:43]But you just have a human in the loop at the end.

[00:15:47]But you just have a human in the loop at the end.

[00:15:50]Now, let's see where our cohort analysis has gotten us.

[00:15:55]Okay, so we're done. So, the verdict is don't ship. So, even though it looked like from a single replay that it was cheaper to do and we reached the same result, across a bunch of those support cases, you actually saw that our agent concludes that you shouldn't be using a cheaper model in this particular case for your data.

[00:16:12]But this might be different for your data.

[00:16:16]In conclusion, um if you want to be replaying your agent executions and answering the questions what if I had done something different while designing this agent or what if the agent could be driven to do something different?

[00:16:34]Well, you can do this if you model your agent with your harness in a runtime that can checkpoint state and is able to replay that state from code with different scenarios.

[00:16:49]If you want to use Guitar Ru, the the the tool that I showed that allows you to do it, um you can scan the repo. It's open source, free to use, and uh we'd appreciate the feedback and love.

[00:17:01]Thank you so much, and see you guys on the next one.