Jarvis Osorio: Why AI Agents Loop, What It Costs, and How Architecture Stops It

I am Jarvis Osorio (Jarvis Nelson Osorio), a technology entrepreneur and innovator based in Chile. I write about AI systems, DAO institutions, books and art. One failure I now see everywhere, once teams leave the chat box and let agents actually do work, is the loop: the same tool call, the same error, the same retry, the same bill.

I originally shared this diagnosis on LinkedIn in Why Is Your AI Agent Looping? The Root Cause, Economic Cost, and Architectural Fixes. The short version is unsentimental. Looping is rarely a mysterious glitch. It is usually an architecture symptom.

Three ways a loop gets born

The first is the self-grading trap. The same model that takes the step is asked to judge whether the step worked. If it misunderstands its own mistake, it treats the failure as a formatting problem, tweaks a small parameter, and tries again. The echo chamber is polite, busy and wrong.

The second is ambiguous stopping criteria. Prompts such as "keep refining this until it is optimal" sound ambitious. They give the system no finish line. Language models work in probabilities, not hard gates. "Optimal" can move forever, and the meter keeps running.

The third is tool-output misinterpretation. A messy error, an empty list, or a confusing status code arrives. Instead of escalating or stopping, the agent "fixes" the input in a way that triggers the same failure downstream. The loop is a misunderstanding with a retry button.

None of this requires a weak model. A capable model in an unconstrained loop can still burn tokens, hammer an API, and fail to deliver.

What the loop actually costs

The obvious cost is money: repeated calls, expanded context, idle compute. The quieter cost is trust. A team that has watched an agent spin overnight becomes cautious about giving it any real authority—the opposite of what you wanted when you automated the task. There is also a safety cost. A loop that retries a write, a payment or a message is not merely inefficient. It is a process without a circuit breaker.

Architecture, not pep talks

The fix is not a cleverer pep prompt. It is a set of hard rails:

• Cap iterations at the orchestrator, not inside the model's self-talk. A sub-task that may call a tool only a handful of times is already safer than an open while.
• Take evaluation away from the actor. A separate judge, or a deterministic test, should return a clear pass or fail before the next step is allowed.
• Prefer a state machine to a free-form conversation. Failure should lead to a named recovery or a stop, not another improvisation.
• Write playbooks for common errors: if this status arrives, wait, retry twice, then abort and notify a person.

I make the same argument in a different domain in Breaking the Centralized Order: institutions beat vibes. A DAO that lets the spender approve the spend is one failure mode. An agent that grades its own work is another.

As models get faster, the bottleneck is no longer raw fluency. It is whether the system can stop, tell the truth about failure, and hand control back. Reliability will not come from asking the agent to try harder. It will come from constraints you are willing to write down.

Where to go next

This expands on ideas I originally shared on LinkedIn in Why Is Your AI Agent Looping? The Root Cause, Economic Cost, and Architectural Fixes.

More essays, books and profiles: jarvisosorio.com and the hub Jarvis Nelson Osorio — articles, books, videos and profiles. For a parallel argument about systems that never refuse, see The Compliant Mind.

More from Jarvis Osorio: https://jarvisosorio.com