Every step you take, every call you make: the reliable agent stack — Giselle van Dongen, Restate

A question-answering model can finish in seconds. A tool-using application may stay active for a session. The next step is harder: persistent, asynchronous agents that remain in an organization’s infrastructure, use tools and context, and communicate with other agents. Once work becomes long-running, stateful, and distributed, the surrounding infrastructure must survive failures and connect components that no single agent SDK owns.

Agent SDKs and memory can accelerate a proof of concept, but production systems still need retries, recovery, state consistency, communication, and operational control. Restate is presented as an open-source foundation for those backend concerns rather than an agent framework. Its ideas draw on Apache Flink and work by architects associated with Meta’s event infrastructure.

The infrastructure layer has four distinct jobs. Durable execution preserves a run through failure instead of restarting a week-long task. Session consistency lets thousands of conversations proceed without corrupting one another’s state. Distributed communication connects agents, MCP servers, and tools. Execution control stops work that is stuck or no longer wanted. Recovery preserves desired work; cancellation deliberately ends it.

Restate runs as a separate server in front of the agent service, acting somewhat like a proxy or message broker. It pushes an invocation to the service and keeps an open connection that van Dongen calls a “lifeline.” As the service works, operations emit events to Restate. Those events form a journal from which the execution can be reconstructed after a failure.

What relationship does that journal create between an ordinary request and a recoverable agent run? The flow below makes the persistence boundary visible: application work produces journal entries before later recovery depends on them.

The result is intended to feel like an ordinary application function while gaining long-running execution and state. The demonstration applies that model to a Slack research agent available to employees inside a company.

The concrete example begins when a user asks Slack, “What is new in AI?” Restate’s UI shows the corresponding execution. A planner first calls an LLM and returns proposed research subtopics. Clicking Approve unblocks the workflow, launches parallel research agents, and eventually hands their output to a writer agent. Planning, authorization, parallel research, and synthesis are separate stages of one durable run.

An injected failure makes the recovery mechanism observable. One subagent completes an LLM call, begins web searches, and encounters a search API outage. The failed search retries and later completes successfully. The surrounding research does not restart because the journal already records the run’s progress; recovery returns to the failed operation rather than discarding earlier work.

In code, the application unit is an HTTP handler using the Restate SDK. Its Restate object context represents the connection to the server, and operations performed through that context create journal events. The planner’s Python LLM function becomes a durable step when wrapped in restate.run. If the process fails much later, the journal supplies the recorded execution point from which it can continue.

Durability also handles intentional inactivity. A human approval may take weeks or a month, spanning service restarts and redeployments. Keeping a conventional function active for that entire period would tie the workflow’s lifetime to one process invocation.

Restate instead creates a durable promise in the journal. The promise marks a suspension point; Slack presents the approval button, and the function suspends while it waits. On serverless infrastructure, van Dongen says the suspended process consumes no function execution time. When approval arrives, the promise resolves and execution resumes where it stopped. The claim concerns serverless execution time during the wait, not the absence of storage or platform operating costs.

This works well for a sequence of durable steps, but a persistent agent needs more than a workflow-shaped history. It also needs an identity, memory, and a way to accept new input while work is already underway.

Restate models that persistent entity as a virtual object, similar to a stateful actor. Each object has a unique key such as a session ID, isolated key-value state such as message history, and handlers that can run durable functions for the session. A user can therefore add context while research is underway instead of waiting ten minutes for the first run to finish.

Isolation alone does not prevent two messages in the same session from racing. If both handlers updated the same conversation state concurrently, one could overwrite the other. The session controller prevents this by allowing one execution at a time for a given object key; another execution waits in a queue behind it. Separate sessions can still run concurrently, but serialization within one session trades some per-session latency for consistent updates.

A session ID addresses persistent conversation state. A separate execution ID addresses one active run. Other processes can use that execution ID to retrieve output, send a signal containing new state, or cancel the run. Together, the two identities let a controller remember the conversation while directly contacting the particular research execution already in flight.

The application adds an LLM classifier on top of those control primitives. When a new Slack message arrives, the classifier asks whether it is relevant to the current research. Relevant context is sent as a signal; unrelated context causes cancellation followed by a new run. Restate supplies addressability and control, while the classifier makes the application-level routing decision.

The first follow-up—“focus on frontier models”—stays within the original “What is new in AI?” assignment. The controller classifies it as relevant and injects it into the active loop. The UI then shows the message entering the research execution, which takes the added focus into account and starts its work again. The talk does not evaluate classifier accuracy or establish precisely how much prior research is reused after this signal.

The second follow-up changes the assignment: “Forget about that. Research AI policy.” The coordinator cancels the existing run and starts a new one. Cancellation travels through the call chain, stopping spawned subagents before the controller unwinds. This can give application code an opportunity to roll back, but stopping execution does not by itself reverse external effects that have already completed.

What decides whether a live run is amended or replaced? The comparison below separates the classifier’s semantic choice from Restate’s execution mechanisms.

Production requirements rarely stop changing after the first deployment. If a newly adopted model is good but expensive, an inline LLM call offers no convenient place for organization-wide controls. Restate’s programming model allows that call to move from a local Python step into a separate handler without changing the broader durable-execution model.

That handler becomes an LLM gateway. It can run a policy check before calling the provider, while agents invoke it through Restate’s distributed communication primitives. Flow control can then limit one department to 300 simultaneous calls. This bounds concurrency rather than total spending, but it creates one enforceable location for policy and capacity controls instead of duplicating them across every agent.

Van Dongen also presents the foundation as able to recover from infrastructure failures such as network partitions and zombie failures. Those capabilities are stated here rather than demonstrated; the demo’s directly observable recovery case is the failed web-search retry.

Under the SDK, Restate uses an event-driven distributed log between clients and services. The log persists journal events, while an event loop interprets them. Depending on the event, it may update an embedded state store, set a timer, or send a request to another agent. The same substrate therefore backs recorded function steps, session state, suspension points, and distributed calls.

What turns the journal into actual application behavior? The diagram shows the event loop dispatching persisted events into three different effects rather than treating the log as passive history.

A notable architectural choice is push-based invocation. Van Dongen contrasts it with workflow workers polling a server for new tasks: Restate sends the request directly to the target service, which also fits serverless functions that wake on incoming requests. She reports 45 milliseconds at p99 for a 10-step workflow, but supplies no benchmark setup, workload, or deployment conditions, so the figure should be read as a reported example rather than a general latency guarantee.

The server packages the state store and UI in one binary. A highly available deployment is described as multiple instances snapshotting to object storage, although the talk does not detail replication, coordination, or restoration. Adoption options include six SDKs, integrations with popular agent frameworks, direct use with arbitrary LLM SDKs, open-source self-hosting, deployment into a customer’s cloud account, and a managed cloud. Keeping Restate in the customer account can keep this layer’s data there; external tools and model providers remain separate data paths.

The closing lesson is narrower than “use a workflow engine for every agent.” Persistent agents need recoverable steps, addressable sessions, communication with live work, and a reliable way to stop it. Putting those mechanics beneath the agent loop lets the application evolve—from an inline LLM call to a governed gateway—without rebuilding retries, state management, and control each time.