New State of Dapr Report 2026.|Get The Report
Diagrid
Back to Learn
Agent Framework Integrations

Using Microsoft Agent Framework with Catalyst's Durable Execution

Microsoft Agent Framework delivers production durability through Azure Durable Task Scheduler, a managed Azure backend every workflow state transition depends on. See how Diagrid Catalyst replaces that backend with Dapr Workflows, keeping the durability engine inside your own runtime without changing how you build agents.

ByHaziqa Sajid
July 22, 20268 min read

Werner Vogels, Amazon's CTO, famously said, "Everything fails, all the time." This is a fundamental truth of distributed systems. Failures are inevitable due to network partitions, service outages, and timeouts.

Production systems are therefore designed with the expectation that components will fail. AI agent workflows are no exception. However, when a production agent fails, its recovery must be automatic.

Agents built with Microsoft Agent Framework do not have a convenient automatic recovery. They depend on Azure Durable Task Scheduler, which is a fully managed Azure backend-as-a-service. Every workflow state transition depends on the availability and reliability of that service.

This raises an important architectural question: should production durability for agents depend on an Azure-specific managed service? This piece explores those tradeoffs and how Diagrid Catalyst provides portable durable execution within the application's own runtime infrastructure.

Inside Microsoft Agent Framework's durability model

Among today's AI agent frameworks, Microsoft Agent Framework provides one of the most complete approaches to production durability. It starts with a checkpointing system as the foundation.

But Microsoft also recognizes that checkpointing is a storage operation, not a reliability guarantee. For production workloads, it extends this model through the Azure Durable Extension, which brings durable execution capabilities to agents and workflows by handling concerns such as failure recovery, state management, and execution coordination at scale.

Let's look at how Microsoft builds this durability model:

Workflow checkpoints

Microsoft Agent Framework represents a workflow as a graph that executes in discrete supersteps using the Pregel execution model. This structure makes it possible to model complex workflows while creating natural execution boundaries where the runtime can safely pause and later resume execution.

At the end of each completed superstep, the runtime snapshots the entire workflow state into a WorkflowCheckpoint.

A WorkflowCheckpoint captures everything needed to reconstruct the workflow at that point in execution. This includes executor state, shared workflow state, in-flight messages between executors, and pending human interaction requests.

Microsoft Agent Framework supports both in-memory and disk-based checkpoint storage backends. Each checkpoint also includes a graph signature hash. During restoration, the runtime uses it to verify that the workflow graph topology has not changed since the checkpoint was created. If the topology has changed, the checkpoint is rejected to prevent restoring a checkpoint against a different version of the workflow.

Restoring workflow execution

Every WorkflowCheckpoint is assigned a unique checkpoint ID, allowing the runtime to restore a specific workflow snapshot.

To resume a workflow, the checkpoint ID is passed to the workflow runner. It loads the corresponding checkpoint, restores the saved checkpoint state, and continues execution from the last completed superstep.

As part of the restoration process, the runtime invokes framework-defined checkpoint lifecycle callbacks on each executor, including agents, sub-workflows, and custom executors. These callbacks, such as on_checkpoint_save and on_checkpoint_restore, allow each executor to save its internal state when a checkpoint is created and restore it when execution resumes. This enables each executor to recover cached data, message history, or other execution-specific information needed to continue processing.

The durable extension

Microsoft adds durability capabilities for production workloads through the Durable Extension. The Durable Extension brings durable execution to agents, multi-agent orchestrations, and Microsoft Agent Framework workflows.

It supports two hosting models. It can run on Azure Functions for managed, serverless hosting, or in a bring-your-own-compute model for running durable agents and workflows in your own worker process, service, container, Kubernetes environment, or existing application infrastructure.

The Durable Extension provides the durability layer by integrating with the Durable Task infrastructure. Within this infrastructure, the Durable Task Scheduler acts as the backend service that manages durable state, scheduling, and workflow coordination.

Through this integration, agents and workflows can persist state automatically across requests and worker executions. They can resume after failures without losing conversation context or repeating completed work, while scaling across distributed workers.

The extension supports durable agent sessions with persistent conversation history, multi-agent orchestrations, and workflows that can pause for human input or external events while preserving execution state. It also supports reliable streaming when configured with a reliable stream broker and provides execution history, agent session insights, orchestration views, and monitoring through the Durable Task Scheduler dashboard.

The architectural tradeoffs

The checkpointing system and the Durable Extension together provide a well-designed foundation for adding durable execution to Microsoft Agent Framework.

