AI Engineer World's Fair 2026
Your Agents Need a Save Button
Read the talk
Your Agents Need a Save Button
Checkpointed execution lets you change a model or tool response, replay from that point, and compare outcomes before deciding whether a cheaper agent is worth shipping.
From a talk by Hamza Tahir
Before you start: Familiarity with tool-calling agents, execution traces, and basic Python will help you follow the replay examples.
Why did the agent do that?
Why did an agent make that decision? Would another model have reached the same result more cheaply? Would a different tool response have changed what happened next? These questions require more than an explanation of the completed run: they require a way to resume it under changed conditions. Hamza Tahir’s starting analogy is the familiar save button. Documents retain state as we work; an agent needs an equivalent checkpoint if we want to revisit a decision.
A trace records emitted telemetry: tool calls, inputs, outputs, and spans. But the trace alone does not necessarily retain the variables, files, executable code, and environment that produced those events. In Tahir’s framing, the missing connection is between observability spans and executable state. A read-only record in an observability backend can show what happened without providing what is needed to run the computation again.
Once that state is available, replay supports several distinct experiments:
- Model substitution: try a cheaper model and inspect its subsequent decisions.
- Tool substitution: override a tool’s return value to test a different policy or external response.
- Failure injection: deliberately degrade a tool response and observe how the agent handles bad information.
Each experiment needs a retained starting point so the changed execution can be compared with what originally happened.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn production checkpoints into evaluations
The architectural move is to put a durable runtime beneath the agent harness and connect its saved execution state to the traces. The harness still coordinates the agent; the runtime retains the material needed to resume its work. With automatic checkpoints during production execution, the system accumulates both the original behavior and starting points for later experiments.
Consider a support agent handling a chargeback dispute and a possible refund. A replay can test whether an order-status response in another language changes the outcome, whether the request should have escalated, or whether a smaller model could have handled it. Successive checkpoints act like autosave: the experiment can begin near the relevant decision instead of reconstructing the whole interaction.
That leads to an evaluation loop:
- Select a cohort of production runs—for example, runs that cost too much or took too long.
- Replay a specific change from saved state.
- Diff the new executions against their original baselines.
- Use the differences to decide what to route or ship.
The distinction matters: these are evaluations using production checkpoints, not merely a collection of production traces. The baseline tells you what happened; the checkpoint lets you test what could happen under an intervention.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Ground simulations in production behavior
Tahir introduces DoorDash as an example of using simulated customer conversations to test changes against production behavior. Its order-status validation compared 302 simulated conversations in five minutes with 175 production conversations collected over seven hours. Escalation rates were 46% in simulation and 44% in production—a two-percentage-point difference in escalation, not a measure of overall accuracy.
DoorDash separately reported 90% fewer hallucinations in simulations. These results concern its particular simulation system and validation exercise. Production-derived scenarios, simulated customers, and mocked dependencies can make experiments useful without establishing that the system restores runtime checkpoints or uses Kitaru. The relevant connection is grounding what-if experiments in interactions that have already occurred.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Inspect what a checkpoint retains
The live demonstration uses Kitaru, developed by ZenML, where Tahir identifies himself as a co-founder. In the demonstrated architecture, Kitaru supplies the runtime beneath the harness, connects execution to traces, and supports checkpoint-based replay. This is the earlier runtime workflow; the later product reorganized execution around sessions and Workers, so current commands should not be substituted for the recording’s interface.
The example application is a support agent that processes customer requests and escalates to a human when necessary. Its execution view shows tool calls and a timeline. Selecting a checkpoint exposes the configuration, code, and input/output artifacts associated with that step. Tahir also describes the execution environment, such as a Docker image or sandbox, as part of the saved context. That description should not be read as a guarantee of automatic capture of arbitrary process memory or every filesystem dependency; the concrete replay mechanism here depends on retained checkpoint results and executable context.
The timeline also exposes how long steps took, including the tool calls surrounding model requests. That gives the first experiment a precise target: pick a point in the support execution and ask whether a cheaper model would make the same subsequent decisions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Change one part of the execution
For the first replay, Tahir selects an execution point, copies the replay invocation into his terminal, and changes the model to GPT-5 nano after a particular tool call. A new execution launches. The demonstrated fork skips its first three checkpoints because Kitaru already has their saved state, then resumes execution at the changed checkpoint. The unchanged prefix is reused; the suffix runs under the new model choice.
The result initially looks similar, so the next experiment changes a different variable. Tahir replaces the lookup-policy tool with another function in the codebase that returns a different policy, while holding the model constant. This separates the policy intervention from the model intervention: if downstream behavior changes, the comparison is no longer confounded by changing both at once.
A Python tool replacement can be a small function with the same calling contract as the original. For example, this policy override returns a modified copy while preserving fields outside the intervention:
python
from typing import Any
def lookup_policy_override(
original_policy: dict[str, Any],
) -> dict[str, Any]:
return {
**original_policy,
"requires_human_review": False,
}
The field here illustrates the substitution pattern rather than Kitaru’s CLI syntax or the demo’s exact policy schema. The replacement supplies a different tool result; the replay must still execute the agent’s downstream decision. Access to the code makes that intervention practical. In the demonstration, the second fork produces different logs and an altered artifact, leaving three executions to compare: the baseline, the model fork, and the policy fork.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Compare decisions, not just trace shapes
Kitaru’s diff command takes the original execution ID and the replay IDs, then produces a URL for a side-by-side comparison. The command emits some artifact warnings before the comparison page opens. In the execution view, the saved prefix remains identical across branches. The policy fork diverges at the changed tool call, with differences in subsequent execution and timing.
Opening the final support_decision artifacts makes the behavioral difference explicit:
| Execution | Account charge | Review status | Next action |
|---|---|---|---|
| Baseline | Restricted | needs_review | escalate_to_human |
| Model fork | Restricted | needs_review | escalate_to_human |
| Policy fork | Restricted | safe_to_answer | answer_directly |
All three retain the restriction, but the policy fork changes whether the agent should answer directly. That is a substantive decision difference even when the executions look broadly similar. Whether it is acceptable depends on the intended policy.
Tahir describes both replay forks as cheaper in input/output token cost, without giving exact savings. The comparison view supplies more detail for analysis, but a lower cost does not establish that a changed review decision is correct. Nor does this single support case establish that the model substitution is safe across other requests.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Apply the intervention across a cohort
The next step is to select a collection of runs, such as the most expensive support requests, and apply the same intervention across matching configurations. The demonstrated replay-many operation resumes each execution from a selected point and changes either the relevant tool behavior or the model. The output is a distribution of outcomes rather than one promising example.
Tahir does not execute the cohort replay live because it would take time. Instead, he opens an already emitted JSON report. At this scale, manually comparing every branch in the UI becomes cumbersome, so he asks an agent to analyze the report using the Kitaru MCP server and recommend what to do across the cohort.
The useful capability is not just summarizing a large JSON file. A queryable runtime lets the analysis agent inspect executions and retrieve artifacts when it needs evidence about a decision. Skills and MCP access become more valuable as the workload grows from a handful of comparisons to thousands. The analysis begins looking for problematic decisions and continues in the background while Tahir returns to the presentation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A cheaper request can still be a worse service
A model swap can make an individual execution much cheaper, but Tahir says naive substitutions often fail in his experience with customers. A support bot that spends less while leaving requests unresolved may miss the product’s actual objective. Cost is one dimension; the value of the completed work is another.
The Braintrust cost-efficiency study provides a useful framing for this trade-off: assess support policies under explicit tool, safety, and response-quality requirements. The false economy is accepting inadequate resolution quality because a policy looks fast and cheap. It does not require claiming that cheaper models always have a higher dollar cost per resolved request; the matching study’s cheap-only policies still report a lower cost on that measure. The release decision needs a quality threshold as well as a cost comparison.
Repeated reliability adds another dimension. In the original τ-bench paper, GPT-4o with function calling achieved 61.2% single-trial success on retail tasks, while retail success across all eight trials was below 25%. This is pass^8 reliability: success on every trial for a task, judged by the final database state. It is not textual self-consistency or a universal rule converting a roughly 60% pass rate into a quarter.
One replay is an anecdote. Cohort evaluation exposes variation across requests, while repeated trials expose instability on the same task. Both matter when deciding whether a change is dependable. Replaying large workloads can itself become expensive, so selection needs to be deliberate: spend evaluation effort on the populations and decisions that matter to the service.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The cohort changes the release decision
An operational replay process starts with real production runs and checkpointed state. Build cohorts around expense, latency, or risk, rather than shipping after one or two favorable examples. The evidence should lead to a concrete decision: ship the change, route suitable requests to it, or hold it back. Automate as much of the loop as is useful, including agent-assisted analysis, while retaining a human at the final decision.
When Tahir returns to the completed cohort analysis, its recommendation is do not ship. The single model replay had appeared cheaper and reached a similar result, but the analysis across the demonstrated support cases recommends against using the cheaper model. That verdict applies to this cohort; another dataset could support a different decision. The demonstration does not provide a numerical failure breakdown, so the result is a cohort-specific recommendation rather than a general judgment about GPT-5 nano.
The architectural requirement is what makes that reversal discoverable: an agent harness backed by a runtime that can checkpoint state and replay it from code under changed scenarios. It lets the team test both alternate design choices and interventions in the agent’s behavior before deciding what belongs in production. Tahir closes by pointing to Kitaru’s repository and describing the tool as open source and free to use.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Open-source agent replay and evaluation software, with setup instructions, examples and MCP integration.
A support-agent experiment comparing model selection, retries and escalation through resolution quality and cost per resolved request.
The original retail and airline benchmark, including repeated-trial reliability measured with pass^k.
Further reading
- Kitaru’s original launchArticle
The original introduction to flows, checkpoints, persisted artifacts and replay with cached earlier results.
Updates since the talk
Hamza Tahir’s August 2026 account of imported sessions, reviewed cohorts, evaluators and the new worker execution layer.
Read the complete timestamped transcript
- 0:00
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?
- 0:10
Would it have been faster? Well, you can do all these things if your agents have a save button.
- 0:20
We've had the save button for documents for decades now. Since the nineteen eighties, people have been used to pressing Control S, Command S, uh, or auto-saving while you're working to have a persistent state.
- 0:34
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.
- 0:48
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
- 1:08
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.
- 1:28
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.
- 1:41
What are the types of questions you might wanna ask? Well, you might wanna swap the model. Maybe you use a, an open source model that is cheaper. Maybe you mock a tool and you override the, what it returns.
- 1:53
Maybe you degrade it intentionally to see what would happen if things are wrong.
- 1:58
And these sorts of questions are only possible if you have that state.
- 2: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, 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
- 2:26
to actually complete the state of this-- of the, of the system.
- 2: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.
- 2:46
Production already has the traces. It already has these state checkpoints,
- 2:53
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.
- 3: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, almost like an auto-save, a Command S, a Control S in your agent.
- 3:24
And once you have that, you can even close the loop. Uh, 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.
- 3:39
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.
- 3:51
That's closing the loop on your evals. It's, it's basically evaluating using your production traces.
- 4:01
So it's basically evaluating using your production checkpoints.
- 4: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. For example, DoorDash. DoorDash has, uh, a blog post on the first of June where they talk about having a simulated environment where they replayed customer bots and they've done what if scenarios and seen
- 4:32
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 five minutes, uh, with hundreds of simulations, have ninety percent less hallucinations, and they're still two points within what they've seen in production.
- 4:49
So the simulations are pretty good because they're grounded in what's already happened.
- 4:54
So we're gonna just walk through this, um, in an example, and we're gonna see how this works.
- 5:03
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.
- 5:17
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, um, and do all the checkpointing that we were just talking about, and then running replay scenarios.
- 5: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.
- 5:44
You can see various things as you might expect. Um, every tool call, uh, I can see a timeline view if I wanted. 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.
- 6:04
Um, and the artifacts, uh, which came in and out of it. 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.
- 6: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.
- 6: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?
- 6:42
So to do this in Kitaru, it's quite easy. All you have to do...
- 6:48
Now, to do this in Kitaru is very easy. All you have to do is you have to take your execution and replay it at a particular point. So I'm just gonna copy this over, and I'm gonna put it in my terminal and see what happens.
- 7: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 gonna happen here is
- 7:21
there's gonna be new execution that's launched from seventy-one, 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.
- 7:35
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.
- 7:47
So this looks pretty similar to me. But, um, what if I had wanted to do a even different change? What if I wanted to mock a tool or, or if I wanted to change a tool call?
- 7:57
Well, in order to do that, um, you can mock up, for example, the lookup policy tool. And here it's also very easy. I can just go back here,
- 8: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, uh, which returns a different lookup policy.
- 8: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
- 8:37
was completely disconnected from the code base. And here you can see that the code base is looking a bit different. So I see my logs here. Um, they look a bit different.
- 8: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. I have the original run, and I have the two replays.
- 8:57
Now, what if I wanted to see them side by side, right? So Kitaru, um, actually has this very handy diff command that lets me give an original ID of an execution and then allows me, um, on the other side to actually see them side by side so I can see what happened.
- 9:18
So there's a few warnings here, uh, 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.
- 9:31
And now I have a very nice, um,
- 9:36
comparison of the original and the two forks. 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?
- 9:47
So these things were skipped. They were exactly as it is. The state is exactly where it was. Um, but now right after that, in the third replay, it's a little bit different, right?
- 9:56
The tool call happened a bit differently because we used a different policy, and then something changed after here. Um, here it took a little bit longer. And you can really start looking at the final result.
- 10:07
And if I click on the final result, I can actually see the artifact side by side. I can see what decision, um, it actually ended up making. So you can see that it, uh, here it restricted the count charge.
- 10:20
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 if...
- 10:32
is this what you expected to see? Well, maybe. Because th- these two were cheaper at the end of the day. For, for, for the number of tokens consumed, uh, they were cheaper, input and output.
- 10:43
And you can see a bunch of detail here, uh, in the, in the UI, which might be useful for these ana-- for these analysis. Okay. But this is just one point, right?
- 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, and I wanted to do one change across the entire cohort.
- 11:11
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.
- 11:25
So this gives me a bigger distribution of information and replays that I can use. Um, and now I can just replay this. 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 we did before, just across the
- 11:45
cohort. Um, this is gonna take a while, so I'm not gonna do it now. But once you execute it, in this particular case, I've just emitted it to JSON.
- 11:55
So I have a very nice, uh, JSON
- 12:00
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.
- 12:09
Um, 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, read this JSON report and do an analysis on what you think I should be doing across the cohort."
- 12:29
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, ten is probably easy to do, but what if you have thousands?
- 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.
- 12:56
So it's going to be, it's going to be doing a lot of things. 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.
- 13:10
So while this is going on, um, maybe we can go back and continue our presentation. So, um,
- 13:21
here you can see, yeah. Yes, if you change the model, it can get very cheap. Um, and of course, you don't want to do it across just one sample, but across many, um, because then you can see a bigger variation.
- 13:37
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, um, having a naive model swap usually or oftentimes doesn't work.
- 13:52
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 bot is not resolving the requests, right?
- 14:06
So this is a study from Braintrust, uh, excellent study, where they actually looked at that, and they saw that there could be a false economy if you s- 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
- 14:20
created, right? So it's a trade-off between how much money you want to spend and, and, um, yeah, the result. Um, and also if you look at the tau bench, uh, what we must understand is that a model that passes sixty percent of the time is only self-consistent about a quarter of the time.
- 14:36
So, which basically means that one replay is just an anecdote, and having a cohort, uh, analysis is way, way, way better. Um, and because then you can really see across a population and across scale what would have happened, um, not just looking at one estimate.
- 14:56
Um, 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. Um, and this you can really bake into your production process as well, right?
- 15:10
So again, if you, if you take a step back and look at the playbook, you can start from real runs, um, not synthetic, but real runs, real production, uh, checkpointed state.
- 15:23
Build cohorts that matter. Um, maybe take the expensive ones, maybe take the long ones, maybe take the risky ones. Um, never ship anything by just replaying one or two things, um, and just do this at scale.
- 15:35
And, uh, 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, um, that's even better. But you just have a human in the loop at the end.
- 15:47
But you just have a human in the loop at the end.
- 15:50
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'd reach the same result, across a bunch of those support cases, you actually saw that our agent concludes that you shouldn't be using
- 16:09
a cheaper model in this particular case for your data. But this might be different for your data.
- 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?
- 16:34
Well, you can do this if you model your agent
- 16:39
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, the, the tool that I showed that allows you to do it, um, you can scan the repo.
- 16:55
It's open source, free to use, and, uh, we'd appreciate the feedback and love. Thank you so much and see you guys on the next one.