# Persist the workflow step before continuing the dialogue

Model the next business action as durable state. A restarted worker should know whether to dispatch, reconcile or report a result without asking the model to guess.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Separate run state from message history

Create a run record with the task owner, workflow version, current step and status. Store messages separately or reference them from the run. The execution path should not parse prose such as "the update is complete" to determine whether a tool already ran.

For a mutation, create an operation record containing the target, payload reference and stable operation identifier. Use explicit states whose meaning is documented. Pending can mean accepted for execution, while uncertain means a request may have taken effect but its outcome is not yet established.

Keep sensitive payloads in appropriately restricted storage. A checkpoint is another data copy, so it needs access and retention rules rather than being treated as harmless infrastructure metadata.

## Claim work atomically

A worker should claim the next step using a transaction or conditional update. Include a version or ownership token so a second worker cannot silently overwrite progress based on an older read.

```text
load run and current operation
claim the expected run version
if operation is completed: use its saved result
if operation is uncertain: reconcile its existing identifier
if operation is pending: verify authority, then dispatch
save the resulting state with the ownership check
release the claim or renew it while work continues
```

This sketch omits platform-specific locking and lease details. A lease expiry alone is not enough if an old worker can still write afterwards. Use a storage-level condition or another mechanism that rejects stale ownership, and consider how external effects are protected too.

## Save intent before the external call

Persist the operation identifier and approved payload before dispatch. If the worker dies afterwards, another worker can recover the same operation. Generating a new identifier on every attempt defeats this relationship.

On a confirmed downstream result, save the business outcome and target reference. If the response is lost, retain uncertainty. Use the downstream idempotency or status contract to resolve it rather than recording a definite failure that encourages a duplicate.

Where the target mutation and workflow state share a database, consider a single transaction for the effect and its result record. Where they do not, make the reconciliation path explicit.

## Rebuild the next prompt from known state

Only after the operation is resolved should the dialogue continue with its recorded result. Supply the model with a bounded summary of completed work and remaining choices. Do not replay tool requests in a way that causes them to execute again merely because they appear in history.

Test a restart at each persistence boundary and verify the run advances once. Include a stale worker attempting to save after another worker has taken ownership. The implementation is ready when durable state determines recovery and the conversation accurately explains that state to the user.

## Sources

- [PostgreSQL: transaction isolation](https://www.postgresql.org/docs/17/transaction-iso.html)
- [AWS Builders' Library: idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)