Durable Execution, Now Built for Agents

Today we're announcing agentic durable execution availability in Diagrid Catalyst.

Add a Diagrid package to the agent framework you already build with, LangGraph, Microsoft Agent Framework, Google ADK, AWS Strands, OpenAI Agents SDK, CrewAI and more, and it gains two things at once: durable execution, so it recovers from failure and runs to completion, and verifiable execution, so every step can be cryptographically signed and traced back to its source.

Production AI runs on a spectrum, deterministic workflows at one end and autonomous agents at the other, and most real systems sit somewhere in between. Wherever you land, the execution underneath has to survive failure and be provable after the fact. Durable execution, the ability to pick work back up exactly where it stopped, is now expected. What's missing is verifiable execution: a durable record of what ran, in what order, and what it produced, layered under any agent framework so auditors and regulators can check the answer. That combination is what Diagrid calls agentic durable execution.

Let's dive in deeper to what Diagrid Catalyst provides with agentic durable execution.

Building systems in the age of AI

Computing is defined by eras. Mainframe, client/server, cloud native + microservices and today AI. Lessons from the past shape the future of innovation, however it is still the businesses that set the agenda. Lowering costs, faster delivery and in the world of AI, optimizing business processes to make choices and decisions based on data. Data is the gold mine, AI is the tool to extract this more efficiently.

Although the business needs have accelerated, business processes have remained consistent. The myriad of software architectures for these business processes have always been stateful and often long running. The creation of business process agents is the emergent technology, and due to their iterative nature, this has thrust durable workflow execution into the limelight.

It's not agents or workflows. It's both.

Anthropic's paper building effective agents covers the spectrum of autonomous agents at one end and deterministic workflows on the other.

People often talk about agentic AI as a switch: deterministic workflows on one side, autonomous agents on the other. That's not how real systems get built, and it's not a choice you make once. The reality is there are millions of business processes that are being migrated to incorporate language models, first in very discrete places and increasing as models evolve.

Take something concrete: resolving a customer refund dispute process. A charge is contested, you have to check the transaction and the policy, decide whether it qualifies, and either issue the refund or explain why not. You can build that exact process four different ways.

The design space has two axes.

Control; how much of the flow is fixed in your code (invariant, procedural) versus decided by a model at runtime: deterministic on the left, autonomous on the right.

Composition; whether the work runs through one reasoning LLM or several specialized ones: single-agent at the bottom, multi-agent at the top. That gives four quadrants:

These are four durable agentic patterns.

• Deterministic workflow - you code the steps and call the LLM at fixed points: classify the dispute, check policy in an if-statement, draft the reply. Predictable and cheap, but less flexible; every edge case is a code change. This is where millions of business processes are evolving to today.
• Autonomous agent - you hand the model tools (look up the transaction, read the policy, issue the refund) and a goal, and let it drive the loop. Flexible, handles messy disputes, but less predictable and most likely more expensive token costs.
• Deterministic multi-agent - a workflow coordinates specialists in a fixed order: a triage agent judges whether the dispute is valid, then a resolution agent works out the remedy. Each reasons within its lane; the process stays in control, agents are used for flexibility and the ability to crunch over all reams of data no human wants or even can do. What are the latest policy changes, what are trends etc.
• Autonomous multi-agent - an orchestrator agent decides which specialists to pull in. Triage, fraud check, resolution, customer comms and in what order. Most flexible, least predictable, more expensive in token costs and unlikely to be used in businesses that have a very deterministic process.

Two things matter more than which quadrant you pick. First, teams don't sit still on this grid. Most start bottom-left (a deterministic Workflow), a refund workflow with a couple of LLM calls and move toward more autonomy and more agents as the disputes get messier and the data gets larger and more complicated. The architecture evolves, and your infrastructure has to survive the move.

Second, and this is what the "agents or workflows" framing misses, as you move up and to the right, the ground gets less stable. More autonomy means more non-determinism, more moving parts, more ways to fail, and more decisions you can't reproduce after the fact. When a refund goes out wrong, "the agent decided to not give you your money back" is not an answer you can give a customer, an auditor, or a regulator. The intuition is that autonomy lets you remove structure. The opposite is true: the more autonomous the system, the more it needs a dependable layer underneath execution that survives failure and can be proven afterward.

That layer is the one thing all four quadrants share, and it's what we call agentic durable execution: execution that is durable, so a crash mid-dispute resumes exactly where it left off instead of re-issuing a refund or losing the thread, and verifiable, so every step, every LLM call, tool call and decision, is recorded and traceable back to its source.

Agentic durable execution automatically recovers from failures, carries autonomous AI agents and deterministic workflows to completion and provides cryptographic tamper-proof evidence of what happened.

