Why Does Your Microsoft Agent Need an Azure Service for Durability?
Microsoft Agent Framework delegates durable execution to the Azure Durable Task Scheduler — a fully managed Azure backend-as-a-service. It requires Azure managed identity, bills per action on the Consumption SKU, caps payloads at 1MB, and has no path to running on AWS, GCP, or on-premises. Dapr Workflows runs as a sidecar in the same Kubernetes pod as your agents — state transitions are local, there are no per-action fees, and it runs on any cloud or on-premises. Built on the open-source CNCF Dapr project trusted by thousands of enterprises.
Production Gap Analysis
Why Azure Durable Task Scheduler Is the Wrong Backend for Agents
Microsoft Agent Framework uses the Azure Durable Task Scheduler as its durability backend. The scheduler is a separate Azure resource that stores orchestration state and dispatches work items over gRPC. Your app connects to it externally, authenticates via Azure managed identity, and pays per action. For teams running multi-cloud, on-premises, or latency-sensitive agent workloads, this architecture introduces unnecessary cost, complexity, and constraints.
Azure-only with managed identity required
The Durable Task Scheduler is an Azure resource (Microsoft.DurableTask/schedulers) that requires an Azure subscription. Authentication is managed identity only — no connection strings, no key-based auth. If you run on AWS, GCP, or on-premises, you either route all durability traffic to Azure or lose it entirely. The docs explicitly state 'Azure connectivity required.'
External gRPC round-trips for every state transition
Every orchestrator replay, activity dispatch, and state persistence is a network round-trip to an external Azure service. Microsoft recommends co-locating in the same Azure region to reduce latency, but even then each state transition crosses the network. Dapr Workflows runs as a sidecar in the same pod — state transitions never leave the host.
Per-action billing adds up with agent workloads
On the Consumption SKU, you pay per action dispatched. An orchestration calling 3 activities generates 7 billable actions (1 start + 3 dispatches + 3 result processings). Agent workflows with dozens of tool calls multiply this quickly. The Dedicated SKU charges a fixed monthly cost per Capacity Unit, with a minimum of 3 CUs required for high availability. Dapr Workflows runs on your existing Kubernetes compute with no per-action or per-CU fees.
External dependency increases failure surface
The scheduler is a separate Azure resource with its own availability. A Durable Task Scheduler outage takes down your agent workflows regardless of whether your own infrastructure is healthy. Provisioning a new scheduler takes 15–20 minutes. Multiple task hubs sharing one scheduler compete for resources — a heavily loaded hub can degrade others. Dapr Workflows runs in-cluster, sharing the same availability as your applications.
1MB payload limits and limited language support
All orchestrator inputs, activity inputs, event data, and entity state are capped at 1MB per message. Large payload offloading to Azure Blob Storage is only available for .NET. The JavaScript SDK is in preview and incompatible with the Durable Functions JS SDK. The Java SDK does not support durable entities. The Go SDK is experimental and community-supported only. Dapr Workflows supports Python, JavaScript, .NET, Java, and Go with no payload restrictions at the framework level.
Azure-specific security with no portable identity
Authentication requires Azure managed identity (user-assigned or system-assigned). There is no SPIFFE-based workload identity, no vendor-neutral mTLS, and no portable access control policies. Teams running hybrid or multi-cloud cannot use the same identity model across environments. Dapr provides mTLS with SPIFFE identity that works identically on any cloud or on-premises.
Integration
Same Durability. No Azure Dependency.
Replace the Azure Durable Task Scheduler backend with Dapr Workflows. Your agent logic stays the same but durability runs in-cluster on Kubernetes — state transitions are local, not gRPC calls to an external Azure service. No per-action billing, no 1MB limits, any cloud. Powered by the same Dapr runtime trusted in production by companies like NASA, Grafana Labs, and HSBC.
var builder = WebApplication.CreateBuilder(args);// Requires Azure Durable Task Scheduler// External gRPC service, per-action billing// Azure managed identity onlybuilder.Services.AddDurableTaskClient(b =>{ b.UseGrpcChannel("my-scheduler.westus2.durabletask.io"); b.UseAzureManagedIdentity();});var app = builder.Build();var builder = WebApplication.CreateBuilder(args);// Register Dapr conversation clientbuilder.Services.AddDaprConversationClient();// Register agents to run withinbuilder.Services.AddDaprAgents() .WithAgent( agentName: "SampleAgent", conversationComponentName: "conversation-ollama", instructions: "You are a helpful assistant.", serviceLifetime: ServiceLifetime.Singleton);var app = builder.Build();Comparison
From Prototype to Production
What changes when you add Diagrid to your Microsoft Agent Framework agents.
Enterprise-Grade
Enterprise Infrastructure for Microsoft Agent Framework
Everything your team needs to run Microsoft Agent Framework agents in production. Built on Dapr, the CNCF project trusted by thousands of enterprises.
Zero-Trust Security
Every agent gets a SPIFFE-based cryptographic identity through Dapr's built-in security model. All communication is encrypted with automatic mTLS. Fine-grained policies control which agents can access which tools.
End-to-End Observability
Distributed tracing for every workflow execution with per-step input and output inspection. Built on OpenTelemetry, so traces integrate with the tools your team already uses.
Multi-Region Failover
Deploy across regions with active-passive failover. If a region goes down, Dapr Workflows automatically resume in the standby region from their last checkpoint.
Durable State Store
Dapr Workflows persist state to a remote store after every activity. Survives process crashes, OOM kills, deployments, and infrastructure failures. Use any supported database as the backend.
Multi-Instance Coordination
Dapr's actor placement service ensures each workflow is processed by exactly one instance. Scale horizontally without duplicate executions or race conditions.
Full Execution History
Complete audit trail for every workflow with deterministic replay. Re-run any past execution for debugging, compliance, or analysis. All built on the open-source Dapr project.
How It Works
Three Steps to Production
Keep your existing Microsoft Agent Framework code. Add production reliability in minutes.
Build with Microsoft Agent Framework
Define your agent, tools, and logic using Microsoft Agent Framework exactly as you normally would. No special patterns or abstractions required.
Wrap with Diagrid
Add one import and wrap your agent with DaprWorkflowAgentRunner (or DaprWorkflowGraphRunner for LangGraph). Each tool call becomes a durable Dapr workflow activity.
Deploy to production
Run with Dapr Workflows handling crash recovery, state persistence, distributed coordination, security, and observability. Your agent code runs locally or in the cloud.
FAQ
Frequently Asked Questions
Does Microsoft Agent Framework already have durable execution?
Yes, but it requires the Azure Durable Task Scheduler as the backend. This is a fully managed Azure resource that your agent connects to over gRPC. It requires an Azure subscription, Azure managed identity for authentication, and has its own billing — per action on the Consumption SKU or per Capacity Unit on the Dedicated SKU. Every state transition is a network round-trip to this external service. There is no alternative backend and no way to run it outside of Azure.
What exactly is the Azure Durable Task Scheduler?
It is a backend-as-a-service for durable execution. It is not a compute platform — your app runs elsewhere and connects to the scheduler over gRPC. The scheduler stores orchestration state and dispatches work items. It uses a combination of in-memory and persistent internal storage, with data retention capped at 90 days (Dedicated) or 30 days (Consumption). It requires Azure managed identity and bills separately from your compute costs.
How is Dapr Workflows different from Azure Durable Task Scheduler?
Dapr Workflows runs as a sidecar in the same Kubernetes pod as your agent. State transitions are local, not external gRPC calls. There is no per-action billing, no 1MB payload cap, and no Azure managed identity requirement. It runs on any cloud or on-premises with no vendor lock-in. It supports Python, JavaScript, .NET, Java, and Go equally — unlike the Durable Task Scheduler where JavaScript is in preview, Java lacks entity support, and Go is experimental. It is part of the CNCF Dapr project, which is open-source and vendor-neutral.
Do I need to change my Microsoft agent code?
Your agent definition, instructions, and tools stay the same. You replace the Durable Task Scheduler backend with DaprWorkflowAgentRunner. Your agent logic is unchanged — only the durability infrastructure changes from an external Azure managed service to an in-cluster Dapr sidecar.
What is Dapr and why does it matter for Microsoft agents?
Dapr is a Cloud Native Computing Foundation (CNCF) project used in production by thousands of enterprises including NASA, Grafana Labs, and HSBC. Its workflow engine provides battle-tested durable execution with automatic failure detection, state persistence, and distributed coordination. Unlike the Azure Durable Task Scheduler, it runs anywhere — any cloud, on-premises, or hybrid — with no vendor lock-in, no per-action fees, and no Azure dependency.
Run Microsoft Agents Without Azure Lock-In
Replace Azure Durable Task Scheduler with Kubernetes-native durable execution. In-cluster latency, no per-action fees, any cloud. Built on open-source Dapr. Start free, no credit card required.