Talk by Giselle van Dongen (Restate) on durable execution infrastructure for AI agents. She argues that teams repeatedly rebuild core plumbing badly — retry logic, recovery, session isolation, and cancellation — and shows how Restate addresses this as a server proxying requests in front of an agent service. Agents emit events to a journal that replays a failed process back to its exact failure point instead of restarting. Design draws on Apache Flink and Meta's event infrastructure, using pushed invocations rather than polling for low latency. The demo features a deep research agent in Slack with a planner and parallel sub-agents, including a simulated tool failure retried via web search. Sessions are modeled as virtual objects with isolated state, enabling mid-run signaling (changing the research focus) and cancellation that unwinds the call chain, killing sub-agents before the controller. Also covers making a single step durable in code, suspending a run for long durations (e.g., awaiting human approval), and the underlying distributed log. # Video Identity Observations — "Every step you take, every call you make: the reliable agent stack" (Giselle van Dongen, Restate) ## Speaker / Channel Affiliation - The presenter identifies as representing **Restate**, an open-source durable-execution framework: *"today I want to talk about an open-source framework called restate."* - The talk is a **conference presentation** (evidence: closing line *"I will be outside in front of the conference hall here if you want to ask any questions"*), not a typical studio-produced channel video. - Hiring solicitation suggests an organizational presence: *"We are hiring across the board for all sorts of roles going from engineering to marketing, especially also here in the Bay Area."* ## Intended Audience - **Engineers building or operating AI agents in production**. The talk opens by scoping the topic: *"This talk will be about how to run agents reliably in production… the infrastructure layer basically."* - Audience is assumed to have backend/distributed-systems familiarity — references to *Apache Flink*, *Meta's core event infra*, *network partitions and zombie failures*, and *serverless* function costs are used without basic explanation. - The framing *"Imagine we are like working at some company and we want to make a Slack agent available to all of our employees"* targets **team/enterprise deployers**, not hobbyists. ## Claimed Scope / Self-Description - Restate is positioned as **general-purpose infrastructure, not agent-specific**: *"It's not specific for agents but as agents are also just a type of a backend it also works well for them."* - Described as a **"flexible durable foundation"**: *"It doesn't really peg you into a specific way of how you should write your application."* - Lineage claims: *"The ideas behind restate come from Apache Flink… and also from some of the ex-architects behind Meta's core event infra."* - Delivery model claims: open source with self-hosting, BYOC (*"data doesn't leave your cloud account"*), and a managed cloud offering. - Ecosystem claims: *"restate has six different SDKs. We also have integrations for most of the popular agent frameworks out there."* ## Demonstrated Presentation Patterns (Observable) - **Demo-heavy format**: *"my talk today will be mainly a demo"* — includes a live Slack research agent, a Restate UI walkthrough, and code walkthroughs in Python. - **Architecture transparency**: internal design (event-driven distributed log, push-model invocation, embedded state store, single binary) is explained in detail with claimed latency figures (*"45 milliseconds p99 for like a 10-step workflow"*). - **CTAs at close**: GitHub repo, careers page, and in-person follow-up — consistent with a company/evangelist talk. ## Explicit vs. Demonstrated — Distinction Notes - **Explicit claims** (creator statements): product capabilities (durable execution, virtual objects, flow control, six SDKs), performance numbers, Meta/Flink lineage, hiring status. - **Demonstrated**: live UI showing journal events, injected tool errors with retry, human-approval suspension, session-state isolation, and signaling/cancellation of a running agent loop — these are shown, though within a pre-prepared demo environment. ## Credibility Signals / Caveats - Performance and capability claims are **vendor self-reported**; no independent verification appears in the material. - The talk cites an external third-party framing (Karpathy's "three waves" description) for context, which the presenter attributes explicitly rather than claiming as original. # Delivery Observations — Giselle van Dongen, "Every step you take, every call you make: the reliable agent stack" ## Overall Delivery Shape - **Demo-driven structure**: The speaker announces early that the talk is "mainly a demo" and then alternates between live UI/code walkthroughs and slide-based explanation, ending with architecture internals and a hiring/community plug. - **Framing move**: Opens by scoping what the talk is *not*: "It will not be about the eile part" — a boundary-setting habit that recurs ("So the reason why I showed this was just to show you a bit like that"). ## Recurring Linguistic Patterns ### Analogy-based explanation This is the most stable pattern. Nearly every technical concept is introduced via a comparison: - Restate's positioning: "you can see it a bit as a flexible durable foundation" - Proxy role: "it sits there a bit like a like a message broker or a proxy" - The connection: "that connection will basically be a bit like a lifeline for the agent" - The UI: "a bit like a cockpit for your agents" - A durable promise: "a bit like a suspension point" - A virtual object: "a bit like a stateful actor" The phrase **"a bit like"** appears repeatedly (at least 6 times) — a clear verbal signature. ### "Basically" as a discourse filler Used very frequently to introduce simplifications or summaries: "So the infrastructure layer basically", "the way that you can think of it is as follows. Restate is basically a server", "this cancellation is basically like a signal", "by doing that you basically have a durable um foundation". ### "So" as a transition marker Most new sections begin with "So": "So when we look at the types of tools", "So today I want to talk about", "So the way that you can think of it is as follows", "So let me show you in the deep research agent again". ## Teaching Habits - **Concrete imagined scenarios before abstractions**: e.g., durable execution is motivated by "when an agent runs for a week and then crashes", concurrency by "Imagine running thousands of concurrent agent sessions", and the LLM-gateway section by a hypothetical where "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". - **Escalating progression**: Concepts are built in layers — single-run resilience → concurrency → communication → control; later, workflow → virtual object → service fabric. - **Live-demo narration with hedging**: Demo commentary is tentative and observational: "Now if I press here approve then this will unblock the workflow", "it should respond again with a plan", "Once this comes back, it will probably decide that it should signal it". - **Explicit signposting between sections**: "Now let's have a look at what this looks like in code", "Okay, so this went a bit more into the direction of like stateful persistent entities... Now the last part of the demo". ## Vocabulary & Content Cues - **Vendor-affiliated but technically framed**: "So the reason why I showed this was just to show you a bit like that. Uh it's basically just a a resilient foundation." - Domain vocabulary used repeatedly and consistently: **durable execution**, **journal**, **recover/recovery**, **suspend**, **virtual object**, **signal**, **cancel**. - Precise numbers appear occasionally: "45 milliseconds p99 for like a 10-step workflow", "300 calls to this LLM gateway at the same time", "six different SDKs". ## Fluency & Fillers - Frequent **"um"/"uh"** fillers and self-corrections: "needing needing to make sure", "let bring it back", "each other each other's session state" — suggests partially improvised narration, especially in demo portions. - Hedges soften claims: "not necessarily", "doesn't really peg you into a specific way", "it's actually a pretty interesting um design". ## Isolated Moments vs. Stable Patterns - **Stable**: analogy habit ("a bit like"), "basically"/"So" fillers, demo-then-code structure, scenario-first teaching. - **Isolated**: the Andrej Karpathy "three waves" framing appears once as scene-setting and is not returned to except one brief callback ("also the way that Karpathy described it in the tweet"). The hiring/careers close is a one-time event, not a delivery pattern. ## Uncertainty Notes - Tone (e.g., warmth, nervousness) can't be reliably judged from a transcript alone; filler density suggests informal, spoken-style delivery, but pacing, gesture, and audience interaction are unobservable here. - "eile" in the opening line appears to be a transcription artifact (likely "LLM"); quoted as-is above where referenced. # Position Record: "Every step you take, every call you make: the reliable agent stack" — Giselle van Dongen, Restate ## Framing & Scope - The talk is about **running agents reliably in production** — specifically the **infrastructure layer**, not the LLM/agent logic itself. - Van Dongen cites a recent quote from **Andrej Karpathy** describing three waves of LLM interaction: 1. LLM as a **website** (ask a question, get a response). 2. Agents as **downloaded apps** with tools and human interaction. 3. Agents as **persistent, asynchronous, long-running processes** in an organization's infrastructure with access to tools, other agents, and context. - Claim: as use cases move from **single agents to agentic platforms**, infrastructure must evolve too. - Gap identified: agent SDKs and memory tooling are good for quick starts but "don't necessarily help with connecting the distributed bits around an organization"; complex agentic systems require extra deployed infrastructure — **retry logic, recovery logic** — which is "completely necessary" and "pretty complex to get right." ## The Proposed Solution: Restate - **Restate** is presented as an open-source framework: "a flexible durable foundation that lets you build any backend" — not agent-specific, but suitable since agents are a type of backend. - Stated lineage: ideas come from **Apache Flink** and from ex-architects of **Meta's core event infrastructure**. ### Four claimed ingredients 1. **Durable execution** — a crashed long-running agent resumes exactly where it failed, not from the start. 2. **Many concurrent sessions** — thousands of parallel sessions with consistent, non-interfering state. 3. **Communication** — between agents, agents and MCP servers, and other tools. 4. **Control** — ability to cancel or kill stuck or unwanted executions. ### Architecture as described - Restate runs as a **server/proxy in front of the agent service**; the connection acts as a "lifeline." The agent sends **journal events** to Restate, which uses the journal to recover after failure. - Implementation: an **event-driven distributed log** with an event loop that either persists state in an embedded state store, sets a timer, or forwards requests to other agents. - The distributed log design is "heavily inspired" by Meta's core event infra layer. - **Push model** claim: unlike most workflow orchestrators that pull tasks, Restate pushes invocations, yielding lower latency (claimed example: **45ms p99 for a 10-step workflow**) and good fit for serverless. - Shipped as a **single binary** including state store and UI; high availability via running multiple instances snapshotting to object storage. ## Demo Claims - Demo: a Slack-connected **deep research agent** (planner → parallel sub-research agents → writer), observable in the Restate UI ("cockpit for your agents"). - Injected tool failures (a web search API down) shown **retrying and completing** rather than restarting. - Code model: HTTP handlers made durable via the Restate SDK; actions on a `RestateObjectContext` emit journal events; wrapping calls (e.g., an LLM call) in `restate.run` makes them durable — "if this fails... two hours or two months later it will recover to exactly that point." - **Human-in-the-loop**: durable promises in the journal act as suspension points; a process awaiting weeks-long approval suspends (no serverless execution time billed) and resumes on response. ## Virtual Objects & Interaction - Claim: workflows don't fit Karpathy's third wave; agents are better modeled as **virtual objects** — stateful actors with a unique ID (e.g., session ID), isolated key-value state (e.g., chat history), and durable handlers. - **Single-writer guarantee**: only one execution per object runs at a time; second executions are queued, preventing agents from overwriting each other's session state. - **Signaling and cancellation**: executions have unique identifiers connectable from other processes — retrieve output, cancel, or inject state into a running agent loop. Demo: a coordinator LLM classifies new Slack input as relevant (signal/inject) or not (cancel and restart with new info). Cancellation propagates down the call chain, cancelling sub-agents first and "rewinding the stack." ## Extensibility Example - Scenario: a new, expensive model causes rising costs months into production. Claim: Restate "doesn't peg you into a specific way" — LLM calls can be pulled from inline steps into dedicated **LLM gateway handlers** with policy checks, invoked via distributed communication primitives, with **flow control** (e.g., a department limited to 300 concurrent gateway calls). - Claimed recovery coverage: even advanced failure modes — **network partitions and zombie failures**. ## Ecosystem & Deployment - **Six SDKs**; integrations with "most of the popular agent frameworks"; any LLM SDK usable for custom agents. - Deployment: open source/self-hosted, **BYOC** (deployed in customer's cloud account, data stays there), and **managed cloud**. - Closing: public GitHub repo; Restate is hiring across roles, especially in the Bay Area. ## Caveats on This Record - All capability claims (latency figures, recovery guarantees, inspirations from Flink/Meta) are the **speaker's own assertions** in a promotional/demo context; no independent verification is presented within the talk. - The transcript renders "Andre Apathy" (likely Andrej Karpathy per context); attribution preserved as stated. # Speaker Attribution Record ## Video **Title:** *Every step you take, every call you make: the reliable agent stack — Giselle van Dongen, Restate* **Video ID:** `01a15ca7-670e-7c40-a828-3449cdc1f304` ## Speakers - **Giselle van Dongen** — **Solo presenter / creator of talk**, speaking throughout the entire transcript. Affiliated with **Restate** (first-person references: "We are hiring", "We also have a BYOC offering"). Role: **speaker / company representative**. - No guests, narrators, or other speakers identified in the transcript or metadata. ## Referenced Sources and Third-Party Claims - **Andrej Karpathy quote** ("of last week") — describes three waves of LLM/agent interaction (website → app → persistent asynchronous entities). Quoted/paraphrased by the speaker; original source (tweet) referenced but not read verbatim in transcript. - **Apache Flink** — cited as inspiration for Restate's ideas (popular distributed stream processing engine). - **Meta's core event infra** — Restate's distributed log design stated as an iteration on Meta's core event infra; "ex-architects behind Meta core event infra" credited as designers. ## Promotional Segments (Flagged) - **Closing promotional block** (near end of transcript): promotion of Restate's offerings — open source, self-hosted, **BYOC**, **managed cloud**. - **Hiring announcement**: "We are hiring across the board... engineering to marketing, especially... Bay Area," directing to careers page and in-person follow-up. - **Project promotion**: GitHub repo for demo code and the Restate repo referenced as calls to explore/contribute. ## Demonstrated Content (Speaker's Own Demo) - Live demo of a **Slack-connected deep research agent** (planner agent, sub-research agents, writer agent) built on Restate; injected tool failures shown with retry behavior. ## Availability and Uncertainty - **Comment availability:** Not stated in transcript or metadata. - **Curated metadata:** None supplied beyond title/transcript. - Speaker name taken from title attribution only; no independent confirmation in transcript. Hi everyone. This talk will be about how to run agents reliably in production. It 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. So the infrastructure layer basically. I want to set the scene with this uh quote of Andre 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 towards persistent and asynchronous entities. So agents being longunning 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 uh the organization our infrastructure layer should also 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 PC's 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 um you have to deploy extra infrastructure. Uh 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. 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 for agents but a as agents are also just a type of a backend uh it also works well for them. The 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. 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 an 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 um 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 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. 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 or 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 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. So my talk today will be mainly a demo. So I'll be showing you um a research agent that is connected to Slack. Imagine we are like working at some company and we want to make an Slack agent available to all of our employees. So if I go here into Slack then can I can here 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 uh 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 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 um 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 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 and 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. I don't know if uh there were some errors. I injected a bit of like tool errors in here. Yeah, 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. 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 a first argument we have a restate object context and the way you can imagine that is basically as that uh connection to that restate server. whenever I do an action on this uh restate object, it will lead to an event being sent to restate. 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 um light lm like LLM call and the way I made it durable is by wrapping it in restate.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 exactly 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 um to survive restarts and redeploys uh over those kind of long periods of time and so with durable execution you can actually also uh suspend a function and let 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 we create a durable promise which lives in that journal a bit like a suspension point. Then 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. So if it's running on serverless this is not using uh execution uh 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. Um, 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 10 minutes to give it some follow-up context or maybe I think about something else that I should have told it. Um I want to actually be able to interact with it, not wait till that research is finished before I can send a 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 uh some key value states that is isolated for that specific session that you can write to. Uh 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. So here the way I implemented this use case that I mentioned of interacting with a running process is as follows. This is a um a bit a session controller. Again, it has like this restate object context at its disposal to do things in a recoverable way. Uh it can write to this session store. Here it 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 uh 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 other 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 cued 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 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. And 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. So 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 than workflows. it goes a bit more towards like writing persistent stateful entities that can interact with each other and have memory at uh their disposal. So let me show you uh 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. Um 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 extra 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 uh 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 inject that new message into the ongoing agent loop. So let me show you in the deep research agent again. Um 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 over again. Here I can now for example also say something like uh forget about that research AI policy. And 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. And so this cancellation is basically like a signal that gets um sent down the stack of or the call chain. So 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 and give agents also the ability to roll back. Okay. 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 um 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 notice that this research agent is actually starting to cost a lot. These 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. 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 um 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 uh 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 um 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. Uh it's basically just a a resilient foundation. It makes sure that your process can uh recover from even a more advanced types of infrastructure failures, things like network partitions and zombie failures. And um 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 um design or architecture. So the way it's implemented is basically by having a 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 service 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 um 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. Uh it's basically like an iteration on top of that. Um and some of those architects are now have designed that for restate as an 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 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. So 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. Pushing invocations also works very well for serverless because they require you to basically uh send the request and wake up the function. So this design that I show here includes everything you need. It includes uh 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 also just use any LLM SDK and implement custom agents by just wrapping some steps into uh these SDK constructs. So, it's open source. You can self-host it. We 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. Otherwise, there's also a managed cloud offering. This was mainly what I wanted to show. If you want to explore the code a bit further, there is here this the GitHub repo. It's publicly available. If you like the project, then have a look at the restate repo itself. We are hiring across the board for all sorts of roles going from engineering to marketing, especially also here in the Bay Area. So, if you're interested in that, uh, then definitely check out our careers page. and I will be outside in front of the conference hall here if you want to ask any questions or learn more about restate. Thank you very much. \>\> \[music\]