Field Notes on Durable Execution: The Missing Runtime for Long-Running AI Work

The most consequential change in agentic software is not that models can call more tools. It is that their work increasingly extends beyond a single request. A procurement assistant may wait three days for approval. A research process may survive a rate limit, a deployment, and a changed model version. A claims workflow may pause while a human resolves an exception.

Conventional application code is poorly suited to this temporal shape. If a process disappears, its local state disappears with it. Teams compensate with queues, status columns, cron jobs, and intricate recovery scripts. Durable execution offers a more coherent foundation: record enough workflow history to reconstruct progress, then resume from a known boundary rather than begin again.

Field Note One: The Unit of AI Work Has Expanded

Early AI features were request-shaped. A user supplied text; a model returned text. Even retrieval and tool use often happened within one synchronous exchange. The emerging unit is a workflow: a sequence of model decisions, deterministic operations, external calls, timers, approvals, and revisions.

This matters because each component obeys a different clock. Model inference may take seconds. A payment API may answer quickly but report final settlement later. A person may approve tomorrow. A vendor portal may be unavailable until morning. Treating all of this as one continuous process creates brittle systems and occupied infrastructure.

Durable execution separates logical continuity from process continuity. The workflow remains one piece of work even though no single server process stays alive for its duration. Its progress is persisted. When an event arrives or a timer expires, a worker can reconstruct the workflow and continue.

The shift is subtle but architectural: builders can model elapsed time as part of the program rather than as an operational accident.

Field Note Two: Replay Is the Mechanism, Not Merely Recovery

A durable runtime typically records a history of meaningful events: an activity completed, a timer fired, a signal arrived, or a child workflow ended. After failure, it can replay workflow logic against that history. Completed effects are not performed again; their recorded results are supplied to the code.

Suppose an onboarding agent performs four steps:

1. Extract company details from submitted documents.
2. Check a corporate registry through an external service.
3. Ask a reviewer to resolve a mismatch.
4. Create the approved account.

If the worker restarts while waiting for the reviewer, the system should not repeat the registry check merely to remember its result. Nor should it lose the pending review. A durable history preserves both the completed check and the unresolved wait.

This imposes an important discipline. Workflow code generally needs to be deterministic during replay. Reading the current clock, generating an unrecorded random value, or making a network request directly from replayed logic could produce a different path. Those operations must pass through runtime-managed activities or recorded primitives.

That constraint can initially feel restrictive. In practice, it creates a clean border between coordination and effects: workflow code decides what should happen; activities interact with the world.

Field Note Three: Reliability Moves from Prompts into Boundaries

Prompt design cannot guarantee that a workflow completes exactly once. Models may repeat a tool request, workers may fail after an API accepts a command, and clients may retry after a timeout without knowing whether the first attempt succeeded.

Durability therefore depends on boundaries with explicit semantics:

Consider an agent authorized to issue a refund. It sends the command, but its worker fails before recording success. A blind retry could issue a second refund. The safer design generates a stable operation key before the call, sends that key to an API capable of deduplicating requests, and records the result. If the target API offers no idempotency mechanism, the workflow needs a reconciliation activity that checks remote state before trying again.

This is where many demonstrations become products. The model remains probabilistic, but the surrounding transaction boundaries become inspectable and controlled.

Field Note Four: Human Judgment Becomes a Native Event

Human-in-the-loop systems are often implemented as interruptions outside the application: an email is sent, someone edits a database field, and a polling job notices. Durable workflows allow human action to become a first-class signal.

A workflow can enter a named waiting state, expose the evidence a reviewer needs, and resume when a signed decision arrives. The review is not simply a chat message. It is a state transition with provenance, authorization, and consequences.

A useful approval checkpoint contains:

• The proposed action: what the system intends to do, expressed concretely.
• The decision basis: source records, model output, and applicable rules.
• The permitted responses: approve, reject, request revision, or escalate.
• The validity window: whether approval expires when underlying data changes.
• The resumption rule: the exact workflow branch triggered by each response.

This structure prevents a dangerous ambiguity: approval of an idea being treated as approval of a later, altered execution. If an agent proposes paying one invoice and the amount changes before execution, the old approval should not silently authorize the new transaction.

Field Note Five: Model Evolution Becomes a State Problem

Long-running workflows may begin under one prompt, model, policy, or tool schema and resume after those components change. That is not an edge case; it is the natural consequence of workflows that last longer than deployment cycles.

Teams must decide which artifacts are historical facts and which may be recomputed. An accepted classification that determined a completed branch should usually remain fixed. A draft that has not yet been acted upon might be regenerated under a newer model. The distinction is less about freshness than causality.

A practical record for each consequential model step includes the input reference, prompt or policy version, tool schema version, model identifier, raw response, parsed result, and validation outcome. This does not make the model deterministic. It makes the workflow explainable.

Code changes require similar care. If replay reaches a branch whose logic has changed, it may diverge from recorded history. Workflow version markers let old executions retain old branching behavior while new executions adopt the revision. Alternatively, a team can migrate active instances, but that demands explicit transformation and testing.

Field Note Six: The Best Architecture Is Selectively Durable

Not every token, thought-like intermediate, or UI interaction belongs in durable history. Persisting everything raises storage, privacy, and debugging burdens. Persisting too little makes recovery impossible.

The useful design question is: what must remain true after every process vanishes? Usually the answer includes accepted decisions, completed side effects, approval state, retry state, deadlines, and references to required evidence. It rarely includes transient streaming fragments or disposable exploratory generations.

A strong pattern is to keep the durable workflow relatively coarse. Let activities perform bounded model interactions, retrieval, or document processing. Return compact, validated results to workflow state, while placing larger artifacts in an appropriate object store or database and recording stable references.

This also limits replay complexity. A workflow history should describe the spine of the operation, not become an indiscriminate transcript of computation.

What Remains Unresolved

Durable execution solves continuity, not correctness. A workflow can reliably preserve a poor model decision. It can repeatedly execute an ill-designed escalation policy. Persistence strengthens whatever process has been encoded, including its flaws.

Several questions remain open in practice. Model outputs can contain sensitive material that should not live indefinitely in event histories. Deletion obligations may conflict with immutable audit designs. Cross-system idempotency remains difficult when external services expose weak guarantees. Debugging replay across code, model, prompt, and schema versions requires tooling that most teams have not yet built.

There is also a conceptual tension between adaptive agents and deterministic orchestration. If every branch is predefined, the system may be reliable but narrow. If the model can continually invent plans and tools, replay and authorization become harder to reason about. The promising middle ground is constrained adaptation: the model may propose and revise within a durable envelope whose permissions, checkpoints, budgets, and terminal states are explicit.

The opportunity is not a more persistent chatbot. It is a new runtime model for work that unfolds across uncertainty and time. Once progress can survive failure, waiting becomes programmable, human judgment becomes composable, and AI systems can take responsibility for processes that do not fit inside a request.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.