The three dangerous failure behaviours
- Optimistic reporting: announcing success because the call was made, not because the record exists.
- Blind retrying: repeating a step that sends a message or takes a payment, producing duplicates.
- Orphaned failures: an error logged somewhere nobody reads, with no owner and no deadline.
Partial completion is the normal case
Most real failures happen mid-chain: the customer was created, the appointment was booked, the confirmation never sent. Reporting that as a flat failure is as misleading as reporting success.
The correct output names each step and its state, so the person picking it up knows exactly what remains and does not redo work that already landed.
When to retry and when to stop
- Retry reads and idempotent lookups freely.
- Retry an internal write only where a duplicate cannot be created.
- Never auto-retry sends, charges or signature requests — re-issue them deliberately instead.
- Stop after a bounded number of attempts and escalate rather than looping.
Escalation that actually gets resolved
An escalation should reach a specific role or person, carry the entity it concerns, state what was attempted and what remains, and have a time by which it is chased again if untouched.
The same principle applies to work the AI declines: refusal without escalation just moves the failure somewhere quieter.