The Scariest AI Agent Failure Is Not Incompetence. It Is Refusing to Stop
A paper scanning 6,549 agent repositories identifies Infinite Agentic Loops: ordinary requests can become costly feedback cycles when planning, tool use, and state updates lack hard boundaries.
Main answer
The more autonomy an AI agent receives, the more explicitly its stopping conditions, budgets, timeouts, and approval gates must be designed.
Who should read this
For teams building, deploying, or evaluating AI agents, automated workflows, tool-using assistants, and multi-agent systems.
Key check
IAL-Scan analyzed 6,549 LLM-agent repositories, reported 74 candidates, and manually confirmed 68 failures across 47 projects, with 91.9% reported precision.
Next step
Audit every agent for maximum steps, maximum cost, timeouts, idempotency, human approval, and replayable logs.
What You'll Learn
- + What Infinite Agentic Loops are
- + Why every step can look reasonable while the whole workflow fails
- + Which agent designs are most exposed
- + How small teams can add effective runtime guardrails
Most people worry that an AI agent will fail because it is not smart enough.
A recent paper points to a different risk that becomes more important once agents enter real workflows:
The agent may not fail to work. It may keep working and fail to stop.
An ordinary request can expand into repeated planning, tool calls, checks, and revisions. Every step may appear reasonable, while the complete process becomes a cost black hole.
The paper calls this failure mode Infinite Agentic Loops, or IALs.
Every Step Can Look Reasonable
A conventional infinite loop is often obvious:
while true:
do_something()An agent loop is more subtle. The agent makes a plan, calls a tool, observes the result, decides that more work is needed, updates state, and plans again. In a multi-agent system, agents may assign work to one another, review each other, and repeatedly send tasks back.
Individually, none of these actions looks wrong:
- plan the next step;
- call a tool;
- inspect feedback;
- revise the approach.
The failure appears when the system has no reliable definition of completion.
The central problem is not one broken line of code. It is that the system never learned what “done” means.
From Worker to Foreman
Older AI systems behaved like day laborers. You asked for one action and received one result.
An agent behaves more like a foreman. You give it an objective, and it can assign roles, use tools, inspect progress, and decide what should happen next.
That autonomy is powerful, but it changes the risk. If “build it well” has no measurable standard, the foreman can keep ordering another inspection, another revision, and another round of work. The system is not being lazy. It genuinely believes that improvement is still possible.
Eventually the budget is gone and the job is still open.
When AI changes from a tool into an execution system, we must design a brake as carefully as we design the accelerator.
Evidence From 6,549 Agent Repositories
The paper, When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents, introduces IAL-Scan, a static-analysis method for detecting feedback paths that may repeatedly reach expensive or state-growing operations.
The authors analyzed 6,549 LLM-agent repositories:
- 74 potential findings were reported;
- 68 were manually confirmed as real IAL failures;
- the failures appeared across 47 projects;
- the paper reports 91.9% precision.
These numbers do not mean that most agents will loop forever. They do show that runaway feedback is no longer a purely theoretical concern.
The paper is currently an arXiv preprint. Its evidence is useful, but the findings should not be generalized to every agent system or treated as completed peer review.
How One Request Becomes a Chain Reaction
When AI can only chat, the common failure is a wrong answer.
When AI can use tools, the failure can become a wrong action.
When AI can plan repeatedly, update state, and coordinate other agents, it can repeat or amplify those actions.
The consequences include:
- Runaway cost. Model calls, API calls, and cloud resources accumulate round after round.
- Service exhaustion. A normal request can occupy processes, memory, and task queues for too long.
- Context growth. History continues to expand, making every later step slower and more expensive.
- Repeated side effects. The agent may send duplicate messages, submit forms repeatedly, place orders again, rewrite files, or delete data more than once.
The more an agent can act on its own, the more strictly we must limit how long it can run, how much it can spend, and which actions require a person.
Three Boundaries Every Agent Needs
You do not need to understand IAL-Scan before reducing the risk.
1. Define a stopping condition
Do not say:
Keep improving until it is perfect.
Say:
Run at most three revision rounds. Report the result after each round, then stop and wait for confirmation.
“Perfect” is a wish. “Stop after three rounds” is an executable boundary.
2. Enforce budgets and timeouts
Give the task hard limits:
Run for no more than two minutes and spend no more than one dollar. Stop and report when either limit is reached.
Budget control should not depend on the agent deciding that it has spent enough.
3. Require human approval for external actions
Sending messages, placing orders, submitting forms, changing permissions, deleting files, or making payments should require an execution preview and explicit approval.
A Practical Checklist
Before trusting an agent with a real workflow, ask:
- How many steps can one task run?
- How much can one task spend?
- Which tools create external side effects?
- Are those actions idempotent and deduplicated?
- How many times can an error be retried?
- Does memory or context growth have a limit?
- Do multi-agent handoffs have a maximum count?
- Can the complete run be replayed and audited?
Prototype teams usually ask whether an agent can complete a task. Production teams must also ask whether it can stop safely.
Kunpeng AI Takeaway
The next stage of AI agents is not only stronger models and more tools. It is more reliable runtime control.
An agent without a budget, timeout, completion condition, or side-effect protection may look impressive in a demo, but it is not ready for important work.
The paper’s lesson is simple:
Do not only ask whether an agent can start working. Ask whether it knows when it must stop.
Automation without a brake is not efficiency. It is risk.
References
Key Takeaways
- - Infinite Agentic Loops are not ordinary while-true bugs; they emerge from agent logic, framework behavior, tool feedback, and weak termination rules.
- - A seemingly reasonable sequence of planning, tool use, observation, and replanning can still fail to converge.
- - Runaway loops can consume budget, grow context, overload services, and repeat real-world side effects.
- - Budgets, timeouts, step limits, idempotency, approval gates, and replayable logs are practical first defenses.
Need another practical guide?
Search for related tools, error messages, setup guides, and engineering notes across the site.
FAQ
Are Infinite Agentic Loops just normal programming loops?
No. They can span model calls, tools, workflow transitions, memory updates, and agent handoffs. The failure emerges from the whole runtime feedback path.
Will a smarter model know when to stop?
Not reliably. Stopping is a system property shaped by termination criteria, budgets, tool responses, error handling, and state transitions.
Should ordinary users care?
Yes whenever an agent can send messages, modify files, submit forms, spend money, or operate external systems. These actions need explicit limits and confirmation.
Voluntary Support
Buy me a coffee
Voluntary support for field tests, server costs, and small open tools. No account, no subscription, no promised delivery.
Alipay QR code
Want to appear on the supporters wall?
After supporting, send your nickname, optional link, and one short note. I will review it manually before publishing.