How does an AI agent know when to stop?

The Problem: Agents Don't Naturally Know When They're Done

An AI agent doesn't finish a task the way a person does — it runs a loop: perceive the situation, reason about what to do, act, then observe the result. Then it runs the loop again. And again. Anthropic's engineering team defines agents as "LLMs autonomously using tools in a loop," and that loop only ends when something deliberately tells it to stop. Without an explicit stopping condition — a goal met, a maximum iteration count, or a handoff to a human — the loop has no reason to end.

That's not a theoretical concern. A large-scale academic study evaluated 6,549 real-world LLM agent repositories and confirmed 68 "Infinite Agentic Loop" failures across 47 real projects, at 91.9% precision. The consequences range from cost exhaustion to repeated external side effects — an agent calling the same broken tool, or writing the same record, over and over.

The financial stakes are real. One developer documented an agent racking up roughly $50 per minute while looping — a headline figure of $12,000 — spinning up Kubernetes clusters to solve a simple syntax error. The only thing that caught it was an external AWS budget alarm triggering at 3:14 AM. Nobody was watching the agent; the bill was.

And runaway behavior cuts both ways:

• Over-execution: agents repeat work they've already done — one anecdote describes an agent creating 847 duplicate customer records in production before anyone noticed the retry loop.
• Premature stopping: agents quit early, skipping a critical step because they incorrectly believe the task is complete.
• State drift: the same failure mode produces both — the agent loses track of what it has and hasn't done.

The premature-stopping problem is arguably the more dangerous one, because it looks like success. A benchmark analysis cited in industry research on agent loops found leading agents complete only 30–35% of multi-step tasks successfully — even 90% per-step accuracy yields roughly 35% end-to-end success across ten steps. An agent that confidently declares "done" while half the job remains isn't obviously broken. It's silently wrong.

The root causes are often mundane, too. As one practitioner deep-dive on LangGraph loops puts it, most endless loops aren't routing bugs — they're state update bugs, where the node an agent returns to never updates the field the router checks, so the exit condition stays true forever.

This is why stopping is now treated as an engineered property, not an emergent one. The skills an agent loads shape how it behaves inside these loops — and since research suggests roughly 26% of published agent skills carry at least one vulnerability, what you wire into the loop matters as much as the loop itself. That's the problem SkillzBench is being built to address: a free, independent directory where agent skills are security-scanned and benchmarked, with a free MCP connector that lets you control exactly which skills and tools your agent can see.

Why Framework Safety Rails Aren't Enough

Every major agent framework ships with a brake pedal — so why do agents still run away? The uncomfortable answer from recent research is that built-in safety bounds exist, but they don't reliably stop the failures that matter.

LangGraph enforces a default recursion limit of 25 steps, LangChain offers max_iterations, the OpenAI Agents SDK exposes max_turns, and CrewAI provides max_iter. On paper, every loop has a ceiling. In practice, a large-scale academic study scanning 6,549 real-world agent repositories confirms these mechanisms "do not eliminate IAL risks" — Infinite Agentic Loop risks — because developers omit them, misuse them, set ineffective values, or place them outside the actual feedback path. The study confirmed 68 runaway-loop failures across 47 real agent projects, at 91.9% detection precision.

The deeper problem is that some "bounds" aren't deterministic at all. A common LangChain pattern exits the loop only when finish_reason stops being "tool_calls" — but since the model itself controls that output, the arXiv authors call it "not a deterministic bound." The agent is effectively deciding when its own safety check applies. And even a genuine hard cap has a blind spot: as agent-loop analysis notes, a cap "doesn't stop the loop from confidently repeating a wrong answer within that limit." An agent can burn all 25 steps producing the same incorrect result, then report it as finished work.

The failure modes compound in three ways:

• Omitted or misplaced bounds — the cap sits outside the feedback path, so it never fires on the loop that actually runs.
• Model-controlled exits — stopping depends on what the model outputs, not on a counter the model can't argue with.
• Confident wrong answers — hard caps bound cost, not correctness; the agent repeats its error politely until the limit hits.

Perhaps most humbling for engineers: the root cause is usually boring. According to LangGraph practitioners, "most endless loops aren't routing bugs — they're state update bugs." The routing logic is correct, but the node it returns to never updates the field the router checks, so the exit condition stays true forever. No amount of clever prompting fixes a variable that never changes.

This is why the Frontier Model Forum recommends deterministic controls placed outside the agent's reasoning loop — limits on tool access and permitted actions that "cannot be overridden through context manipulation." What the agent loads and sees matters too: instruction packages like agent skills shape loop behavior, and with roughly 26% of published skills carrying at least one vulnerability, SkillzBench is building free security scanning and per-agent tool toggling so builders control exactly what enters the loop in the first place.

The Solution: Layered Stopping Mechanisms

Runaway agents don't fail because the model is dumb — they fail because nobody built the exit. The good news is that practitioners and researchers are converging on a layered answer, and it's changing how serious teams design agent systems.

Layer 1: explicit stopping conditions. Every agent loop needs a defined reason to end: the goal is satisfied, a maximum iteration count is reached, or the task is handed to a human. As Atlan's agent-loop analysis puts it, a loop without an explicit stopping condition "has no reason to end."

Layer 2: the "two-door exit." A quality gate alone can loop forever if the score never climbs high enough; a hard cap alone lets the agent confidently repeat a wrong answer within its limit. LangGraph practitioners recommend pairing both — stop when the output is good enough, and stop after N passes, with the default 25-step recursion limit acting as a safety net that kills the run if your logic fails.

