Retries

You'll learn why retrying a side-effecting tool call in an LLM agent loop can cause a new action instead of a repeat, and how stable idempotency keys, cancel-and-confirm on timeout, a shared budget and failure classification keep each action to one run.

You will learn how to decide which agent work to drop under overload, using deadline budgets, a shedding ladder, retries at a single layer, retry budgets and priority tiers with a named owner.

You'll learn why idempotency keys built from a hash of the payload fail when an LLM agent retries, and how to key side-effecting tool calls on intent (task_id + step_id), with the key minted by the orchestrator.

Your `max_retries=3` wrapper is quietly promising that a tool call is safe to run more than once, and nothing in your dashboards will tell you when that promise is a lie.

A timeout, a retry, and zero broken code is all it takes for a multi-agent pipeline to double-charge a customer — here's the decade-old fix almost nobody carried over into agent orchestration.

Two rows, one identical idempotency key, both attempts legitimate — the 3am postmortem that made us realize our retry wrapper wasn't resending a request, it was re-asking the model what it wanted to do.