# 🎵 Every step you take, every call you make - the reliable agent stack — Giselle van Dongen — session 2026-07-02T20:55:00.000Z → 2026-07-02T21:15:00.000Z

_51 transcript lines · 0 slides · source: full recording_

## Transcript

Hi everyone, this talk will be about how to run agents reliably in production. It will not be about the eval part, but it will be about all the other things you need to get going in order to run agents resiliently. So the infrastructure layer basically. I want to set the scene with this quote of Endrick Apathy of last week. It describes that the way we interact with agents and LLMs has been evolving in three waves. The first wave was an LLM being something like a website where we go to, we ask it a question, it thinks for a few seconds and then gives us a response. The second wave was going towards agents. It was an app that we download to our computer. It has some tools at its disposal and it can do some work with our interaction. Now the third wave will be going more and more to Parts persistent and asynchronous entities. So agents being long running processes in our infrastructure with access to tools and other agents around the organization and context. And so as our use cases are evolving more and more from single agents to agentic platforms that connect parts around, the organization, our infrastructure layer should To evolve with that. So when we look at the types of tools that are currently out there to implement agents, a lot of innovation has been done on sites such as agent SDKs and memory. And agent SDKs are really cool to implement POCs and get started quickly, but they don't necessarily help with like connecting the distributed bits around an organization. And if you want to implement more complex agentic systems, you actually need all of those things. So that is the layer that you see below here where, you have to deploy extra infrastructure. Sure, you need to write things like retrial logic, recovery logic, and all of that is actually pretty complex to get right, but completely necessary to run long running stateful and distributed processes in production. So today I want to talk about an open source framework called Restate and you can see it a bit as a flexible, durable foundation that lets you build any backend. So it's not specific. Pick for agents, but as agents are also just a type of a backend, it also works well for them. The ideas behind tree states come from Apache Flink, which is a popular distributed stream processing engine, and also from some of the ex architects behind Metascore Event Infra. So what are the ingredients in Restate? Basically four parts. First of all, it makes sure that a single run of an agent is resilient. This is called durable execution in the industry. Think about things like when Agent runs for a week and then crashes, we want to be able to bring it back and let it continue exactly at the point where it failed. We don't want it to start over from the beginning. Another, area here is running many concurrent sessions in parallel. Imagine running thousands of concurrent agent sessions at the same time and needing needing to make sure that state is always consistent and that different agents don't interfere with each other. And then going more towards things like Communication between agents, between agents and MCP servers and other tools. And finally also control. Making sure that when an agent, for example, is doing, something you don't want it to continue or when it's stuck being able to actually cancel or kill the execution. So the way that you can think of So the way that you can think of it is as follows. Restate is basically a server which runs in front of your agent service, so as a separate component. It sits there a bit like a, like a message broker. For a proxy. And when there's a request for your agent, Restate proxies the request to the service and pushes it to the service, basically. And from that moment, there's a connection, open connection between Restate and the agent. And that connection will basically be a bit like a lifeline for the agent. So as the agent is doing stuff, it sends events over to Restate and Restate will use that journal of events to recover the process after a failure. So from a slightly higher level, explanation you could say that it's turning a normal function in your application into something that is long running, durable, and stateful without having to do, a lot of the complex things you otherwise need to do for this. So my talk today will be mainly a demo. So I'll be showing you a research agent that is connected to Slack. Imagine we are like working at some company and we want to make a Slack agent available to all of our employees. So if I go here into Slack, then I can hear in this channel, for example, ask what is new in AI? Now let's have a look at what it's doing under the hood. So if I go back here, I have here the restate, UI. This is a bit like a cockpit for your agents. So you can see a registry of all the agents that are currently registered and you can also see, for example, which execution is currently happening. So here is the deep research agent. That I spinned up a few seconds ago. We can, see what it's currently doing now. It's called first an LLM and then it sent me an answer via Slack. This first LLM call was a planner agent. So what it did is it planned the research and sent me, a list of subtopics that it wants to research. Now if I press here approve, then this will unblock the workflow and will spin up a set of parallel research agents. So this is basically like The classical deep research workflow, right? You have a planner, then a set of sub research agents, and then finally someone, who writes a report on this, like a writer agent. And so this journal you see here on the left, that is basically the events that get sent from the agent to the restate server. And if this now crashes at some point, this journal is what will be used to recover the execution to the point where it failed. I don't know if there were some errors. I injected a bit of like tool errors in here. Yeah. Here you can for example see that, the sub agent first did an LLM call then started doing some web searches and eventually, one of the web searches didn't go through because the API was down. And then you see here on the right how it got retried and eventually completed successfully. So instead of starting over it uses the journal to recover the progress. Let's now have a look at what this looks like in code. So the basic unit of how you implement applications in Restate is by writing HTTP handlers and those handlers become durable by using the Restate SDK. So here in this case, we have here our deep research handler and here as the first argument we have a restate object context. And the way you can imagine that is basically as that connection to that restate server. Whenever I do an action on this restate object, it will lead to an event being sent to State. So for example, when I did that planner LLM call, what actually happened under the hood was it executed here this Python function. This is just a simple light, light LLM, like LLM call. And the way I made it durable is by wrapping it in restate dot run. So what happens is by doing these durable steps, if this fails somewhere here, two hours or two months later, it will recover to exact That point. So that's the idea of durable execution. You're always able to recover a process to where it was. You can also use that for other things, not necessarily for failure recovery. For example, imagine we want to ask a human to approve something and this approval might take weeks or a month. This process needs to be able to, to survive restarts and redeploys over those kind of long periods of time. And so with durable execution, you can Actually also suspend a function and bring it back when it's able to make progress. So in the case of a human approval, what we do here is basically we create a durable promise which lives in that journal, a bit like a suspension point. Then we ask a human to click that button in Slack, as I showed in the beginning, and while we are waiting, this process actually suspends. So if it's running on serverless, this is not using execution. And, time on our functions. Once the response comes in, this then gets unblocked and can continue where it left off. So what we see here is a bit like a workflow. It's a set of steps that get executed durably. But when we think about agents and also the way that Karpathy described it in the tweet, it's more like a persistent stateful entity that lives for a longer period of time, that has some memory. So a workflow is not the nicest way to model this kind of Thing. So the way that we can model this in restate is by using something called a virtual object. So imagine in the use case that I'm showing this Slack research agent, imagine that I don't want to wait for ten minutes to give it some follow-up context or maybe I think about something else that I should have told it. I want to actually be able to interact with it, not wait till that research is finished before I can send the follow-up. And so this is basically what a virtual Object in restate is, it's a bit like a stateful actor. It has a unique ID, for example, a session ID. It has, some key value states that is isolated for that specific session that you can write to. Imagine for example your history of messages. And it also has like a set of handlers that can execute durable functions for this session. So here, the way I implemented this use case that I mentioned of interacting With a running process is as follows. This is a, bit of session controller. Again, it has like this restate object context at its disposal to do things in a recoverable way. It can write to the session store. Here I'm retrieving the chat history. And one thing that's interesting there is that in order to run these kind of sessions in very high, paralyzed ways, so thousands of sessions at the same time, we need to make sure That agents do not interfere with each other. Imagine I'm sending two messages on Slack and now two agents are actually overwriting each each other's session state. To prevent that, this will guarantee that only one execution is running at a time. So a second execution will be queued behind the current one. Then let's have a look at How we implement this, like interacting with another execution. So an execution in reset has a unique identifier and you can use that identifier to connect to it from other processes. For example, to retrieve, the output but also to cancel it or maybe to signal it being injecting a bit of state into an already running agent loop. And so this is like a very flexible type of capabilities that you can do to implement things like for example signaling an already ongoing agent loop. What we do here is if there is a current execution ongoing, then we will, ask an LLM, is this like something that is relevant for the current agent loop? If that is the case, inject this via a signal. If it's not really relevant for what we're currently doing, then cancel what you're currently doing and start over again with this new information. And so this goes a little bit further. And workflows. It goes a bit more towards like writing persistent stateful entities that can interact with each other and have memory at their disposal. So let me show you, how this works. So here, if I now ask again what is new in AI and I wait a few seconds, then it should respond again with a plan. And then I can say, for example, some extra info, focus on frontier models, let's say. So once I have the plan, I will inject that bit of Press state. Now let's look at the UI of what this is now doing. So here I have that controller which I just showed. It started calling an LLM to classify, this new input. Once this comes back, it will probably decide that it should signal it because it's it's still relevant to the research it's currently doing. So this injects that new message into the ongoing agent loop. So let me show you in the deep Church agent again. So we first called an LLM, then asked us, then we injected this new message of focus on frontier models, and then it took that into account and started over again. Here I can now, for example, also say something like, forget about that. Research AI policy and if I send this then the coordinator We will, decide to cancel the ongoing run and start a new one that will research this new topic. And so this cancellation is basically like a signal that gets, sent down the stack of or the call chain. So if my agent was already spinning up sub agents, first the sub agents would be canceled, then, the controller itself and like that it would basically rewind the stack and give agents also the ability to roll back. Okay. So this went a bit more into the direction of, like, stateful persistent entities that we can interact with over longer periods of time. Now the last part of the demo that I want to show is, going more towards, like, being able to write highly customized applications. Imagine that we deploy this in production but then a few months later a new model provider brings out a new model, for example, Fabulous. And even though the model is very good, it's also very expensive and we note Is that this research agent is actually starting to cost a lot. These kind of things that pop up halfway through a project require you to then deploy a lot of new extra infra or like find a good way to solve this. This is the kind of things that Restate really excels at. It doesn't really peg you into a specific way of how you should write your application. It basically gives you like a durable programming model that lets you implement an application in the way that fits for you and also Extend it if necessary. So first I showed this, LLM call in the first example as an inline step. It was just a Python function that got persisted. But imagine this use case that we want to actually have a bit more control over those LLM calls. For example, what you can do is then pull this out into its own handler And this handler can now do things like, for example, a policy check and then, do the LLM call. And the other agents, instead of doing this LLM call inline, can now use restates like distributed communication primitives to actually just call this LLM gateway instead of doing it as an inline step. And this service fabric that lets you communicate between agents also gives you some, things like flow control. So we can, for example, say one department is only allowed to run 300 calls to this LLM gateway at the same time. So the reason why I showed this was just to show you a bit like that, it's basically just a resilient foundation. It makes sure that your process can recover from even the more advanced types of infrastructure failures, things like network partitions and zombie failures. And, it gives you, like, tooling to extend and customize as your use case grows. Let's Go back to the slides to have a little more of an idea of how this thing is actually implemented on the inside because it's actually a pretty interesting, design or architecture. So the way it's implemented is basically by having a event driven distributed log implementation. So inside the box, you basically on one side have the clients, on the other side the services, and inside the box is a log which persists all those journal events and an event loop. And that event loop basically gets the events from the server. Based on what the event is, it either persists some state in the embedded state store or it sets a timer or it sends a request to another agent. And by doing that, you basically have a durable foundation for whatever an application is doing. The design of this distributed log is heavily inspired by the way that the core event infra layer at meta works. It's basically like an iteration on top of that. And some of those architects are, now have designed that for restate as a more generic solution that is available in open source. There are two important things related to this architecture that make it interesting. The first one is that it works as a push model. So whereas most workflow orchestrators actually pull for new tasks, pull from the workflow server, Restate actually pushes the invocations and the benefit you get from that is that it has Much lower latency. So you can use these kind of workflow guarantees in functions around your application and, have like a latencies of, for example, forty five milliseconds p 99 for, like, a 10 step workflow. Pushing invocations also works very well for serverless because they require you to basically, send the request and wake up the function. So this design that I show here includes everything you need. It includes as well that State Store where we were embedding the state as the UI. It's a single binary, so it's pretty easy to operate as well. To run it in like a highly available way, you just spin it up multiple times and let it snapshot to object storage. So Restate has six different SDKs. We also have integrations for most of the popular agent frameworks out there and of course because it's just like a flexible layer you can And also just use any LLM SDK and implement custom agents by just wrapping some steps into, these SDK constructs. So it's open source. You can self host it. We also have a BYOC offering where we deploy restates in your cloud account and, that gives you the benefit that data doesn't leave your cloud account. Otherwise, there's also a managed cloud offering.

## Slides