How Long Should an Agent Loop Run?

Roughly half the agent overruns I've investigated weren't caused by genuinely hard tasks — they were caused by loops with no sensible length limit, thrashing well past the point where they'd stopped making progress. The task was answerable in six steps; the loop ran twenty because nothing told it that step fifteen was clearly futile. Getting agent loop length right isn't just about capping cost. It's about knowing the difference between a loop that needs more room and one that's spinning, and that distinction turns out to be one of the most useful signals you have.

This post covers how to think about how long a loop should run, how to set the limit well, and how to use the limit as a diagnostic rather than a blunt cutoff.

What Is Agent Loop Length?

Agent loop length is the number of steps a loop is allowed to take before it must stop — either by finishing naturally or by hitting a ceiling. It's usually expressed as a maximum step count, sometimes paired with a wall-clock budget for good measure. The length limit is the boundary between "keep working" and "stop, you've had enough."

The naive view treats loop length as a single number you tune until it feels right. But a good length limit isn't one number applied everywhere — it depends on the task, and more importantly, it should almost never be the thing that actually stops your loop. In a healthy agent, runs finish naturally well before the ceiling. The ceiling is a safety net for the pathological cases, not the normal stopping mechanism.

That reframing matters because it changes what "the right length" means. The right ceiling isn't "long enough for the agent to always finish" — it's "long enough that legitimate tasks finish comfortably, but short enough that a thrashing run gets caught before it wastes real money." Those two goals pull in opposite directions, and where you land between them is the actual decision.

Why It Matters

Loop length sits at the intersection of three things you care about: cost, latency, and reliability. Too long and you pay for pointless thrashing, users wait through it, and you mask bugs that a shorter limit would surface. Too short and you truncate legitimate work, cutting off genuinely hard tasks before they finish and returning half-answers.

The cost angle compounds because of how loops accumulate context. Late steps in a long loop are the most expensive steps, since each one re-processes everything before it. A loop that runs to twenty steps doesn't cost twice a ten-step loop — it costs much more, because those last ten steps each carry the full weight of the first ten. Trimming excessive length cuts disproportionately from your most expensive steps.

The reliability angle is the one teams underuse. A well-set length limit is a tripwire. When a loop hits its ceiling, that's almost always a signal something went wrong — the agent got stuck, a tool failed silently, the task was mis-scoped. If you treat every ceiling-hit as an alert worth investigating rather than a routine outcome, your loop length becomes a bug detector.

The relationship between length and quality isn't the straight line people assume, either. It's tempting to think more steps means more thoroughness means better answers, but past a point the curve bends the other way. Beyond the steps a task genuinely needs, extra iterations don't add accuracy — they add opportunities for the agent to second-guess a correct conclusion, introduce a hallucinated detail, or wander. On several agents I've measured, answer quality rose with steps up to the task's natural length and then declined slightly as the agent over-worked. The right loop length isn't the maximum the agent can use; it's the point where quality peaks, which is usually a lot shorter than teams expect.

⚡ Pro tip: Plot answer quality against step count for a sample of runs, and look for where the curve flattens or turns down. That inflection point is your task's natural length, and it's the number your ceiling should sit just above. Most teams set ceilings far past this point, paying for steps that are actively making answers slightly worse rather than better.

⚡ Pro tip: Track the ratio of natural finishes to ceiling-hits as a core health metric. In a healthy agent, the vast majority of runs finish on their own, and ceiling-hits are rare exceptions worth investigating one by one. If a meaningful share of your runs hit the ceiling, your ceiling isn't a safety net — it's load-bearing, which means it's hiding an efficiency problem you should fix instead of a limit you should raise.

How to Set the Right Loop Length

Set the ceiling from your actual data, not from intuition. Run a representative batch of tasks with a generous ceiling and plot where runs naturally finish. Your ceiling should sit comfortably above where legitimate tasks complete — enough headroom that real work isn't truncated — but not so far above that a thrashing run burns dozens of steps before stopping.

[object Object], ,[object Object],(,[object Object],):
    steps = ,[object Object],(r.steps ,[object Object], r ,[object Object], completed_runs ,[object Object], r.finished_naturally)
    p95 = percentile(steps, ,[object Object],)
    ,[object Object],
    ,[object Object], ,[object Object],(p95 * headroom)

