Why durable agent workflows need explicit state

An agent starts a supplier-onboarding workflow, sends a verification request, waits three days, receives a reply and then restarts after deployment. If its only memory is a conversation transcript, what should it do next? The transcript may say “request sent,” but not whether the message was accepted. It may contain a proposed approval, but not whether an authorised person confirmed it. A model can produce a plausible reconstruction, but plausibility is the wrong standard for resuming real work.

Durable workflows need explicit state: a controlled record of what has been requested, accepted, executed, verified and decided. The model may interpret evidence and propose transitions. The workflow runtime should enforce and persist them.

State is a claim the system is prepared to enforce

A useful state is not a paragraph saying what probably happened. It is a bounded claim with evidence and transition rules. For example:

• proposed: a plan exists but carries no execution authority;
• awaiting-approval: a specific proposal has been sent to an eligible approver;
• authorized: approval is valid for the recorded proposal and time window;
• dispatched: an operation was sent, but its effect may be unknown;
• effect-confirmed: an authoritative external record shows the intended effect;
• completed: all required checks and communications are satisfied; or
• compensating: the system is applying a defined response to a partial or failed outcome.

Each transition should name the event, actor, preconditions, resulting version and evidence reference. Reject transitions that skip required gates. A tool response should not move a workflow directly from proposed to completed if policy requires approval and end-state verification.

Separate commands, events and current state

Three record types reduce confusion:

1. Command: an instruction to attempt something, such as “send this approved order.”
2. Event: an immutable observation, such as “provider accepted message ID 8F2.”
3. State: the current interpretation of relevant events under the workflow rules.

Commands express intent, not fact. Events say what was observed, not necessarily what the business now considers complete. State is derived under rules that can be versioned and reviewed.

This separation is particularly important for model output. “The customer has been notified” is not an event merely because the model generated it. The event comes from the messaging provider or another authoritative record. The workflow may then mark notification complete if that evidence satisfies its rule.

Give every unit of work an identity

Durability depends on stable identifiers:

• workflow instance and version;
• step or task;
• request and correlation ID;
• idempotency or deduplication key;
• principal and delegated authority;
• external effect or resource ID;
• approval and evidence version; and
• parent and child workflow relationships.

Use these identifiers across queues, tools and traces. The W3C Trace Context standard provides interoperable trace identifiers for correlating a request through distributed services. A trace ID does not replace business state, but it connects telemetry to the workflow record needed for investigation.

Checkpoint decisions, not hidden model internals

A checkpoint should contain the information required to resume safely: current state, completed steps, pending work, tool effects, active approvals, budgets, versions and next allowed transitions. It need not capture a model’s hidden reasoning.

Persist before and after consequential boundaries. Before dispatch, record the authorised command and its deduplication key. After the call, record the observed response and any external identifier. Before waiting, record the condition and deadline. After resumption, revalidate authority, policy and source freshness rather than assuming they remain unchanged.

Research on resilient workflow systems makes the recovery trade-off explicit. ExoFlow durably logs workflow structure and coordinates checkpoints so failed work can be recovered without blindly rerunning everything. Work on distributed speculative execution likewise describes durable execution as persisting state and resuming after failure. Agent decisions add uncertainty to the workflow, but they do not remove these distributed-systems requirements.

Model ambiguous effects explicitly

The hardest state is not failure; it is unknown. A tool can change an external system and lose the response. If the runtime marks the step failed and retries, it may duplicate the effect. If it marks the step complete, it may silently skip unfinished work.

Represent the ambiguity, for example effect-unknown, and route it to reconciliation:

1. query the target system using the business key or operation ID;
2. compare the observed state with the intended effect;
3. if found, attach the external evidence and continue;
4. if absent and the operation is safely repeatable, retry with the same deduplication key; and
5. if still ambiguous, stop and escalate with the evidence collected.

RFC 9110 defines an HTTP method as idempotent when repeated identical requests have the same intended server effect, and explains why that matters when a connection fails before the response is read. Agent workflows need the same reasoning at the business-operation level; the HTTP verb alone cannot guarantee that a downstream side effect is safe to repeat.

Keep conversation, memory and workflow state distinct

The transcript can be retained as evidence and used to rebuild model context. Memory can preserve preferences or useful past episodes. Neither should silently mutate the workflow state.

Suppose a user writes, “Actually, ship to the office.” The message is an event. A model may interpret it as a change request. The workflow should then check identity, order state, cut-off rules and confirmation requirements before transitioning to an approved address change. The transcript records what was said; the state machine determines what that statement is allowed to change.

This design also handles conflicting messages. Two instructions remain visible as separate events, while state can move to needs-resolution instead of forcing the model to choose one as truth.

Version everything that changes behaviour

Long-running workflows may cross deployments. Record the versions of:

• workflow definition and policy rules;
• model and prompt or instruction bundle;
• tool contracts and schemas;
• retrieval index or important source snapshot;
• evaluation and grading configuration; and
• authorisation policy.

Choose an explicit migration rule. A running instance might finish under its original definition, migrate at a safe checkpoint or stop for review when a material control changes. Never let a deployment quietly reinterpret old events under incompatible rules.

The NIST Generative AI Profile emphasizes documentation, monitoring and risk management across the lifecycle. For a durable agent, the lifecycle includes the version under which each decision and action occurred.

Prove recovery with fault injection

Do not infer durability from code review. Interrupt the system at every consequential seam:

• after state commit but before dispatch;
• after external effect but before response;
• after response but before state commit;
• while waiting for human approval;
• during a model or tool version change;
• after a duplicate queue delivery; and
• after a late completion from an expired worker.

For each fault, assert the state after restart, external effects, authority validity, duplicate prevention and evidence completeness. A passing result is not merely that the workflow eventually finishes. It must finish without prohibited or duplicate effects and with a trace a reviewer can reconcile.

Release the state model with the agent

The release packet should include the state diagram, transition rules, persistence boundary, recovery procedures, tool effect semantics, migration policy and fault-test results. Name the owner for stuck and ambiguous states. Define timeouts and terminal outcomes so work cannot remain “in progress” forever.

Explicit state can feel less intelligent than asking a model to decide what to do next. That is its advantage. It makes the facts of the workflow deterministic enough to inspect, while leaving interpretation and planning to the components designed for them.

An agent can be probabilistic. The record of whether money moved, approval exists or work completed should not be.