Durable Agent
Why checkpointed, resumable execution is becoming the default for agents that do real work.
Why checkpointed, resumable execution is becoming the default for agents that do real work.
An agent that answers one question in ten seconds can live inside a web request. An agent that researches a market, waits for legal approval, updates a CRM, retries a failed API, and reports back tomorrow cannot.
That second agent is not a longer chatbot. It is a distributed system with a model in the loop.
If its process dies halfway through, what happens to the work it already completed? If a deployment lands while it waits for approval, who wakes it up? If an API times out after accepting a payment, can the agent retry without charging twice? If nobody can answer those questions, the agent is still a demo.
Durable execution is the layer that turns long-running agents from hopeful scripts into production systems. It persists progress, breaks work into recoverable steps, and lets an agent pause for minutes or weeks without holding a process open.
Our view is straightforward: durable execution is likely to become the dominant architecture for long-running asynchronous agents. Not because every agent needs it, and not because durability makes failures disappear. It will dominate because the work we expect agents to perform is naturally asynchronous, stateful, failure-prone, and full of human handoffs.
Durable long-running workflows have been something that the enterprise fintech community has been working on since multistep transactions appeared and is a perfect analogy to the existing agent problem.
An agent’s real runtime is not one model call
The clean demo loop looks simple:
Production adds everything the demo leaves out. The model provider throttles a request. A worker restarts. A tool returns a temporary error. A person needs to approve a refund. A webhook arrives six hours later. A deployment replaces the process that held the conversation in memory.
These are normal events, not edge cases. The longer an agent runs and the more systems it touches, the more opportunities it has to stop between intent and outcome.
A queue can keep a job from disappearing, but it does not automatically preserve the agent’s full position inside the job. A conversation database can save messages, but saved messages do not detect a dead worker, schedule retries, deduplicate side effects, or resume a suspended approval. Checkpointing alone is useful, but it is not the same as an execution runtime that drives recovery.
That distinction matters. An agent framework can remember what happened without guaranteeing that the work continues.
What durable execution changes
A durable runtime records the agent’s execution as it advances. The implementation varies, but the operating model is consistent:
The workflow starts with a stable identity.
Model calls and tool calls run as named steps.
Completed step inputs and outputs are persisted.
Timers, messages, approvals, and external events can suspend the workflow.
A worker can disappear while the workflow is waiting.
When work resumes, the runtime reconstructs state from durable history and continues from a safe boundary.
The result is not an long lived process. It is a process that no longer depends on one machine, container, or request staying alive.
That gives long-running agents four properties they otherwise have to rebuild by hand.
1. Progress survives infrastructure
Without durability, a crash near the end of a research task can throw away hours of tool calls and model spend. With durable steps, completed work remains completed. Recovery starts from recorded progress instead of from the original prompt.
This also changes deployment. The old runtime treats an in-flight agent as a process you are afraid to interrupt. The durable runtime treats workers as replaceable compute.
2. Waiting becomes a first-class state
Useful agents spend a surprising amount of time doing nothing. They wait for a manager, a webhook, a rate limit, a scheduled window, or another system.
Keeping a container alive for that wait is wasteful and fragile. Persisting the workflow, releasing compute, and resuming on an event is the correct asynchronous model. Human-in-the-loop control becomes practical because an approval can take days without turning the agent into an abandoned process.
3. Recovery becomes visible
A long-running agent needs more than application logs. Operators need to know which step ran, what it received, what it produced, why it retried, and where it is waiting now.
Durable execution creates a natural execution history. That history supports debugging, audit, cost analysis, and manual intervention. It also separates a slow agent from a dead one, which is much harder than it sounds in an improvised queue-and-database design.
4. Reliability policy moves into the platform
Retries, backoff, timeouts, compensation, cancellation, and concurrency control are distributed-systems concerns. They do not become model problems just because an LLM chose the next action.
A durable runtime gives those concerns one place to live. The model can remain probabilistic while the execution envelope stays explicit and testable.
Vercel’s eve shows where the abstraction is heading
Vercel introduced eve in June 2026 as an open-source framework for backend agents. Its most important design choice is not its filesystem structure or its TypeScript tools. It is that durability is the default.
In eve, every conversation is a durable workflow. Each step is checkpointed, so a session can pause, survive a crash or deployment, and resume where it stopped. An action can wait for human approval without consuming compute, then continue after the decision arrives. Scheduled agents also continue without an active user session.
Eve builds this on Vercel’s open-source Workflow SDK. Underneath, Vercel Workflows records an event history and coordinates step execution, retries, state, and streaming. The developer writes ordinary application control flow while the runtime supplies the recovery machinery.
This matters beyond Vercel. Eve is a signal that durability is moving up the stack. Developers should not need to assemble a queue, worker fleet, status table, approval service, retry engine, and recovery dashboard before their agent can safely run overnight. The framework can make the durable path the easy path.
Vercel is not alone.
Three approaches are converging on the same requirement
DBOS: durability inside application code
DBOS provides durable execution as an open-source library. Python functions become workflows and steps through decorators, with execution state backed by Postgres. Its example refund agent can wait for manual review and recover after a crash without operating a separate queue and external orchestrator.
DBOS also demonstrates an important separation of concerns. LangGraph can define the agent’s stateful control flow, while DBOS makes the business operations invoked by that agent durable. A graph describes where work may go. A durable runtime makes sure the work keeps going when infrastructure fails.
Microsoft: durability as execution infrastructure
Microsoft Agent Framework’s Durable Extension persists sessions, checkpoints workflow progress, recovers across distributed workers, and supports long human waits without consuming compute. Microsoft explicitly distinguishes this from basic checkpoint storage. Saving a checkpoint inside one runtime is not the same as recovering work across stateless hosts with Durable Task infrastructure.
Temporal: the established durable-execution model applied to agents
Temporal predates the current agent wave and would be the first thing that comes to mind when discussing durable workloads. Initially positioned for fintech and ecommerce, its in a great position with AI agents coming into prominence.
Temporal persists workflow history, retries failure-prone activities, supports long waits, and resumes work after process or infrastructure failure. Agent tool calls map naturally to activities, while the agent loop lives inside durable workflow logic.
The products differ in developer experience, hosting model, language support, and operational weight. Their shared direction is more important: long-running agent state belongs in an execution system, not only in memory or a chat-history table.
Agents are moving from answers to outcomes
A chatbot can finish when it returns text. An operational agent finishes when the external world reaches the intended state: the refund is processed, the incident is resolved, the report is reviewed, or the deployment is verified.
Outcomes take longer than requests. They cross service boundaries. They include side effects and waiting. Once agents own outcomes, durable coordination stops being optional plumbing.
Asynchronous work is the economically useful work
The high-value use cases are rarely single-turn. Customer onboarding, procurement, compliance review, incident response, software delivery, research, and back-office operations all span multiple systems and timelines.
These are exactly the workloads where an agent can save meaningful human effort. They are also exactly the workloads that expose an in-memory loop’s weaknesses.
Human control requires suspension, not blocking
Production agents need approval gates for consequential actions. A platform that cannot safely wait for a person forces teams into bad choices: remove the approval, keep expensive compute alive, or build a separate state machine around the agent.
Durable suspension makes safety compatible with long-running autonomy. The agent can move quickly through low-risk work, park at a boundary, and continue when authority arrives.
The abstraction is becoming cheaper to adopt
Durable execution used to imply a specialist orchestration platform and a second programming model. That option still has a place, especially for complex enterprise workflows. But Eve, DBOS, Vercel Workflows, and Microsoft’s extension show another path: durability embedded in normal application code or supplied directly by the agent framework/platform.
When the reliable path requires less custom plumbing than the fragile path, it becomes the default.
Model improvements do not solve execution failure
A better model may choose tools more accurately. It cannot stop a container from crashing, make a third-party API available, or reconstruct an approval that lived only in RAM.
This is why durable execution has staying power. It solves a systems problem beneath the model layer. Models will change rapidly. The need to persist state, recover work, and control side effects will remain.
What to require from a durable agent platform
Do not evaluate these systems by whether they have a checkpoint() function. Ask what happens after the worker disappears.
Automatic recovery: Who detects abandoned work and schedules it again?
Durable boundaries: Which model calls, tool calls, messages, and stream events are persisted?
Safe suspension: Can the agent wait for days without holding compute?
Side-effect controls: How are retries, idempotency keys, and compensation handled?
Versioning: What happens when workflow code changes while runs are still active?
Observability: Can an operator see the current step, history, retries, cost, and pending approvals?
Operational ownership: Are you running an orchestration service, using a managed platform, or embedding durability in your existing database?
Security: Is persisted agent state encrypted, access-controlled, and treated as a trust boundary?
The right platform depends on your stack. The requirement does not.
The durable agent becomes the production agent
Short-lived agents will continue to run in memory. That is the right tradeoff for quick, read-only, low-consequence tasks.
But once an agent runs asynchronously, waits on people, touches several systems, or owns a business outcome, memory is no longer a reliable place for its existence. It needs a durable identity, a persisted history, recoverable steps, and safe side effects.
The winning agent frameworks will make those properties boring. Eve’s “durable by default” approach is a strong example of that future. The developer describes the agent. The platform makes sure it can finish the job.
Where we come in
We design agent platforms that survive the parts demos skip: crashes, deployments, slow APIs, approval delays, retries, and partial failure. We help teams choose the right durable runtime, define safe step boundaries, and make side effects idempotent before an agent reaches production.
If your agent needs to finish work after the original request is gone, contact us. We will pressure-test the execution model before production does.
Sources
Vercel: Introducing eve: eve architecture, checkpointed conversations, durable approvals, deployment behavior, and the Workflow SDK foundation.
Vercel: A new programming model for durable execution: event history, workflow steps, retries, durable state, streaming, and code-first orchestration.
Vercel: What is WorkflowAgent?: persisted tool-call steps, automatic retries, resumable streams, and durable human approval.
DBOS: Durable Execution for Building Crashproof AI Agents: Postgres-backed durable workflows, asynchronous refund processing, and LangGraph integration.
Microsoft Learn: Durable Extension for Agent Framework: distributed recovery, persistent sessions, human waits, and the distinction between checkpoints and Durable Task execution.
Temporal documentation: durable workflow history, recovery, retries, and long-running execution.