Microsoft Agent Framework adds generally available durable execution

Agent quality is not enough without reliable execution

Microsoft has made the Durable Task extension for Microsoft Agent Framework generally available. It brings the execution model of Durable Task to agents and agentic workflows, preserving progress across failures, restarts and long waits. The extension supports Python and .NET, including self-hosted applications and Azure Functions deployments.

This addresses a gap between a capable demonstration and an operational agent. A long-running task must know which steps finished, which tools are still running and whether a person needs to approve the next action. Conversation history alone cannot reliably reconstruct external side effects after a process disappears.

Durable state makes recovery explicit

The extension records orchestration state so an application can resume rather than restart a workflow after interruption. Developers register agents, orchestrations and workflow graphs with a durable worker. Microsoft recommends Durable Task Scheduler as the backend for Durable Functions and Durable Task SDK deployments.

Recovery semantics need to be understood at every tool boundary. If an agent submitted an order but crashed before saving the result, replaying the step can create a duplicate. Tools should accept idempotency keys or expose reconciliation APIs. A durable orchestrator can remember intent, but the external system must help determine what actually happened.

Human approval can survive a restart

Many production workflows pause for policy, financial or safety approval. Durable execution lets that wait remain part of the orchestration instead of holding a server request open. A reviewer can respond later and the workflow can continue from a known point, even if the original application process has been replaced.

Approval records should bind the person, timestamp and reviewed payload to the exact workflow version. If circumstances change while the task is paused, the system may need to invalidate the decision. Expiry, delegation and rejection paths are essential. A durable wait is useful only when the eventual action still matches what the reviewer saw.

Self-hosting and Azure Functions offer different control

Python and .NET samples cover self-hosted workers as well as Azure Functions. Self-hosting gives teams control over runtime, network and deployment, while Functions can reduce infrastructure management. The same business workflow may therefore fit organisations with different compliance and operational preferences.

The environments will not behave identically. Identity, scaling, networking and checkpoint storage can affect tool calls and latency. Teams should test the target hosting model under restarts and load, and document configuration separately from agent instructions. Moving code is easy compared with moving reliable state and permissions.

Observability must follow the orchestration

A durable system needs traces that show checkpoints, retries, timers, approvals and tool outcomes. Operators should be able to answer why an agent is waiting and whether it is safe to resume. Metrics should distinguish healthy long-running work from a stuck loop that is repeatedly waking and consuming resources.

Logs also require privacy controls because agent state can contain customer data and tool results. Redaction, retention and access should apply to orchestration history as carefully as conversation content. Debugging value does not justify copying secrets into every event. Structured identifiers can preserve causality without exposing full payloads.

General availability raises the production bar

The release gives Agent Framework developers a supported route to resilient execution rather than requiring each application to invent its own job store and recovery logic. It should reduce undifferentiated infrastructure work and make failure handling more consistent across agent projects.

Teams should still run destructive tests before trusting it: terminate workers between steps, delay approvals, return inconsistent tool responses and restore from checkpoints. A durable agent is one that resumes safely, not simply one that continues. Microsoft’s extension supplies the mechanism; application developers remain responsible for idempotency, policy and accountable outcomes.

Version changes need migration rules

Long-running workflows may survive several application deployments. A checkpoint created by one agent graph can become incompatible after instructions, tool schemas or code change. Teams need versioned orchestration definitions and an explicit choice to finish, migrate or cancel old instances. Automatically resuming with new logic can produce actions nobody reviewed.

Blue-green deployment is useful when both workflow versions must operate temporarily. New tasks start on the new version while existing tasks drain on the old worker. Operators should monitor the remaining population and retain rollback capacity until high-impact instances finish. Durable state makes upgrades safer only when its schema and behavioural contract are managed deliberately. Disaster-recovery exercises should restore the scheduler and state store into a clean environment, then verify that timers, approvals and external-operation identifiers survive. Backups that cannot resume a representative workflow are not enough. Capacity planning should also include a burst when delayed tasks wake together after an outage. Rate limits and prioritisation can prevent recovered low-value work from overwhelming urgent new tasks. Every resumed instance should retain its original audit identity so operators can safely distinguish recovery from duplicate submission.