However, production durability also requires architectural decisions around infrastructure, deployment, operations, and cost. Organizations must also consider the implications of introducing an external Azure managed service into their runtime architecture. Below are the key architectural tradeoffs of this approach:

Durability depends on an external Azure service

In this architecture, the application connects to the Durable Task Scheduler, which manages durable state, scheduling, and orchestration execution for agents and workflows. Running production workloads therefore introduces another infrastructure component. And it must be deployed, managed, and operated as part of the production architecture.

Azure becomes part of the runtime architecture

The Durable Task Scheduler is an Azure-managed service used as the backend for the Durable Extension. Even when applications run using the bring-your-own-compute model with their own workers, containers, or Kubernetes environments, the durability layer still relies on the Durable Task Scheduler backend.

This means organizations running workloads across AWS, GCP, or on-premises environments must incorporate an Azure-hosted durability component into their architecture. The result is a runtime architecture where application compute and durability infrastructure are separated, with the durability layer tied to Azure services.

External orchestration introduces operational overhead

As workflow coordination happens through an external scheduler, orchestration replays, activity dispatches, and state transitions are communicated to the Durable Task Scheduler over gRPC. This means execution is coordinated between the application and the external durability service rather than entirely within the application process.

Every orchestration replay, activity dispatch, and state transition introduces a network interaction with the durability layer. For workloads with many short-running agent steps, tool calls, or frequent state transitions, these interactions can become an important consideration for latency and operational cost. The scheduler also becomes another production dependency. Workflow execution depends not only on the availability of the application itself, but also on the availability and responsiveness of the external orchestration service.

Framework logic remains portable, infrastructure does not

Agent implementations largely remain unchanged when adopting the Durable Extension. The durability layer, however, depends on Azure-specific infrastructure and operational services. Organizations therefore need to evaluate whether this deployment model aligns with their broader platform strategy, including cloud preferences, infrastructure ownership, and operational requirements.

What Diagrid Catalyst adds to Microsoft Agent Framework

Diagrid Catalyst extends Microsoft Agent Framework with a durable execution runtime built on Dapr, the CNCF project trusted in production by organizations such as NASA, Grafana Labs, and HSBC. It provides everything your team needs to run Microsoft Agent Framework agents in production. Here's how Diagrid Catalyst enhances Microsoft Agent Framework:

Replaces the durability backend

Diagrid Catalyst replaces Azure Durable Task Scheduler with Dapr Workflows as the durable execution backend for Microsoft Agent Framework. Developers do not need to connect applications to an external Azure service for durable execution. Instead, Diagrid Catalyst keeps the durability engine within the application's own runtime infrastructure, where Dapr Workflows persists workflow state and coordinates workflow execution.

Dapr Workflows runs as a sidecar in the same Kubernetes pod as the application, allowing state transitions to remain local rather than traversing the network to an external service. Durable execution can run on Kubernetes across any cloud, on premises, or in hybrid environments without introducing an Azure dependency. It also eliminates the per-action billing model associated with Azure Durable Task Scheduler.

Durable execution built into the runtime

Unlike checkpointing systems that require external recovery logic, Diagrid Catalyst builds durable execution directly into the runtime. Workflow execution automatically resumes after crashes without requiring developers to implement manual recovery, restart mechanisms, or failure detection.

Before executing each workflow activity, Dapr Workflows records durable execution state. If the application process, Dapr runtime, or even an entire Kubernetes node fails, the workflow is automatically reactivated and resumed without external intervention. During recovery, completed activities are replayed from the durable event history rather than executed again, allowing the workflow to continue from its latest durable point instead of restarting from the beginning.

Distributed coordination is also built into the runtime. Dapr's actor placement service ensures that each workflow is processed by exactly one instance at a time, preventing duplicate execution and race conditions while automatically redistributing workflow execution across the cluster when nodes fail or new nodes are added.

Enterprise infrastructure capabilities

Beyond durable execution, Diagrid Catalyst provides production infrastructure capabilities for operating AI agents at scale. Built-in observability offers end-to-end workflow tracing, per-step execution visibility, and complete execution history through OpenTelemetry, allowing traces to integrate with existing observability platforms.

For compliance and operations, every workflow maintains a complete audit trail with deterministic replay. Past executions can be replayed for debugging, compliance, operational analysis, and incident investigation. Communication between agents and services is secured through automatic mTLS and SPIFFE-based workload identities, enabling zero-trust authentication and fine-grained access control.

