Every step you take, every call you make: the reliable agent stack — Giselle van Dongen, Restate
AI Engineer · 20 min · 181 sentences · from YouTube's caption track
Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.
- 00:12Hi everyone.
- 00:13This talk will be about how to run agents reliably in production.
- 00:17It will not be about the eile part, but it will be about all the other things you need to get going in order to run agents resiliently.
- 00:25So the infrastructure layer basically.
- 00:28I want to set the scene with this uh quote of Andre Apathy of last week.
- 00:33It describes that the way we interact with agents and LLMs has been evolving in three waves.
- 00:39The 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.
- 00:49The second wave was going towards agents.
- 00:52It was an app that we download to our computer.
- 00:54It has some tools at its disposal and it can do some work with our interaction.
- 01:00Now the third wave will be going more and more towards persistent and asynchronous entities.
- 01:06So agents being longunning processes in our infrastructure with access to tools and other agents around the organization and context.
- 01:17And so as our use cases are evolving more and more from single agents to agentic platforms that connect parts around uh the organization our infrastructure layer should also evolve with that.
- 01:29So 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.
- 01:39And agent SDKs are really cool to implement PC's and get started quickly, but they don't necessarily help with like connecting the distributed bits around an organization.
- 01:51And if you want to implement more complex agentic systems, you actually need all of those things.
- 01:57So that is the layer that you see below here where um you have to deploy extra infrastructure.
- 02:03Uh you need to write things like retry logic, recovery logic and all of that is actually pretty complex to get right but completely necessary to run longunning stateful and distributed processes in production.
- 02:17So today I want to talk about an open-source framework called restate.
- 02:21And you can see it a bit as a flexible durable foundation that lets you build any backend.
- 02:27So it's not specific for agents but a as agents are also just a type of a backend uh it also works well for them.
- 02:36The ideas behind restate come from Apache Flink which is a popular distributed stream processing engine and also from some of the exarchitects behind Meta Score event infra.
- 02:49So what are the ingredients in restate?
- 02:51Basically four parts.
- 02:54First of all, it makes sure that a single run of an agent is resilient.
- 02:58This is called durable execution in the industry.
- 03:01Think about things like when an agent runs for a week and then crashes.
- 03:05We want to be able to bring it back and let it continue exactly at the point where it failed.
- 03:11We don't want it to start over from the beginning.
- 03:14Another um area here is running many concurrent sessions in parallel.
- 03:20Imagine 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.
- 03:31And then going more towards things like communication between agents, between agents and MCP servers and other tools.
- 03:38And finally also control, making sure that when an agent for example uh is doing um something you don't want it to continue or when it's stuck being able to actually cancel or kill the execution.
- 03:51So the way that you can think of it is as follows.
- 03:54Restate is basically a server which runs in front of your agent service.
- 03:58So as a separate component it sits there a bit like a like a message broker or a proxy and when there's a request for your agent restate proxies the request to the service
- 04:09and 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.
- 04:21So 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.
- 04:33So from a slightly higher level um 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 um a lot of the complex things you otherwise need to do for this.
- 04:49So my talk today will be mainly a demo.
- 04:52So I'll be showing you um a research agent that is connected to Slack.
- 04:56Imagine we are like working at some company and we want to make an Slack agent available to all of our employees.
- 05:03So if I go here into Slack then can I can here in this channel for example ask what is new in AI.
- 05:12Now let's have a look at what it's doing under the hood.
- 05:15So if I go back here, I have here the restate uh UI.
- 05:19This is a bit like a cockpit for your agents.
- 05:22So 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.
- 05:31So here is the deep research agent that I spinned up a few seconds ago.
- 05:36We can see what it's currently doing.
- 05:38Now it called first an LLM and then it sent me an answer via Slack.
- 05:43This first LLM call was a planner agent.
- 05:46So what it did is it planned the research and sent me um a list of subtopics that it wants to research.
- 05:53Now if I press here approve then this will unblock the workflow and will spin up a set of parallel research agents.
- 06:01So this is basically like the classical deep research workflow, right?
- 06:05You have a planner then a set of subress research agents and then finally someone uh 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
- 06:22and if this now crashes at some point this journal is what will be used to uh recover the execution to the point where it failed.
- 06:30I don't know if uh there were some errors.
- 06:33I injected a bit of like tool errors in here.
- 06:36Yeah, here you can for example see that um the sub agent first did an LLM call then started doing some web searches and eventually uh 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 retrieded and eventually completed successfully.
- 06:53So instead of starting over, it uses the journal to recover the progress.
- 06:58Let's now have a look at what this looks like in code.
- 07:02So 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.
- 07:13So here in this case we have here our deep research handler and here as a first argument we have a restate object context and the way you can imagine that is basically as that
- 07:24uh connection to that restate server.
- 07:26whenever I do an action on this uh restate object, it will lead to an event being sent to restate.
- 07:34So for example, when I did that planner LLM call, what actually happened under the hood was it executed here this Python function.
- 07:42This is just a simple light um light lm like LLM call and the way I made it durable is by wrapping it in restate.run.
- 07:54So what happens is by doing these durable steps if this fails somewhere here two hours or two months later it will recover to exactly that point.
- 08:05So that's the idea of durable execution.
- 08:07You're always able to recover a process to where it was.
- 08:10You can also use that for other things not necessarily for failure recovery.
- 08:15For example, imagine we want to ask a human to approve something and this approval might take weeks or a month.
- 08:22this process needs to be able to um to survive restarts and redeploys uh over those kind of long periods of time and so with durable execution you can actually also
- 08:34uh suspend a function and let bring it back when it's able to make progress.
- 08:40So in the case of a human approval what we do here is basically we we create a durable promise which lives in that journal a bit like a suspension point.
- 08:49Then we ask uh a human to click that button in select as I showed in the beginning and while we are waiting this process actually suspends.
- 08:58So if it's running on serverless this is not using uh execution uh time on our functions.
- 09:06Once the response comes in this then gets unblocked and can continue where it left off.
- 09:11So what we see here is a bit like a workflow.
- 09:14It's a set of steps that get executed durably.
- 09:18But 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.
- 09:29Um, so a workflow is not the nicest way to model this kind of thing.
- 09:34So the way that we can model this in restate is by using something called a virtual object.
- 09:40So imagine in the use case that I'm showing this slack research agent.
- 09:44Imagine that I don't want to wait for 10 minutes to give it some follow-up context or maybe I think about something else that I should have told it.
- 09:53Um I want to actually be able to interact with it, not wait till that research is finished before I can send a follow-up.
- 10:00And so this is basically what a virtual object in restate is.
- 10:04It's a bit like a stateful actor.
- 10:06It has a unique ID, for example, a session ID.
- 10:09It has uh some key value states that is isolated for that specific session that you can write to.
- 10:16Uh imagine for example your history of messages and it also has like a set of handlers that can execute durable functions uh for this session.
- 10:27So here the way I implemented this use case that I mentioned of interacting with a running process is as follows.
- 10:36This is a um a bit a session controller.
- 10:39Again, it has like this restate object context at its disposal to do things in a recoverable way.
- 10:46Uh it can write to this session store.
- 10:49Here it I'm retrieving the chat history.
- 10:52And one thing that's interesting there is that in order to run these kind of sessions in very high uh paralyzed ways, so thousands of sessions at the same time,
- 11:02we need to make sure that agents do not interfere with each other.
- 11:06Imagine I'm sending two messages on Slack and now two agents are actually overwriting each other each other's session state.
- 11:13To prevent that, this will guarantee that only one execution is running at a time.
- 11:19So a second execution will be cued behind the current one.
- 11:26Then let's have a look at how we implement this like interacting with another execution.
- 11:31So an execution in reset has a unique identifier and you can use that identifier to connect to it from other processes.
- 11:40for example, to retrieve uh the output, but also to cancel it or maybe to signal it being injecting a bit of state into an already running agent loop.
- 11:51And so this is like a very flexible type of um uh capabilities that you can do to implement things like for example signaling an already ongoing agent loop.
- 12:02So 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.
- 12:13If 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.
- 12:26And so this goes a little bit further than workflows.
- 12:29it goes a bit more towards like writing persistent stateful entities that can interact with each other and have memory at uh their disposal.
- 12:38So let me show you uh how this works.
- 12:40So 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.
- 12:49Um and then I can say for example some extra info focus on frontier models let's say.
- 12:59So once I have the plan I will inject that bit of extra state.
- 13:06Now let's look at the UI of what this is now doing.
- 13:09So here I have that controller which I just showed.
- 13:13It started calling an LLM to classify uh this new input.
- 13:19Once 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.
- 13:26So this inject that new message into the ongoing agent loop.
- 13:31So let me show you in the deep research agent again.
- 13:34Um so first it called an LLM then asked us then we injected this uh new message of focus on frontier models and then it uh took that into account and started
- 13:46over again.
- 13:47Here I can now for example also say something like uh forget about that research AI policy.
- 14:00And if I send this then the coord coordinator will um decide to cancel the ongoing run and start a new one that will research this new topic.
- 14:11And so this cancellation is basically like a signal that gets um sent down the stack of or the call chain.
- 14:20So if my agent was already spinning up sub agents first those sub aents would be cancelled then uh the controller itself and like that it would basically rewind the stack
- 14:30and give agents also the ability to roll back.
- 14:34Okay.
- 14:34Okay, so this went a bit more into the direction of like stateful persistent entities that we can interact with over longer periods of time.
- 14:42Now the last part of the demo that I want to show is um going more towards like being able to write highly customized applications.
- 14:50Imagine 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 notice that this research agent is actually starting to cost a lot.
- 15:06These kind of uh things that pop up halfway through a project require you to then deploy a a lot of new extra infra or like find a good way to solve this.
- 15:17This is the kind of things that Restate really excels at.
- 15:21It doesn't really peg you into a specific way of how you should write your application.
- 15:25It 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.
- 15:35So first I showed this um LLM call in the first example as an inline step.
- 15:42It was just a Python function that got persisted.
- 15:45But imagine this use case that we want to actually have a bit more control over those LLM calls.
- 15:51For example, what you can do is then pull this out into its own handler.
- 15:56And this handler can now do things like for example a policy check and then uh do the LLM call.
- 16:03And 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.
- 16:17And this service fabric that lets you communicate between agents also gives you some um things like flow control.
- 16:24So we can for example say one department is only allowed to run 300 calls to this LLM gateway at the same time.
- 16:33So the reason why I showed this was just to show you a bit like that.
- 16:37Uh it's basically just a a resilient foundation.
- 16:39It makes sure that your process can uh recover from even a more advanced types of infrastructure failures, things like network partitions and zombie failures.
- 16:50And um it gives you like tooling to extend and customize as your use case grows.
- 16:57Let'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
- 17:08um design or architecture.
- 17:11So the way it's implemented is basically by having a a event-driven distributed log implementation.
- 17:19So 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 service
- 17:34based on what the event is.
- 17:35It either persists some state in the embedded state store or it sets a timer or it sends a request to another agent.
- 17:42And by doing that you basically have a durable um foundation for whatever an application is doing.
- 17:50The design of this distributed log is heavily inspired by the way that the core event infra layer at meta works.
- 17:59Uh it's basically like an iteration on top of that.
- 18:02Um and some of those architects are now have designed that for restate as an more generic solution that is available in open source.
- 18:11There are two important things related to this architecture that make it interesting.
- 18:16The first one is that it works as a push model.
- 18:19So whereas most workflow orchestrators actually pull for new tasks um for pull from the workflow server, restate actually pushes the invocations and the benefit you get from that is that it has a much lower latency.
- 18:34So you can use these kind of workflow guarantees in functions around your application and uh have like a latencies of for example 45 milliseconds p99 for like a 10-step workflow.
- 18:48Pushing invocations also works very well for serverless because they require you to basically uh send the request and wake up the function.
- 18:58So this design that I show here includes everything you need.
- 19:03It includes uh as well that state store where we were embedding the state as the UI.
- 19:08It's a single binary so it's pretty easy to operate as well to run it in like a highly available way.
- 19:14You just spin it up multiple times and let it snapshot to object storage.
- 19:21So restate has six different SDKs.
- 19:24We also have integrations for most of the popular agent frameworks out there.
- 19:29And of course, because it's just like a flexible layer, you can also just use any LLM SDK and implement custom agents by just wrapping some steps into uh these SDK constructs.
- 19:42So, it's open source.
- 19:43You can self-host it.
- 19:44We also have a BYOC offering where we deploy restate in your cloud account and uh that gives you the benefit that data doesn't leave your cloud account.
- 19:54Otherwise, there's also a managed cloud offering.
- 19:58This was mainly what I wanted to show.
- 20:01If you want to explore the code a bit further, there is here this the GitHub repo.
- 20:05It's publicly available.
- 20:07If you like the project, then have a look at the restate repo itself.
- 20:11We are hiring across the board for all sorts of roles going from engineering to marketing, especially also here in the Bay Area.
- 20:18So, if you're interested in that, uh, then definitely check out our careers page.
- 20:23and I will be outside in front of the conference hall here if you want to ask any questions or learn more about restate.
- 20:30Thank you very much.
- 20:47[music]