Most agent demos finish in seconds. Production agents don't. An agent working a production incident or an insurance claim can run for hours. It calls APIs, updates records and waits for a human to approve the next step. Then a pod gets evicted, and the whole run starts over. Every LLM call and tool call runs again. You pay for the same tokens twice, and actions that already happened may happen again.
Durable execution is meant to fix that. At AGNTCon + MCPCon North America in San Jose last month, Diagrid, the company behind the CNCF-graduated Dapr project, announced durable execution for goose, the open source agent hosted by the Agentic AI Foundation (AAIF). It plugs in through goose's standard extension mechanism, so goose itself doesn't change. Diagrid also added integrations for LangChainGo and Mastra, bringing its support to more than 15 agent frameworks across Python, TypeScript, Java and C#.
The approach wraps the agent in a workflow. Each LLM call and tool call becomes a checkpointed step. If the process dies, the agent resumes from the last completed step instead of from zero. In the open source diagrid-goose integration, goose runs inside a Dapr Workflow, and each conversation turn becomes a durable activity.
I sent questions to Yaron Schneider, Diagrid co-founder and CTO and chair of the AAIF Workflows Working Group, about which workloads need this, what it costs and where it stops helping. His answers have been lightly edited for length and clarity.
Production agents run for minutes, hours or days. What kinds of agent workloads actually need durable execution, and which ones are better off simply restarting?
Yaron Schneider: The dividing line isn't really how long an agent runs. It's the cost and consequences of losing its progress. If an agent is answering a simple question, classifying a document or generating a draft that can be recreated cheaply, restarting is usually fine. There's little value in adding durability to work that is stateless, inexpensive and safe to repeat.
But consider an agent investigating a production incident, coordinating several other agents, processing an insurance claim or executing a multi-step business transaction. It might spend hours gathering evidence, calling APIs, updating systems and waiting for human approval. If the process crashes halfway through, starting over wastes time and tokens, and potentially repeats actions that have already happened.
Those are the workloads that need durable execution: systems where progress matters, actions have consequences, or the workflow must continue even when a process, machine or dependency fails. The agent should be able to resume from its last completed step rather than reconstructing everything from scratch.
The goal isn't to make every agent more complicated. It's to make reliability proportional to the work being done. If you can safely throw away the progress, restart. If losing that progress means lost money, duplicated actions, broken processes or an incident that goes unresolved, you need a way to recover and finish the job.
Diagrid commits each step before the next one begins. What does that cost an agent in latency and complexity, and when isn't that cost worth it?
Schneider: Complexity is minimal. We're talking about a three-line-of-code integration in most cases that wraps around the agent to make it durable. Regarding latency, each agent step will incur an extra 50 milliseconds, give or take. When an LLM call takes several seconds to complete, this extra latency becomes a non-issue.
If an agent crashes and resumes at the last committed step, what about steps that had side effects, like an email sent or a payment made? How should developers think about a step that ran but wasn't recorded?
Schneider: Developers should make sure that their business logic is idempotent to avoid cases where a step ran and wasn't recorded.
LLM calls aren't deterministic. When a workflow resumes, does it replay the saved result or call the model again? What are the trade-offs?
Schneider: The execution plan of the agent is saved, and every LLM and tool call result is saved. An LLM call will only be replayed if it wasn't checkpointed before the crash. Otherwise, the workflow will keep previous LLM calls and only issue new ones where needed to complete the agentic workflow.
Diagrid now supports more than 15 agent frameworks, including goose, LangChainGo and Mastra. What does a developer have to change in their code, and what stays the same?
Schneider: With goose, Diagrid integrates through its standard extension mechanism, so developers don't need to modify goose itself. For frameworks like LangChainGo and Mastra, developers use the corresponding Diagrid integration to run their agents with durable execution.
What stays the same is the framework's core functionality, models, prompts, tools and existing agent logic. What changes is how the agent is connected to and executed on Diagrid, which checkpoints completed steps and enables recovery after a failure. Developers can keep building with the frameworks they already know while gaining the reliability needed to run agents in production.
Can you share a real case where durable execution saved a team from paying for the same tokens twice?
Schneider: We work with a large manufacturing company in the EU that runs agents in a complex OCR workflow. Diagrid saves them usage tokens by continuing where the agent left off in the face of failure, instead of restarting the entire process from the beginning.
Durable execution is one of several ways to make agents reliable. How do you decide between it and simpler options like retries, queues or checkpoints in the framework itself?
Schneider: The sensitivity to both lost data and failure is what drives the need for durable execution. Retries are in-process only. They do not survive a process restart. Checkpoints only give you the ability to store state in a database. You're still on the hook for detecting that a failure happened, and then figuring out how to resume it yourself. That's a lot of cognitive overhead that durable execution removes from developers.
What claim about making AI agents reliable should engineering teams be skeptical of right now?
Schneider: Reliability factors in many different aspects, not just the durability of the workflow and state. One of the hardest challenges is making the accuracy of the underlying system reliable. It's done through evaluations today, but there's no way to make a probabilistic system like an LLM reliable in terms of response quality.
What This Means for Developers
Start with Schneider's first answer, because it's the most useful filter here. Most agents don't need durable execution. If the work is cheap, stateless and safe to repeat, let it restart. Add durability when losing progress costs money, repeats an action or leaves an incident unresolved.
The idempotency answer is short, but it's where your real work is. Durable execution gets the agent back to the last committed step. It doesn't promise a side effect happens exactly once. If a step sends an email or charges a card and the process dies before the checkpoint lands, that step runs again on resume. So build for it before you turn durability on. Use idempotency keys where the API supports them, which most payment APIs do. Check whether the action already happened before you take it. Record completed actions somewhere the agent can see.
The replay behavior matters more than it first appears. Because saved LLM and tool results are reused on resume, the agent doesn't re-ask the model and wander down a different path halfway through a job. Only the call that wasn't checkpointed goes back to the model. Keep in mind that this one call can return a different answer than it would have the first time.
The 50-millisecond figure is Diagrid's own number. Next to a multi-second LLM call, it's noise. For an agent that makes many fast tool calls between model calls, measure it on your workload.
Schneider's distinction between retries, checkpoints and durable execution is a good one to keep handy. Retries die with the process. Framework checkpoints save state, but you still have to notice the failure and write the resume logic yourself. Durable execution handles detection and recovery for you.
And his last answer is the honest one. Durability isn't correctness. A durable agent that reasons badly will still finish the wrong job, just more reliably. You still need evaluations. Treat durable execution as one layer of reliability, not the whole thing.
If you want to try it, the goose integration is open source, and Diagrid's integrations for frameworks like LangGraph, CrewAI and the OpenAI Agents SDK install as Python packages. Pick one long-running agent whose failures already cost you tokens or cleanup time. That's the right test case.