Why durable execution matters

Software engineers have always built dependable systems on top of fragile systems. TCP is all about handling network and packet loss failures to make a reliable system out of unreliable networking. Disk replication and RAID arrays do the same for data.

Durable execution does this for a process. By saving all the execution state (function inputs, outputs and variables as a log) it handles process crashes, host failures, and mid-flight interruptions (via checkpointing and replay) to make a reliable, exactly-resumable workflow out of unreliable, ephemeral compute. TCP did it for packets, RAID for disks, and durable execution does this for computation.

Guardrails are the checks you wrap around an agent's steps to catch and correct bad decisions before they propagate. They exist because of the compounding-error math: since per-step accuracy multiplies across a chain, you can't just trust each step to be right, you have to actively verify. In practice that means verification steps that check a step's output, retries that re-run a failed call with better context, and human-in-the-loop approvals at high-stakes points. They're required because they're the only way to hold end-to-end accuracy up as the chain gets longer.

Durable execution doesn't make any single step smarter or accurate; a replayed step repeats the same decision. What it does is make guardrails and token usage cost effective. Because the state is checkpointed and a workflow resumes exactly where it stopped, you can drop in a verifier, retry a step, or pause for approval without throwing away the progress already made and burning more tokens. On a freewheeling agent, adding a check risks the whole chain from the top; on a durable workflow, it's a local fix.

Durable execution saves you token cost preventing replays, makes essential agent guardrails affordable and gives you peace of mind on agent work completion.

So how do I protect what an agent does in the world of its unpredictable and autonomous nature? How can I be sure what it did?

Durable execution alone is not agentic durable execution

There are several vendors promising durability for agents from online services to runtimes. Few are built for the agentic era.

Declarative workflow engines are not built for agents

Take declarative workflow engines like Camunda, Orkes, and Airflow. They are mature orchestrators, and they've added agentic features. But they share an assumption: the process is expressed in their model (BPMN, a JSON DAG, a Python DAG) and the agent is something you either rebuild inside that model or wrap as an opaque task the engine coordinates around. They don't natively integrate with agent frameworks.

Your LangGraph, MAF, or ADK agent doesn't get durability added underneath it; it gets replaced while you re-write the logic in the engine's language. The durability is real, but it lives in the orchestration graph, not in the agent's own reasoning loop. This is agent integration bolted onto a workflow engine, the engine on the outside, the agent as a black box.

The bar for agentic durable execution is different. It has to do three things:

1. Integrate with the agent framework you already build with.
2. Ensure durability at every step is durable (recoverable from failure).
3. Verify every step with tamper-proof attestation and provenance (cryptographically provable and tamper-proof) to provide agent trustworthiness.

Code-first workflow engines are not built for trust

Code-first durable execution engines such as Temporal, Restate, and peers like Inngest and DBOS let you keep your framework: a plugin or a few lines wraps your existing agent's LLM and tool calls in durable steps. You write the agent you were already developing, and it becomes crash-safe.

Where they stop is providing trustworthiness and tamper-proof verification of the steps.

These engines give you a journal or an event history, a complete, replayable log of what the system recorded. That gives you reliability and debugging, but it is not verifiability. A journal tells you what your own runtime wrote down about itself. It doesn't cryptographically attest that a step ran as claimed, that the record wasn't altered, or which workload identity produced it. There's no signing, no attestation, no independently verifiable chain of custody. It's observability, not proof.

That distinction is the reason this isn't agentic durable execution. Returning to our refund example. When a payout is disputed and a regulator asks what happened, "here is our internal log of what the system recorded" is a weak answer compared with "here is a signed, attested record of every LLM call, tool call, and decision, each tied to the identity that produced it, that you can verify without trusting us." The first is a log. The second is evidence.

Verifiable execution proves, after the fact, exactly what the agent did, not just that a log says so.

Agents are being required to interpret and learn the reams of data in an organization that no human will ever see or touch. However you need to trust them and provide guardrails (yes, they can be wrong) and that means they need an issued identity. And without proof of exactly what they did, you are vulnerable and open to legal and compliance responsibilities.

This regulation is emerging. The EU AI Act requires providers of high-risk systems to keep automatic logs and event records over the system's lifetime and to build in human oversight; These laws are there to ask: can you show what your AI system actually did, and whether a human was in the loop? Transparency, oversight, and audit obligations all rest on having a trustworthy record of each consequential decision.

That is where agents need to leave a reliable record. Durable execution checkpoints every step as it runs; verifiable execution goes further, cryptographically signing the history so the record is tamper-evident. Instead of reconstructing after the fact what an agent probably did, you have an unrebuttable answer to the question; here is exactly what the agent did, in this order, provably unaltered.

