Resume an agent without repeating its action

A process can crash after submitting a refund but before saving its response. Restarting the conversation does not establish whether the refund happened. Recover the business operation from durable state before allowing another write.

Persist an operation identifier before dispatch. Store the action input or an appropriate reference to its immutable snapshot, the selected environment and any invocation or effect IDs received. The agent's conversational memory should not be the sole record of consequential work.

Cover both crash windows

Crash point	Recovery requirement
Before dispatch	Resume the persisted intended operation
After dispatch, before response	Treat execution as potentially started
After response, before local save	Recover through the same operation identity
While approval is pending	Observe the existing request rather than create another

The difficult window is between your application's database and the external invocation. A stable operation key connects attempts across that window; generating a new key during restart breaks the connection.

Make recovery a state machine

On startup, load unfinished business operations. For those with known invocation IDs, inspect their records. For governed operations submitted with a stable key, use the documented identity behavior rather than submitting unrelated new work. Preserve pending and unknown states explicitly.

If the outcome is unknown, assign reconciliation. If approval is still pending, show or observe that request. If the operation completed, record the result and continue the workflow. An application timeout is not a reason to start again.

Validate with controlled termination

Use a safe fixture and stop the worker after dispatch but before it records the response. Restart it and verify the original operation is recovered. Count provider writes or fixture side effects, not just successful HTTP responses. Repeat around the approval wait and final local-save boundary.

This procedure tests your integration's recovery behavior; it does not claim that Anlyon hosts or restarts your agent process. Your application remains responsible for its durable task state.

Read business operation keys, governed effects and unknown outcome recovery.