A workflow is not one atomic action
Handle a refund followed by email or another multi-step agent task when one external operation succeeds and the next does not.
A refund followed by a confirmation email crosses two external operations. If the refund succeeds and the email fails, the workflow is partially complete. Retrying the entire workflow from the beginning can issue another refund.
Give each consequential step its own persisted business identity and outcome. Record the relationship between steps in your application. Anlyon governs individual routed actions; that does not turn several provider operations into a cross-provider transaction.
Model the intermediate states
| Refund | Workflow interpretation | |
|---|---|---|
| Confirmed | Not started | Refund complete; notification remains |
| Confirmed | Unknown | Do not refund again or blindly resend email |
| Unknown | Not started | Resolve refund before claiming completion |
| Refused | Not started | Explain the execution boundary that stopped the task |
These states are more informative than one workflow success boolean. They also give an operator a precise recovery target.
Retry the task that is actually unresolved
When resuming, inspect persisted outcomes before scheduling work. A completed refund should remain completed. An unknown email send needs its own reconciliation rather than a new send under a fresh key. A notification that was never dispatched can follow its own approved recovery path.
Keep the operation IDs stable across worker restarts. Derive step identity from the persisted workflow task, not from the current agent session or retry counter.
Plan compensation explicitly
Some external effects cannot be undone. A sent email cannot be recalled through the send adapter, and a refund is not reversed by rolling back an action definition. Where a correction exists, define it as a separate operation with its own authorization and evidence.
Do not assume a successful compensation restores every downstream consequence. A customer may already have read an email or acted on a changed record. Document the business interpretation of partial completion.
Exercise the failure boundaries
Test failure before each step, after the provider write but before the response, and after the response but before local persistence. Count actual fixture or provider effects when assessing the result.
Use restart recovery, rollback boundaries and governed effects.