Error Handling & Retries for Agents

A DevOps agent automating infrastructure provisioning crashes its entire ten-step workflow because step three, a DNS check, hit a transient timeout. Nine other steps had nothing to do with DNS, and yet the whole workflow died anyway. This is the difference between a demo and a production system: a demo can afford to just stop on the first error. Production cannot.

The first design mistake is treating every failure identically. A rate limit or a network timeout is transient: the same request will likely succeed if tried again shortly. An authentication failure or a resource that genuinely does not exist is permanent: retrying the exact same request will never succeed, no matter how many times you try. Treating a permanent error like a transient one wastes time and money retrying something that can never work. Treating a transient error like a permanent one gives up on something that would have succeeded on the next attempt.

For transient errors specifically, retrying immediately and repeatedly can make the underlying problem worse, hammering an already-struggling service with an instant retry storm. Exponential backoff waits progressively longer between attempts, and a retry cap prevents an error from retrying forever.

• -Retry: for transient errors, with exponential backoff and a hard cap.
• -Fallback: switch to an alternative approach or provider, exactly like the multi-provider failover from Tier 7's model selection chapter.
• -Skip: for a genuinely non-critical step, proceed without it rather than blocking the entire workflow.
• -Escalate: notify a human when the agent cannot safely resolve the situation on its own, connecting directly back to the approval-gate pattern from the previous chapter.
• -Dead letter: log the failure for later review and move on, rather than the workflow silently vanishing with no trace of what went wrong.