Your Agents Need a Save Button

Talk transcript

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

2. 0:10

   Would it have been faster? Well, you can do all these things if your agents have a save button.

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

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

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

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

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

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

9. 1:53

   Maybe you degrade it intentionally to see what would happen if things are wrong.

10. 1:58

    And these sorts of questions are only possible if you have that state.

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

12. 2:26

    to actually complete the state of this-- of the, of the system.

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

14. 2:46

    Production already has the traces. It already has these state checkpoints,

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

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

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

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

19. 3:51

    That's closing the loop on your evals. It's, it's basically evaluating using your production traces.

20. 4:01

    So it's basically evaluating using your production checkpoints.

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

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

23. 4:49

    So the simulations are pretty good because they're grounded in what's already happened.

24. 4:54

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

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

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

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

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

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

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

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

32. 6:42

    So to do this in Kitaru, it's quite easy. All you have to do...

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

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

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

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

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

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

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

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

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

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

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

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

45. 9:31

    And now I have a very nice, um,

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

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

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

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

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

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

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

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

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

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

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

57. 11:55

    So I have a very nice, uh, JSON

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

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

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

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

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

63. 13:10

    So while this is going on, um, maybe we can go back and continue our presentation. So, um,

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

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

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

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

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

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

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

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

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

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

74. 15:47

    But you just have a human in the loop at the end.

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

76. 16:09

    a cheaper model in this particular case for your data. But this might be different for your data.

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

78. 16:34

    Well, you can do this if you model your agent

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

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