With verifiable execution, compliance and legislation stops being an after-the-fact reconstruction and becomes a property of the system.

Diagrid Catalyst: Built for agentic durable execution

Declarative workflow engines cannot be natively integrated with agent frameworks. The code-first workflow engines can, but leave them unverifiable and untrusted. Agentic durable execution is using your existing agent framework, making it durable and verifiable.

Durable execution is becoming table stakes for agents. Verifiable execution is needed for trusted systems. That's the one Catalyst is built for: Durable and verifiable execution through workflows, attestation, cryptographic signing, and SPIFFE-based workload identity.

Currently Catalyst supports native integration with the 10 leading frameworks.

• LangGraph (and LangGraph Deep Agents)
• Microsoft Agent Framework
• Google Agent Development Kit (ADK)
• AWS Strands
• OpenAI Agents SDK
• Claude Managed Agents
• CrewAI
• Pydantic AI Agents
• Dapr Agents

More are planned including, Vercel AI SDK, Nvidia Nemo agent SDK, Hugging Face Smolagents, and Mastra. Catalyst not only provides agentic durable execution to your agents, but also to the tools and MCP servers used by those agents as well as any application workload.

Diagrid Catalyst is built on Dapr, the CNCF-graduated open source project used by tens of thousands of organizations, so your agent code runs unchanged on AWS, Azure, GCP, or on-prem with no vendor lock-in.

Simple, transparent, and cost effective pricing

Durable agentic workflows shouldn't come with unpredictable bills. Most workflow engines charge by "actions", every step, state transition, or tool call, which is exactly the wrong meter for agents: they're chatty by nature, so the more your agents reason, the more you pay, and your cost swings with every loop you can't predict. Reliability shouldn't be metered by how busy your agents get.

Diagrid Catalyst is priced on one thing you can actually reason about: the number of concurrent workflows you run. There are no per-action charges, no metering on steps, state transitions, or tool calls, so you size for capacity, not volume, and your bill doesn't move when an agent takes an extra step. Pick your concurrency, choose a support level, and you're off. Check out our pricing page, configure your exact price in the calculator, or start a free 14-day trial.

How Diagrid Catalyst delivers agentic durable execution

Let's look at some code. A canonical LangGraph example is a good place to see the gap. Here's a minimal chatbot, a single node that calls the model, wired between START and END, using LangGraph's built-in MessagesState (which already carries the message list and the append-on-write behavior):

import os
from langchain_core.messages import HumanMessage
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, START, END, MessagesState
 
model = ChatOpenAI(model="gpt-4.1-2025-04-14")
 
def chatbot(state: MessagesState) -> dict:
    return {"messages": [model.invoke(state["messages"])]}
 
graph = StateGraph(MessagesState)
graph.add_node("chatbot", chatbot)
graph.add_edge(START, "chatbot")
graph.add_edge("chatbot", END)
compiled = graph.compile()
 
# Run it (in-memory, no durability)
result = compiled.invoke({"messages": [HumanMessage(content="Hello!")]})
print(result["messages"][-1].content)

This works, but look at that last block. compiled.invoke(...) is a synchronous, in-process call. The state lives in memory for the duration of the call and nowhere else. If the process is killed while the LLM call is in flight, a deploy, an OOM, or a node eviction the run is gone. There's no record that it started, no way to resume it, and if a client retries, you pay for the work twice. It's a problem in production, where the interesting agent workflows are long-running, multi-step, and expensive to repeat.

The reasoning logic isn't the issue, the execution model is. So we keep the graph exactly as written and change how it's run: simply wrap the compiled graph in Catalyst's DaprWorkflowGraphRunner.

import os
from langchain_core.messages import HumanMessage
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, START, END, MessagesState
# One new import
from diagrid.agent.langgraph import DaprWorkflowGraphRunner
 
model = ChatOpenAI(model="gpt-4.1-2025-04-14")
 
def chatbot(state: MessagesState) -> dict:
    return {"messages": [model.invoke(state["messages"])]}
 
graph = StateGraph(MessagesState)
graph.add_node("chatbot", chatbot)
graph.add_edge(START, "chatbot")
graph.add_edge("chatbot", END)
 
# Wrap the compiled graph, each node becomes a durable workflow activity
runner = DaprWorkflowGraphRunner(
    graph=graph.compile(),
    name="chatbot",
    role="Chat Assistant",
    goal="Respond to user chat messages.",
)
 