Dapr Workflows also persist state after every workflow activity to a durable state store, allowing workflows to survive process crashes, deployments, infrastructure failures, and other runtime disruptions. Multi-region failover further enables workflows to resume from their latest durable state in a standby region if a primary region becomes unavailable.

How it works

From the developer's perspective, workflow code remains straightforward and linear. There is no need to implement custom recovery logic, checkpoint restoration, conditional resume paths, or duplicate execution handling. The runtime transparently persists workflow state, coordinates execution, and resumes workflows after failures. Because durability runs within the Kubernetes cluster, state transitions remain local rather than traversing gRPC to an external Azure service. This removes the whole conundrum of Azure dependencies like per-action billing and service-imposed payload limits.

Microsoft Agent Framework on its own:

var builder = WebApplication.CreateBuilder(args);

// Requires Azure Durable Task Scheduler
// External gRPC service, per-action billing
// Azure managed identity only
builder.Services.AddDurableTaskClient(b =>
{
    b.UseGrpcChannel("my-scheduler.westus2.durabletask.io");
    b.UseAzureManagedIdentity();
});

var app = builder.Build();

Microsoft Agent Framework with Diagrid Catalyst:

var builder = WebApplication.CreateBuilder(args);

// Register Dapr conversation client
builder.Services.AddDaprConversationClient();

// Register agents to run within Dapr
builder.Services.AddDaprAgents().WithAgent(
    agentName: "SampleAgent",
    conversationComponentName: "conversation-ollama",
    instructions: "You are a helpful assistant.",
    serviceLifetime: ServiceLifetime.Singleton);

var app = builder.Build();

If an agent registered through AddDaprAgents() is processing a workflow when the application crashes, Dapr Workflows automatically resumes execution from the latest durable point once the application is available again. Completed workflow activities are restored from durable state rather than executed again, so the workflow continues without manual recovery logic or duplicate execution.

From Azure managed durability to portable durable execution

Microsoft Agent Framework and Diagrid Catalyst share the same durable execution concepts, including deterministic workflow replay and event-sourced state management. The difference is not how workflows execute, but where the durability infrastructure lives.

By default, Microsoft Agent Framework delivers production durability through Azure Durable Task Scheduler. Diagrid Catalyst replaces that backend with Dapr Workflows, moving durable execution into the application's own Kubernetes environment while preserving the existing Microsoft Agent Framework programming model. Developers continue building the same agents and workflows, but without introducing an Azure managed durability service into the runtime architecture.

The table below compares the two approaches:

CapabilityMicrosoft Agent Framework on its ownMicrosoft Agent Framework + Diagrid Catalyst
Durability backendAzure Durable Task SchedulerDapr Workflows
Deployment modelAzure Functions or bring-your-own-compute connected to Azure Durable Task SchedulerRuns on Kubernetes with Dapr sidecars on any cloud, on premises, or hybrid environments
Cloud portabilityAzure dependencyCloud agnostic
Workflow coordinationExternal Azure scheduler over gRPCLocal, in-cluster through Dapr Workflows
Cost modelPer-action billing or Capacity UnitsRuns on existing Kubernetes infrastructure with no per-action fees
Payload limits1 MB per messageNo framework-level payload limits
SecurityAzure Managed IdentitymTLS with SPIFFE workload identity
ObservabilityDurable Task Scheduler dashboardOpenTelemetry tracing and execution history
Multi-region supportAzure service dependentBuilt-in multi-region failover
Execution historyBasic scheduler historyDeterministic replay and complete audit trail

Where to go next

With Diagrid Catalyst, you can make your Microsoft Agent Framework agents production-ready without changing how you build them. Your existing workflows, durable execution model, and recovery semantics remain the same. What changes is where the durability engine runs and how it is operated.

To go deeper on the concepts behind durable agents, work through the Dapr University lesson on Dapr Agents. It covers how workflow engines model activities, how state is checkpointed, and how replay stays deterministic. It's the fastest way to build the mental model for what Diagrid Catalyst is doing underneath your framework of choice.

Frequently asked questions

Yes. Microsoft Agent Framework provides one of the most complete durability models among agent frameworks. It starts with a checkpointing system that snapshots the entire workflow state into a WorkflowCheckpoint at the end of each completed superstep, and extends this through the Azure Durable Extension for production workloads. The Durable Extension brings failure recovery, state management, and execution coordination to agents and workflows. The tradeoff is that its durability layer depends on Azure Durable Task Scheduler, a managed Azure backend that every workflow state transition relies on.