Your Agents Need a Save Button - Hamza Tahir, ZenML

Have you ever looked at your agent execution and asked yourself the question, "Why did it do that?" What if it had done a different thing? Would it have been cheaper? Would it have been faster? Well, you can do all these things if your agents have a save button.

We've had the save button for documents for decades now. Since the 1980s, people have been used to pressing Ctrl+S, Command+S, or auto-saving while you're working, to have a persistent state. But agents, they don't have that today. 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 and 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 flight, the decisions that it makes in the code, 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.

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 OTel and the execution. And maybe at this point you might be wondering, "But why even bother?

Why do I need to have a save button?" Well, save allows you to replay. You can go back in history and ask the what-if question. What are the types of questions you might want to ask? Well, you might want to swap the model.

Maybe you use an open-source model that is cheaper. Maybe you mock a tool and you override what it returns. Maybe you degrade it intentionally to see what would happen if things are wrong. And these sorts of questions are only possible if you have that state.

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, and put a durable runtime below that 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 the system.

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. 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.

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 states as it goes along.

Almost like an auto-save, a Command+S, a Ctrl+S in your agent. And once you have that, you can even close the loop. This conference is all about loops, 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. That's closing the loop on your evals.

It's basically evaluating using your production traces.

So

it's basically evaluating using your production checkpoints. So checkpoint, replay, diff, decide. And this is really the methodology that I've seen and I've seen others do, which has really scaled. For example, DoorDash. DoorDash has 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 seen how they could have made it better.

And where it used to take them hours and hours to do this, now they've reduced it to five minutes 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.

So we're going to just walk through this in an example, and we're going to see how this works.

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 ZenML. ZenML has been around for many years and is a player in the orchestration space.

I'm one of the co-founders. 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 and do all the checkpointing that we were just talking about, and then running replay scenarios.

So you can see here, I have all of my I have a support agent which looks at my customer requests and escalates it when it needs to, to humans. You can see various things, as you might expect. Every tool call, I can see a timeline view if I wanted.

And here, the difference is that if I click on a particular

checkpoint, like a tool call, I can see the configuration, where it ran, the code it took, and the artifacts which came in and out of it. 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.

And you can see that here, in this particular example, there were a few tool calls every time it went to the LLM, and I can actually see how long it took. 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? So to do this in Kitaru, it's quite easy. All you have to do now, to do this in Kitaru is quite easy.

All you have to do is you have to take your execution and replay it at a particular point. So I'm just going to copy this over, and I'm going to put it in my terminal and see what happens.

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. 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 Kitaru already has the state of all the checkpoints before that. All it needs to do is just change this particular checkpoint and then 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 an even different change? What if I wanted to mock a tool, or if I wanted to change a tool call? Well, in order to do that, you can mock up, for example, the lookup policy tool.

And here, it's also very easy. I can just go back here,

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 codebase which returns a different lookup policy. 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 codebase.

And here, you can see that the codebase is a little bit different. So I see my logs here. They look a bit different. And here, you can see that I got a slightly different artifact, maybe, from the tool call, and it published the thing.

So now I have three runs. I have the original run, and I have the two replays. Now, what if I wanted to see them side by side,right? So Kitaru actually has this very handy diff command that lets me give an original idea of an execution and then allows me, on the other side, to actually see them side by side so I can see what happened.

So there's a few warnings here about some artifacts, but in a second, it will go and give me a URL. I can copy this URL, and I can actually put it directly here. And now I have a very nice

comparison of the original and the two forks. 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 baseline is the same,right?

So these things were skipped. They were exactly as it is. The state is exactly where it was. 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.

Here, it took a little bit longer, and you can really start looking at the final result. And if I click on the final result, I can actually see the artifact side by side. I can see what decision it actually ended up making.

So you can see that here, it restricted the account charge. Here, it also restricted it. Here, it also restricted it. The first two, it actually needs review, and the third, because we changed the policy, is safe to answer.

So this might or might not be good in your scenario, but is this what you expected to see? Well, maybe, because these two were cheaper at the end of the day for the number of tokens consumed. They were cheaper, input and output.

And you can see a bunch of detail here in the UI, which might be useful for these analyses. Okay, but this is just one point,right? What if I wanted to do this across a cohort? What if I wanted to have a bunch of runs,right, which actually

may be sorted by cost? So maybe I took all of my expensive ones, and I wanted to do one change across the entire cohort. So change all the tool calls that happened for this particular set of configurations across the cohort, or change the model itself and use a cheaper model across the cohort.

So this gives me a bigger distribution of information and replays that I can use. And now I can just replay this. And the way you would replay it is you can use the replay many command, where you actually start from a particular point and you do the same as you did before, just across the cohort.

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 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 many, many, many comparisons here. But what you could do, and what I love to do personally, is use the Kitaru MCP server.

And here, what you do is you can just say, "Hey, read this JSON report and do an analysis on what you think I should be doing across the cohort." And I think this is what is really important, is to be using agents and LLMs to analyze these cohorts across a plethora of data because at some point, I mean, 10 is probably easy to do, but what if you have thousands?

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. So it's going to be

it's going to be doing a lot of things. So it's trying to run an analysis around these decisions, and it's going to flag any red flags that happen. So while this is going on, maybe we can go back and continue our presentation.

So

here, you can see, yeah, yes, if you change the model, it can get very cheap. 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 this with our users and customers, what I've personally seen is that having a naive model swap usually, or oftentimes, 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 spending a lot less money. But what happens if your support bot is not resolving the requests,right?

So this is a study from BrainTrust, an 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, yeah, the result. And also, if you look at the TaoBench, what we must understand is that a model that passes 60% of the time is only self-consistent about a quarter of the time, which basically means that one replay is just an anecdote, and having a cohort analysis is way, way, way better

because then you can really see across a population and across scale what would have happened, not just looking at one estimate. 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.

And this you can really bake into your production process as well,right? So again, if you take a step back and look at the playbook, you can start from real runs, not synthetic, but real runs, real production checkpointed state, build cohorts that matter.

Maybe take the expensive ones, maybe take the long ones, maybe take the risky ones. Never ship anything by just replaying one or two things and just do this at scale, and ship, route, and hold, and try to automate that loop as much as possible.

Maybe there's an agent that's doing that for you. That's even better, where you just have a human in the loop at the end. Where you just have a human in the loop at the end. Now, let's see where our cohort analysis has gotten.

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.

But this might be different for your data.

In conclusion,

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?" 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.

If you want to use Kitaru, the tool that I showed that allows you to do it, you can scan the repo. It's open source, free to use, and we'd appreciate the feedback and love. Thank you so much, and see you guys on the next one.