The first thing most people build into an agent loop is a retry. The second thing they discover is that the retry almost never helps.
Watch a failing run closely and the reason is obvious: attempt two is character for character the same request as attempt one. Same prompt, same tools, same context window, same everything. A model given identical input produces near identical output, so the second attempt fails in the same place as the first — just later, and for more money.
Retrying is not the problem. Retrying unchanged is.
What to vary
The useful question on a retry is not "should I try again" but "what is different this time." There are three answers worth building in, roughly in order of how often they work.
Feed the failure back. If the tool call returned an error, the model never saw it. Put the error text into the next attempt explicitly — not summarized, not paraphrased, the actual string. A malformed JSON argument, a 422 with a field name in it, a timeout: these are the most information-dense tokens available to you, and the default retry throws them away.
Narrow the task. If the model was asked to do four things and failed, ask it to do the first one. Agents fail at the seams between subtasks far more often than they fail at any individual subtask. A retry that decomposes is doing real work; a retry that repeats is not.
Drop the noise. By attempt three the context is usually full of the wreckage of attempts one and two — half-finished tool output, abandoned reasoning, stale file contents. Long context does not degrade gracefully. Rebuilding the context from the original task plus only the confirmed-good results often succeeds where the accumulated version keeps failing.
What not to vary
Temperature is the reflex, and it is close to useless here. Raising it makes the output different, not better; you are buying variance and hoping it lands on correct. If your retry strategy is "same prompt, hotter," you have a lottery ticket, not a loop.
Switching models mid-loop is a similar trap. It occasionally rescues a run, but it makes failures unattributable — you can no longer tell whether attempt three succeeded because of the decomposition or because of the model swap. Keep one variable moving at a time, for the same reason you would anywhere else.
Cap it at three
Three attempts, each structurally different from the last: raw, error-fed, decomposed. If the third fails, the loop is not the problem — the task is outside what this agent can do, and the correct behavior is to stop and say so.
An agent that fails loudly on attempt three is worth paying for. One that silently burns forty attempts and returns something plausible is a liability, and it is the single most common way a demo turns into an incident.