Layer 3: the maker/checker split. In modern coding agents, a separate small model checks the stop condition after every turn — "the agent that wrote the code isn't the one grading it," as Addy Osmani describes the pattern. Because "done" is a claim, not a proof, independent verification matters.

Layer 4: deterministic controls outside the loop. The Frontier Model Forum recommends hard limits on tool access and permitted actions that "cannot be overridden through context manipulation." This is also why what an agent loads matters: research found roughly 26% of published agent skills carry at least one vulnerability, which is why SkillzBench is building security scanning and per-agent tool toggles into its free skills directory and MCP connector.

Layer 5: graceful error handling. When everything else fails, catch the recursion error and return a useful fallback rather than a crash.

The key insight from large-scale academic research — 68 confirmed infinite-loop failures across 47 real agent projects — is that the issue "is not the presence of a loop, but whether an effective bound covers its feedback path." Boris Cherny, head of Claude Code at Anthropic, sums up the discipline: "I don't prompt Claude anymore. I have loops running that prompt Claude... My job is to write loops." That discipline now has a name: loop engineering — treating termination as a first-class design problem, not an afterthought.

What This Means in Practice: Tuning, Budgets, and Verification

Knowing an agent should stop is theory; making it stop is engineering. The difference between a reliable agent and a $12,000 cloud bill usually comes down to a handful of deliberate controls you set before the loop ever runs.

Tune caps to expected behavior, not defaults. LangGraph's default recursion limit is 25 steps, but practical guidance suggests sizing limits relative to the task: 30–40 for an agent that typically needs ~10 tool calls, around 10 for a simple three-step flow. The cap should describe "normal" — anything beyond it signals a problem. And never rely on model-controlled exits alone; research on infinite agentic loops shows exits gated on model output are not deterministic bounds, because the model itself controls them.

Set external backstops the agent cannot override. In the widely cited $12,000 incident, an AWS budget alarm firing at 3:14 AM was the only thing that caught a runaway agent burning roughly $50 per minute. The Frontier Model Forum's guidance is explicit: deterministic controls must sit outside the agent's reasoning loop, where context manipulation cannot touch them.

A layered stopping strategy looks like this:

• A quality gate paired with a hard cap — the "two-door exit" — since a quality threshold alone loops forever if the score never climbs.
• Confidence-threshold escalation to a human reviewer, preventing the agent from guessing when it should ask for help.
• Budget alarms and circuit breakers that kill the run regardless of what the agent believes about its progress.
• Independent verification of "done" — a separate checker model grading the stop condition, not the agent that did the work.

That last point deserves emphasis. As Addy Osmani puts it, 'done' is a claim and not a proof — the maker/checker split applied to the stop condition itself is what turns a self-report into a verdict.

Finally, remember that stopping is also a security control. The skills and tools an agent loads shape both its behavior and its blast radius — published research found roughly 26% of agent skills carry at least one vulnerability, and the Frontier Model Forum notes that damage from any failure scales directly with granted permissions. Scoping what an agent sees per task, which MCP's per-task permissions allow, is as much a stopping control as any iteration cap. SkillzBench is building toward exactly this: a free directory of security-scanned skills plus a free MCP connector where you toggle precisely which skills and tools each agent sees — because an agent that can't touch something can't loop on it.

Going Further: Equipping Agents with Skills You Can Trust

If a stopping condition is the brake pedal for an agent, then the skills and tools you load into it are the steering wheel — and neither should be left to chance. An agent's behavior inside its loop is shaped by everything you equip it with, which means deliberate selection matters as much as deliberate termination.

The stakes are easy to underestimate. Agent skills — SKILL.md instruction packages built for tools like Claude Code, Codex, Cursor, and Gemini CLI — are multiplying across GitHub, but published research has found that roughly 26% of published agent skills carry at least one vulnerability. Load the wrong one, and you've handed a looping agent a faulty instruction set with your credentials in reach.

This is the same lesson the rest of the article teaches: control what the agent can do before you let it run. The Frontier Model Forum recommends deterministic controls placed outside the agent's reasoning loop — limits on tool access that can't be overridden by prompt manipulation — precisely because "the potential damage from any agent failure scales directly with the level of trust and permissions a user has granted." Per-task permission scoping, including one-time access to sensitive information, is a core part of that guidance.

SkillzBench is being built to make that kind of scoping practical for everyday agent builders. The idea is a free, independent directory of agent skills where every entry gets the treatment a careful engineer would want:

• Version pinning to a specific commit SHA, so you know exactly what code you're running
• License checks and automated security scans on every skill
• Sandbox benchmarking that measures each skill's actual Lift — tested with the same model, with and without the skill — published in percentage points
• A trust score from 0–100 built on security, quality, license, maintenance, and community signals, with Lift always shown separately so ratings and money never mix

Alongside the directory, SkillzBench is building a free MCP connector that works like a loadout screen for your agents: you toggle exactly which skills and tools each agent can see, and the agent only ever sees what you chose. It's the per-agent version of the "least privilege" principle that security researchers keep circling back to — the same instinct behind LangGraph's recursion limit and the two-door exit, applied to the agent's toolkit instead of its loop.

None of this is live yet. SkillzBench is pre-launch, with the team actively building the scanning, benchmarking, and connector infrastructure — but the waitlist and newsletter are open now if you want to follow the progress. The through-line from this whole article holds whether you're configuring a stop condition or picking a skill: an agent is only as trustworthy as what you deliberately gave it. Stopping conditions must be engineered, and so must the skills riding along inside the loop.