Durable workflows are the foundation for long-running AI

The browser session is not the workflow

An operational task may wait for a document, an external response, or a person's decision long after the original request finishes. If its state exists only in a running process or a conversation buffer, a restart can erase the information needed to continue. A capable model cannot reconstruct a reliable transaction history from a vague instruction to pick up where it left off.

Temporal's documentation describes workflow execution with durable history and recovery. AWS's Builders' Library explains why retryable APIs need careful idempotency design. These references address established distributed-systems problems that also appear in agentic applications. Adding a model changes how some steps are chosen; it does not remove the need to know which steps happened, which can be repeated, and which require reconciliation.

Persist the business state explicitly

Represent a task using states that reflect the actual process. For a hypothetical submission workflow, those might include preparing, ready for review, approved, submission attempted, confirmed, and needs reconciliation. Store the relevant identifiers, versions, and evidence references with the state. Avoid making the entire conversation transcript the only authoritative record of what has occurred.

The model can propose a transition, while application logic checks whether that transition is valid. A task should not move from preparing to confirmed merely because generated text says the submission succeeded. Require evidence from the destination system. This separation helps operators understand the workflow and makes recovery less dependent on reproducing the exact wording or reasoning of an earlier model response.

Separate decisions from side effects

Reading a record, generating a proposal, and committing an update have different recovery requirements. Make the boundaries visible in code and in the execution record. If a process stops after generating a proposal, regenerating it may be acceptable. If it stops after sending an external request, repeating the action may create a duplicate. The workflow must distinguish those cases before choosing a retry policy.

Use a stable operation identifier when the destination supports it, and retain it across retries of the same intended action. If the request changes materially, decide whether it represents a new operation rather than reusing an identifier indiscriminately. Where the destination offers no idempotency mechanism, design a reconciliation step that checks observed state. Some ambiguous outcomes will require human investigation; model confidence cannot substitute for evidence.

Make waiting, cancellation, and upgrades first-class

Waiting should release scarce execution resources while preserving enough state to resume. Record what event or decision the task expects, who owns the next step, and when the wait expires. A notification is not the state itself: missed delivery should not erase the pending work. Operators need a queryable view of what is waiting and why.

Cancellation also needs precise semantics. It can prevent future steps without undoing actions already completed. Tell the user what stopped and what remains in effect. Plan for software upgrades while tasks are active. Changes to state shape, tool arguments, or decision logic can affect runs created under an older version. Preserve compatible behavior or provide an explicit migration path instead of assuming every task starts and finishes on the same release.

Record a recovery playbook for ambiguous operations. Specify where to look for confirmation, how long to wait for eventual results, and who can decide that a new attempt is appropriate. Keep these rules attached to the integration rather than asking each agent run to invent them. Recovery should follow the destination system's behavior, not whichever explanation the model happens to generate.

Prove recovery before expanding duration

Test the workflow by interrupting it at consequential boundaries. Stop the worker before and after an external write. Deliver the same event twice. Resume a task after its permission changes. Let an approval expire. Verify both the final state and the absence of duplicate side effects. These tests are more informative than simply leaving a successful agent running for a long time.

Choose infrastructure according to the complexity of the process. A modest queue and database can support a bounded workflow when state transitions and retry behavior are carefully designed. A durable orchestration platform becomes attractive as waiting, branching, and recovery needs grow. The central decision is not the framework name. It is whether the system can explain its history and continue safely after interruption, without asking a model to guess what already happened.