What this does: It looks at where your naturally-finishing runs actually complete, takes the 95th percentile so nearly all legitimate work fits under it, and adds headroom — giving you a data-driven ceiling that fits real tasks instead of a number you guessed.

For agents handling a mix of easy and hard tasks, a single ceiling serves both badly. Consider setting the ceiling by task class, so a simple lookup gets a tight limit and a complex investigation gets a generous one. This catches a thrashing lookup fast while giving a legitimate investigation room.

[object Object], ,[object Object],(,[object Object],):
    ,[object Object], {
        ,[object Object],: ,[object Object],,
        ,[object Object],: ,[object Object],,
        ,[object Object],: ,[object Object],,
    }.get(classify(task), ,[object Object],)

What this does: It sizes the ceiling to the task class so each kind of task gets a limit matched to its real needs — a tight cap that catches a spinning lookup quickly, and a roomy one that lets a genuine investigation run its course.

Using the Limit as a Diagnostic

The most valuable thing you can do with your loop length limit is treat hitting it as data. Every ceiling-hit is a run that couldn't finish in the space you gave it, and the reasons cluster into patterns worth mining.

Log the full trace of every ceiling-hit and review them, at least at first. You'll typically find a handful of recurring causes: a specific tool that returns ambiguous results and sends the agent in circles, a task type that's genuinely underserved by your tools, or a prompt that lets the agent over-verify. Each pattern is a fix that's worth far more than nudging the ceiling up.

⚡ Pro tip: When you're tempted to raise the ceiling because runs are hitting it, first check whether those runs were making progress at the moment they hit it. A run that was steadily advancing and just needed two more steps justifies a higher ceiling. A run that spent its last five steps thrashing needs a bug fix, not more room — raising the ceiling for it just buys more thrashing. The wasted-step signal tells you which case you're in.

Common Mistakes

⚠️ Common mistake: Using the ceiling as your primary stopping mechanism. If your agent routinely runs until it hits the length limit and then force-answers, the ceiling is doing the job a proper stop condition should do — and force-answering after a full run of thrashing produces the worst answers your agent gives. The ceiling should be a rare safety net. If it's firing often, add a real stop condition and fix whatever is preventing natural completion, rather than treating the cutoff as normal.

A second mistake is setting one global ceiling for wildly different tasks. A limit generous enough for your hardest investigation is far too generous for your simplest lookup, so a thrashing lookup gets to waste fifteen steps before the cap catches it. Size the ceiling to the task class, or you're protected against overruns only on your hardest cases.

A third is treating a truncated answer as a normal, shippable result. When a run hits the ceiling and force-answers, that answer should be flagged as incomplete, not presented with the same confidence as a naturally-finished one. An unflagged truncated answer is a confident answer to a task the agent didn't actually finish.

Three teams show the range. A support agent set task-class ceilings and caught a thrashing FAQ lookup that a global limit had been hiding for months. A research agent used ceiling-hits as an alert and discovered a tool returning silent empties that drove most of its overruns. And a coding agent treated every ceiling-hit as a flagged incomplete result requiring review, which turned truncations from silent failures into a visible, fixable queue.

⚡ Pro tip: When you do need to raise a ceiling, raise it for a specific task class based on evidence, never globally based on a feeling. A blanket increase gives every task — including the ones that were already thrashing — more room to waste, while a targeted increase gives headroom only where legitimate work actually needs it. The instinct to bump the global ceiling when anything hits the wall is how loop lengths creep upward over time until the cap stops protecting you from anything.

Conclusion

The right agent loop length is long enough that legitimate work finishes comfortably and short enough that thrashing gets caught quickly — and in a healthy agent, the ceiling almost never fires, because a real stop condition finishes runs first. Set the limit from your data, size it to the task, and treat every ceiling-hit as a signal worth investigating rather than a routine outcome.

The ceiling-recommendation logic, task-class limits, and ceiling-hit diagnostics are reusable across every agent you run. A prompt and snippet library like PromptABCD is a handy place to keep these patterns alongside your stop-condition prompts, so your next agent gets sensible loop length and a built-in diagnostic instead of one guessed number doing all the work.