Assume dependencies fail
Models time out, networks disappear, applications close and permissions change. Reliability starts by treating these as normal operating conditions.
Bound retries
Retry only when the failure is plausibly transient and cap the number of attempts. Repeating the same failed action forever is not resilience.
Preserve enough state to recover
Long-running work should be able to resume from a safe checkpoint when that is appropriate for the product. Keep recovery data minimal and integrity-checked.
Use alternate routes carefully
Fallbacks should remain within the same user-approved scope. A blocked path must not silently become broader authority.
Run a failure drill before trusting recovery
Start with an ordinary, reversible task such as saving a small report. Then interrupt one dependency at a time: disconnect the model, withhold a tool permission or make the destination unavailable. The test is not whether the agent keeps talking. It is whether it stops safely, preserves what it knows and can distinguish completed steps from unknown ones.
If a write request times out, do not immediately repeat it: the first attempt may already have changed the file. Read the destination first, then decide whether a retry is safe. If the action cannot be checked or safely repeated, leave it incomplete and ask for confirmation.
Expose failure honestly
When recovery is exhausted, report what succeeded, what failed and what the user can do next.