With the Microsoft Agent Framework and its Durable Task extension, durable execution is once again a major topic in the .NET world. The idea is tempting: define agents and workflows in ordinary code, then let the runtime handle persistence, crash recovery, state management, distributed scaling, and observability.

That is strong technology. At the time of writing, the Durable Task extension for Microsoft Agent Framework is still in preview, but the direction is already clear: durable execution is becoming easier to apply to agentic and workflow-based systems.

Precisely because it is powerful, it will also be used in places where it does not belong.

My thesis: for short, cheap, idempotent pipelines, durable workflows are usually the wrong abstraction. Not because the framework is bad, but because the nature of the problem is different.

Keep Two Concepts Separate

There is an important distinction that is easy to blur.

Microsoft Agent Framework workflows let you define a graph of executors and agents. That can be useful even without durability. A workflow graph can model a sequence, a branch, a fan-out, or a handoff.

Durable Task is a different decision: it adds persistence, recovery, replay semantics, and distributed coordination.

Those two things are related, but they are not the same. A workflow does not automatically need to be durable. A three-step graph can still be just a three-step graph.

That distinction matters because the cost of a workflow model and the cost of durable execution are not the same.

What Durable Workflows Are Built For

Durable execution solves a real and difficult problem: how do you keep a workflow alive when it runs for a long time, consists of several steps, waits for external events, and may fail along the way?

The runtime records progress in durable state. If the process crashes, the workflow can be reconstructed from history and resumed. Work that has already completed does not have to be blindly executed again. In serverless hosting models, a workflow can wait for a human approval or external event without consuming compute for the entire waiting period.

That is excellent engineering for workflows that actually have these properties:

  • long-running processes
  • human approvals
  • external events
  • distributed execution
  • visible business state
  • expensive intermediate steps
  • recovery requirements that span process restarts

This is where durable workflows shine. The extra machinery buys you something concrete: continuity, recovery, and visibility.

But durability is not magic. It does not remove the need to design side effects carefully. If a step sends an email, charges a card, writes to an external system, or publishes a message, you still need idempotency keys, deduplication, transactional boundaries, or an outbox pattern. Durable execution helps avoid repeating completed work, but it does not make the outside world exactly-once.

What a Short Pipeline Is

A short pipeline is not just a workflow that finishes quickly.

For this discussion, a short pipeline has four properties:

  • it runs in milliseconds or a few seconds
  • it has only a small number of steps
  • it does not wait for humans or external events
  • it is cheap and safe to repeat from the beginning

That last point is the decisive one.

A message comes in, gets transformed, validated, enriched, and forwarded. If the process dies halfway through, the simplest recovery strategy is often to run the whole pipeline again. If the pipeline is idempotent and the cost of repetition is tiny, replaying from durable history is solving a problem that the workload barely has.

For this kind of workload, durable execution can make you pay a price without giving you enough value in return.

The Costs You Add

Infrastructure overhead.

Durable execution depends on a persistent backend and a hosting environment that records workflow progress. For a process that finishes in milliseconds, that can be more machinery than the problem deserves.

Programming model constraints.

Replay-based orchestration requires discipline. You need clean step boundaries, deterministic orchestration logic, and careful handling of replay semantics. Those rules are worth their cost when you need recovery across time. If you do not, they become cognitive overhead.

Latency.

Every durable boundary has a cost. In a workflow that waits for 24 hours, that cost disappears in the noise. In a low-latency pipeline, it lands exactly where you care most.

Debugging distance.

You are no longer debugging simple control flow. You are debugging an orchestration with history, replay behavior, stored state, and runtime semantics. That is powerful for complex processes, but unnecessary distance from a three-step transformation.

Operational coupling.

The pipeline now depends on the durability store, the worker model, the hosting configuration, and the runtime's interpretation of history. That can be a good trade when you need the guarantees. It is a bad trade when a normal retry would have solved the failure.

The Actual Question

The question before choosing durable execution is not:

Would reliability be nice?

Reliability is always nice.

The useful question is:

What does it cost me to repeat the entire operation?

If the answer is "almost nothing, because the pipeline is short, cheap, and idempotent," you probably do not need durable execution.

If the answer is "a lot, because the workflow runs for hours, waits for external input, or contains expensive side effects," then the overhead may be worth every cent.

I would ask five questions before introducing a durable workflow:

  • Does the process outlive a single request or worker process?
  • Does it wait for humans, timers, or external events?
  • Is there meaningful intermediate state that someone needs to observe?
  • Is repeating the whole operation expensive or dangerous?
  • Are side effects isolated and designed for idempotency?

If most answers are no, durability is probably the wrong layer.

What I Would Use Instead

For a short pipeline, the honest architecture is usually boring:

  • a few methods or handlers called in sequence
  • validation at the boundary
  • retry only around transient I/O
  • idempotency keys for incoming messages
  • dead-letter handling for poison messages
  • tracing and metrics for observability
  • an outbox pattern if a database write and message publish must stay coordinated

That gives you reliability where it matters without turning ordinary control flow into orchestration.

The goal is not to avoid infrastructure at all costs. The goal is to put infrastructure at the correct boundary.

When I Would Use Durable Workflows

Durable workflows are the right choice as soon as at least one of these points applies:

  • The process runs for minutes, hours, or days.
  • There are waiting points for external events or human approvals.
  • The workflow state must be externally visible while it is running.
  • Completed steps are expensive to repeat.
  • Side effects need strict coordination and cannot be treated as a cheap retry.
  • The process needs distributed execution across workers or machines.
  • Auditability and replayable history are part of the requirement.

In those cases, the durable runtime earns its place. The workflow is no longer just a short transformation. It is a stateful business process.

Conclusion

The temptation with powerful frameworks is to use them everywhere because they are impressive. Durable workflows are impressive for good reasons.

But durability is not a free upgrade. It is a trade: persistence, replay semantics, storage dependency, latency, and a stricter programming model in exchange for recovery, continuity, and observability.

For short, cheap, idempotent pipelines, that trade is usually wrong. Repeating the whole operation is simpler than preserving every intermediate step.

Sometimes the right answer to "Should we make this durable?" is simply:

No. Make it repeatable.