Agents Are Retry Loops with Opinions

The word "agent" does a lot of quiet work. It suggests autonomy, intelligence, something that reasons and acts on its own. That framing sells demos and misleads engineers. Strip the mystique and an agent is a loop: call a model, let it pick an action, run the action, feed the result back, repeat until it decides it is done. That is the whole mechanism. It is a retry loop with opinions about what to do next.

This is not a dismissal. Agents are useful. But the romantic framing hides exactly the things that determine whether one works, and the mechanical framing reveals them. Once you see an agent as a loop rather than a mind, its failure modes stop being mysterious and its reliability becomes an engineering problem you know how to solve.

What the loop framing reveals

Look at an agent as control flow and the questions that actually matter come into focus, none of which the word "agent" invites you to ask.

• A loop needs a termination condition. The first thing you learn writing loops is that a loop without a reliable exit runs forever. An agent decides for itself when it is done, which means the exit condition is a judgment made by a non-deterministic component. That is a loop whose termination is not guaranteed, which is why agents get stuck, wander, or burn through steps and budget without finishing. The autonomy that sounds like a feature is an unbounded loop that sounds like a feature.
• Every iteration compounds error. In a normal loop each iteration is deterministic. In an agent, each iteration is a model call that can be wrong, and the next iteration builds on the last one's output. Errors do not stay contained; they accumulate. A small misstep early becomes the premise for everything after, and the loop confidently reasons forward from a wrong turn. The longer the loop runs, the more room error has to compound.
• The tools are where the real risk lives. The "opinions" part, the model deciding what to do, is only half the loop. The other half is the doing: the tools the agent can call. Those tools touch real systems. An agent that can send emails, modify data, or spend money is a non-deterministic loop wired to consequential actions. The danger is never the model's reasoning in the abstract; it is the action the reasoning triggers.
• State makes it fragile. A loop that carries state across iterations, the accumulating context of what it has tried, is a loop whose behavior depends on a growing, messy history. That history can confuse the model as easily as inform it, and long-running agents often degrade as their own accumulated context works against them.

None of these problems is visible when you call the thing an autonomous agent. All of them are obvious when you call it a loop.

Why the framing changes how you build

If an agent is a loop, then making an agent reliable is a control-flow problem, and control flow is something engineers know how to make reliable. The techniques are not exotic; they are the ones you already apply to any loop that does real work.

• Bound the loop. Cap the number of iterations, the time, and the budget. An agent must have hard limits it cannot exceed, because its own judgment about when to stop cannot be trusted to always fire. A bounded loop that gives up is recoverable; an unbounded one that wanders is not.
• Make the tools fail safe, not the model reason perfectly. You will not make the model's judgment flawless, so do not stake reliability on it. Stake it on the tools. Every consequential action the agent can take should be validated, reversible where possible, and constrained so that a wrong decision has a small blast radius. A model that reasons imperfectly through tools that fail safely is far more reliable than a model that reasons well through tools that do not.
• Verify at each step, do not trust the chain. Because error compounds, check the result of each action before feeding it back into the loop. Catching a wrong turn on the iteration it happens keeps it from becoming the foundation of the next ten. An agent that verifies each step is a loop that self-corrects; one that trusts the chain is a loop that confidently builds on its own mistakes.
• Keep the loop short and the task narrow. The failure rate of an agent grows with the number of iterations, because every step is another chance to go wrong and another layer of compounding. A narrow task that finishes in a few steps is far more reliable than an open-ended one that reasons for fifty. When you can decompose a big job into short, verifiable loops, do, rather than handing one long loop the whole thing.
• Put a human at the consequential edge. Where an action is expensive, irreversible, or sensitive, the loop should stop and ask, not decide alone. The human is not a fallback for when the agent fails; the human is a designed step in the control flow, placed exactly where autonomy is too risky.

The reframe

The hype around agents encourages you to think about capability: what can this autonomous system do. The loop framing encourages you to think about control: how does this loop terminate, how is error contained, what happens when a step is wrong, what can the tools actually touch. The second set of questions is the one that produces agents that work. The first set produces demos that impress and then fail in production for reasons the framing told you not to look for.

Agents are genuinely useful, and this is not an argument against them. It is an argument for seeing them clearly. A retry loop with opinions is not a lesser thing than an autonomous agent; it is the same thing, described in a way that tells you how to build it well. Call it a loop, engineer it like a loop, and it becomes reliable. Call it an autonomous mind, trust it like one, and it becomes the outage you did not see coming.