# Serve it: subscribe for incoming tasks, publish results. Catalyst tracks state.
runner.serve(
    port=int(os.environ.get("APP_PORT", "8005")),
    input_mapper=lambda req: {"messages": [HumanMessage(content=req["task"])]},
    pubsub_name="agent-pubsub",
    subscribe_topic="chat.requests",
    publish_topic="chat.results",
)

What actually changed in the code

The imports are identical except for one added line from diagrid.agent.langgraph import DaprWorkflowGraphRunner. The model, the node function, and every add_node / add_edge call are the same. The logic didn't change.

What changed is the compiled.invoke(...) a fire-and-forget in-process call became DaprWorkflowGraphRunner(graph=graph.compile(), ...) followed by runner.serve(...). The runner wraps the compiled graph so that each node becomes a durable workflow activity. As the graph executes, Catalyst records which nodes completed and stores their results in its workflow engine, not in your process. If the process crashes mid-run, the workflow resumes from the last completed node on restart; finished nodes are not re-executed, so there are no duplicate LLM calls and no lost work.

There's also a shift from invoke to serve. Instead of calling the graph once and blocking, the runner runs as a service driven by HTTP requests or pub/sub: it can also subscribe to a message topic for incoming tasks and publish results to any message broker. That's why there's no explicit "run", Catalyst triggers a fresh durable workflow instance for each client call. Your agent code never leaves your machine; only workflow state is stored in Catalyst. And you can use a multitude of databases (Redis, PostgreSQL, AWS DynamoDB, Azure SQL, GCP Firestore, etc) for your workflow state.

The pattern generalizes. A one-node chatbot doesn't really need durability, but the moment your agent chains multiple tool calls, waits on external events, or runs for minutes, or years, the difference between an in-memory call and a durable workflow instance is the difference between a demo and something you can put into production. The framework decides what the agent does; the Catalyst runner decides whether that work survives contact with production without you having to rewrite the agent.

How Diagrid Catalyst delivers verifiable execution

The durable runner already moved your agent's work out of process memory and into Catalyst's workflow engine. Verifiable execution turns that record from a log into evidence.

A durable engine gives you a faithful account of what your own runtime says it did, enough to resume after a crash, enough to debug. It's not enough to prove to someone who doesn't trust your runtime that a step ran as claimed, in that order, produced by that agent, and unedited since. Closing that gap is what Catalyst provides with cryptographic history signing, execution lineage propagation, and workflow attestation, anchored to SPIFFE-based workload identity.

• History signing: each step is signed as it completes, covering its inputs, outputs, and position, so any later edit breaks verification. The history is sealed, not just stored.
• Lineage propagation: each step carries what came before it, so the record is a connected chain you can trace from any decision back to its origin.
• Workflow attestation: every agent and activity has a SPIFFE identity over mTLS, so a signed step proves not just that something happened, but which agent produced it.

You write none of this into your agent. Durability needed the DaprWorkflowGraphRunner wrapper because it changes how the graph runs; verifiability doesn't touch execution. It's a property of the workflow engine. The same LangGraph agent from the previous section produces signed, attested history without a line of graph code changing.

What is required for this verification is agent identity and that is what Catalyst provides.

The result is a record anyone can check with the public key, verify each signature, walk the lineage end to end, confirm the identities, with no access to your systems. That's what a log can't do: security teams confirm an agent did what it claimed, compliance gets a provable chain of custody per decision, and regulated teams can prove an execution completed, where it originated, and that it wasn't altered.

Back to the refund. Disputed months later, durability lets you show your log; verifiable execution lets you hand over a signed, attested chain, the triage judgment, the policy read, the amount, the approval, each entry sealed and tied to the identity that produced it (started by this person, using this agent), checkable without trusting Diagrid or you. The log was a story about what happened. This is proof.

The bottom line

The first wave of AI was about making models intelligent. The next is about making the systems built on them trustworthy, resilient enough to finish the job, provable enough that you can stand behind what they did and meet compliance requirements.

That's the need for agentic durable execution. It's not agents or workflows, it's both, migrating existing business processes and only using agents where necessary. It's not durable or verifiable, it's both, you need reliability and trust. It's not using a new agent framework, it's the ones you are already using.

Take the refund one final time: durable execution carries it to completion even when a node dies mid-payout, and verifiable execution lets you prove, months later, exactly what every agent did and that no one altered it. Together, under any agent framework, they're what turns a prototype into something an enterprise can actually run in production, compliant with laws and legislation.

Agent frameworks made agents easy to build. Agentic durable execution is what makes them resilient and safe to trust. That's what Catalyst is built for, add the package to your agent, keep the framework you already have, and take it to production, anywhere.

Build a trusted, durable agent in under 5 mins with Diagrid Catalyst Cloud.