The Microsoft Agent Framework durable extension persists sessions and workflow checkpoints across worker processes. The same pattern applies whether an agent runs for minutes, scales across several workers, or pauses overnight for a person.
Durability means a stopped process can continue the same job without pretending the interruption never happened.
How does durable execution recover a workflow?
The runtime stores workflow state after meaningful transitions. On restart, it loads the most recent checkpoint, reconstructs the agentic workflow, and continues from the first unfinished step. A useful checkpoint records both the data needed to continue and which work already committed. It may include the current node, tool outputs, conversation state, retry counters, and identifiers for external operations.
Some runtimes replay deterministic orchestration code to rebuild in-memory state. Replay does not mean repeating every external call. It means recomputing the control flow from recorded events until execution reaches new work.
Does durable execution guarantee exactly-once actions?
No. A process can fail after an email provider, payment service, or database accepted a write but before the agent recorded success. Retrying blindly may duplicate the action. External writes still need an idempotency key, a stable operation identity, or reconciliation against the destination system.
That boundary matters more than the checkpoint format. LLM tracing can show which operation was attempted, but a trace alone cannot prove whether another system committed it. Production tools should return identifiers that the resumed run can query before deciding to retry.
Is durable execution the same as memory?
No. Agent memory supplies facts that may help future reasoning. Durable execution preserves the identity and progress of one running job. Memory answers what the agent knows, while durability answers what the workflow has already done. A system often needs both, but storing a conversation does not automatically make its side effects recoverable.
When is durable execution worth adding?
Use it when work can outlive one request, cross a deployment, wait for an external event, or pause at a human in the loop gate. Short, read-only requests may need ordinary retries instead. Durability earns its complexity when restarting from zero would be expensive or unsafe.
A production agent harness should treat interruption as a normal state, not as an exceptional path that nobody tests. Recovery tests should stop a workflow after each meaningful step, resume it, and confirm that completed actions remain completed while unfinished work continues.