A runaway AI agent loop is a run that keeps calling the model and its tools without getting closer to the goal. You stop it with several independent brakes: a hard step cap, a time and token budget, a check that each step makes progress, and a clear finish test. When a brake trips, the agent stops and hands over.
Why agents get stuck in loops
An agent works in a cycle: it reads the situation, picks an action, calls a tool, reads the result and decides again. That cycle is what makes it useful, and it is also how it gets stuck. Common causes are easy to recognise once you have seen them in logs:
- A tool returns an error the agent does not understand, so it retries the same call with the same inputs.
- Two tools give answers that contradict each other, and the agent swaps between them.
- The goal is vague, so the agent never decides it is finished and keeps "improving" the result.
- A search returns nothing useful, and the agent reformulates the query again and again.
None of these crash anything. The run simply keeps going, spending tokens and touching your systems, while looking busy. We cover what to do with failed calls themselves in when an AI agent tool call fails; this post is about the run as a whole.
The brakes every agent run needs
No single limit catches every kind of loop, so treat them as layers that each work on their own.
A hard step cap
Every run should have a maximum number of model turns or tool calls, enforced by your code, not by the prompt. When the cap is reached the loop ends, whatever the agent wants to do next. Most agent frameworks have a setting for this, but the default is rarely tuned for your task. Set it per task type: a short customer chat needs far fewer steps than an overnight research job. Start low and raise it when real runs show they need more, because a run that stops early is cheap to repeat.
A time and token budget
A step cap does not catch one slow tool call that hangs, or a few steps that each pull in huge amounts of context. Add a wall-clock limit for the run and a timeout on each tool call, plus a token or spend budget. Tie these to the controls described in controlling AI agent running costs, so one stuck run cannot use up a whole team's allowance.
A no-progress check
The cap tells you a run is long, not that it is stuck. A progress check watches for patterns that mean the agent is going in circles:
- the same tool called with the same arguments more than once in a row
- the same error coming back after a retry
- a plan or summary that has not changed between steps
- many model calls with no completed sub-task
When the check fires, stop the run or switch it to a narrower fallback path, rather than letting it try again with nothing new to go on.
A finish test the code can check
Agents loop when "done" is a matter of opinion. Wherever you can, define completion as something your code can verify: a record was created, a test passed, a form has every required field, a reply was sent. The agent proposes that it is finished, and the check confirms it. Without that, the only thing that ends the run is a limit, which is the most expensive way to stop.
What should happen when a brake trips
Stopping is only half the job. A run that dies with a stack trace leaves users confused and work half done. Plan the stop as a normal outcome:
- Return a structured result, such as "stopped: step limit reached", with what was completed and what was not.
- Leave systems in a known state. If the agent was part way through a multi-step change, either finish the safe part or roll back, and record which.
- Hand over to a person with the context they need: the goal, the last few steps, the tool results and the reason the run stopped.
- Tell the user plainly that the task needs a person, instead of retrying silently in the background.
For long jobs that pause and resume, the same rules apply to each stage, not just the whole job. Running AI agent tasks that take days covers checkpoints that make a clean stop and restart possible.
Watching for loops in production
Brakes stop individual runs; monitoring tells you why they keep tripping. Track how often each limit fires, by task type and by tool. A rise in step-cap stops on one workflow usually points to a changed tool, a new kind of input or a prompt edit, not to the limit being too tight. Alert on runs where model calls climb with no finished sub-tasks, and review a sample of stopped runs each week. Our guide on how to monitor an AI agent in production explains which signals to log.
Raise a limit only after you have looked at the runs it stopped and seen that they were doing real work. If they were circling, the fix is in the tool, the goal or the finish test.
How CodeDTX approaches agent run limits
When we build agentic systems, limits are part of the design from the first prototype, not something added after the first surprise bill. Each workflow gets its own step cap, budget, progress check and finish test, and every stop produces a handover a person can act on. If you want a second opinion on how your agents stop, talk to us.
Frequently asked questions
What is a runaway AI agent loop?
It is an agent run that keeps calling the model and tools without moving towards its goal. Typical signs are the same tool call repeated with the same inputs, the same error after each retry, or many steps with no finished sub-task. It rarely crashes anything, so it can carry on for a long time, spending tokens and touching systems, unless a limit in your code stops it.
Is a maximum step count enough on its own?
No. A step cap ends long runs, but it does not notice a single tool call that hangs, a few very expensive steps, or an agent going in circles well below the cap. Combine it with a wall-clock limit, per-call timeouts, a token or spend budget, a no-progress check and a finish test your code can verify. Each catches a different kind of stuck run.
How do I choose the right step limit for an agent?
Set it per task type, based on real runs rather than a framework default. Look at how many steps successful runs of that task actually take, set the cap a little above that, and start on the low side. Review the runs the cap stops: if they were doing useful work, raise it; if they were repeating themselves, fix the tool, goal or finish test instead.
What should the user see when an agent run is stopped?
A plain message that the task needs a person, not an error page or silence. Behind it, the run should return a structured result saying which limit tripped, what was completed and what was not, and pass the goal, recent steps and tool results to whoever picks it up. Systems the agent touched should be left in a known state, with any partial change finished safely or rolled back.
