Handle Errors and Retries Inside an Agent Loop

    You are an engineer who has watched an agent spend forty turns and a lot of money failing at the same step in slightly different ways. Design the failure behaviour of my loop.

What the agent does: {{agent_purpose}}
Its tools and what can go wrong with each: {{tools_and_failure_modes}}
Current retry and error handling, if any: {{current_handling}}
What it costs when the agent gives up: {{cost_of_giving_up}}
What it costs when the agent keeps trying: {{cost_of_persisting}}

Produce the following.

1. **Classify the errors.** For each realistic failure, decide which kind it is and treat it accordingly:
   - **Transient** — rate limits, timeouts, 5xx. Retry with backoff, in code, without involving the model.
   - **Malformed call** — bad arguments or schema violations. Return a specific, corrective error and let the model retry once or twice.
   - **Legitimately empty** — the tool worked and there is nothing there. This is not an error, and treating it as one causes some of the worst loops.
   - **Terminal** — permissions, missing resource, contradictory instruction. Stop. Do not retry.
   Say which of mine fall where.

2. **Stop retry contamination.** Every failed attempt leaves its output in the context, and the model treats its own failed reasoning as evidence, diverging further with each try instead of converging. Tell me what to strip, summarize, or replace between attempts so the retry starts from a clean statement of the problem rather than the wreckage of the last three tries.

3. **Set hard budgets.** Maximum retries per tool call, maximum total steps per run, maximum spend or wall-clock per run. Give me actual numbers for a task like mine and the reasoning. Enforce them in code, because a model asked to limit itself will not.

4. **Detect the loop.** How to notice the agent is repeating itself — identical or near-identical calls, oscillating between two approaches, re-reading the same resource — and what to do the moment it is detected. Breaking out early is nearly always better than one more attempt.

5. **Design the give-up path.** Failing usefully means reporting what was attempted, what is known, what is blocking, and what a human should do next. Write the shape of that output. An agent that stops cleanly with a good handoff beats one that produces a confident wrong answer.

6. **Decide what is idempotent.** Which actions are safe to retry and which could double-charge, double-send, or double-write. For each unsafe one, the guard that makes retrying safe.

Return the error-handling design as rules I could implement directly, and name the one failure mode most likely to hit me first.