When an AI agent calls a tool, that tool calls another agent, which calls the first tool again—and nothing checks whether this has happened before—you have uncontrolled recursion. It is not a hypothetical edge case. In 2025, incident reports from agent frameworks like AutoGPT-style planners, LangChain-based pipelines, and custom multi-agent orchestrators began describing the same failure mode: a planning agent delegates a sub-task to a "worker" agent, the worker decides the task is still too big and delegates back to a planner-like function, and the loop repeats until the process exhausts its stack, its token budget, or its cloud bill. One publicly discussed case involved a customer-support agent that re-invoked its own summarization tool 40,000+ times in under three minutes before a hard timeout killed the container. Traditional software has decades of recursion-depth guardrails. Most agent frameworks shipped without any.
What Is Uncontrolled Recursion in AI Agent Loops?
Uncontrolled recursion is when an AI agent's own tool-calling or sub-agent-spawning logic re-enters itself without a bounded exit condition, consuming compute, tokens, or memory until an external limit (or a crash) stops it. In classical programming, recursion is bounded by a base case the developer writes explicitly—if n == 0: return. In an LLM-driven agent, the "base case" is a judgment call the model makes at inference time: it decides whether a subtask is complete, whether to call itself again, or whether to hand off to another agent. That judgment is probabilistic, not deterministic. A model that is 98% reliable at recognizing "this task is done" will still fail 1 time in 50—and in a loop that calls itself thousands of times per session, a 2% failure rate guarantees runaway recursion eventually happens. Frameworks like LangGraph, CrewAI, and AutoGen all support recursive agent-to-agent handoffs, and as of their 2024-2025 releases, only some ship a default recursion_limit (LangGraph defaults to 25 as of v0.2), while others leave depth entirely unbounded unless the developer adds it.
Why Do AI Agents Get Stuck in Recursive Loops?
Agents get stuck in recursive loops because the model's stopping decision degrades under ambiguity, and multi-agent architectures amplify that single-point failure across every hop in the chain. Three specific triggers show up repeatedly in incident writeups from 2024-2025:
- Ambiguous task decomposition. A planner agent breaks "research X" into sub-tasks, one sub-task turns out to be equally broad, and the model re-applies the same decomposition prompt to it—recreating the original task under a new name. This is functionally identical to infinite recursion with no decreasing counter.
- Tool-result echo. A tool returns an error or a partial result that resembles the original query closely enough that the agent's retry logic re-issues the same tool call, sometimes appending the growing error trace to context each time, which inflates token cost per iteration.
- Cross-agent delegation cycles. In multi-agent setups (planner → executor → reviewer → planner), a reviewer agent that rejects work sends it back to the planner, which reissues an equivalent plan, producing a cycle across three or more agents that no single agent's local logic can detect—because no individual agent has visibility into the full call graph.
Anthropic's own guidance on building agents (published 2024) explicitly recommends capping iteration counts and adding "circuit breaker" checks precisely because model-driven stopping conditions are not reliable enough to trust alone.
How Much Can Runaway Recursion Actually Cost?
Runaway recursion can turn a $0.02 task into a $500+ bill in minutes, because every recursive hop typically re-sends accumulated context to the model, and cost scales with both call count and growing token volume. Consider a loop that calls a tool 5,000 times before an external timeout intervenes (a figure consistent with several publicly shared incident postmortems from teams running unbounded LangChain agents in 2024). If each call carries even a modest 2,000-token context window at $3 per million input tokens, that's 10 million tokens—roughly $30 in raw model cost for a single stuck session, before counting the compute for whatever tool the agent is calling (a database, a code sandbox, another API with its own per-call billing). Multiply by concurrent sessions in production and the number compounds fast. Beyond dollars, the same failure mode causes denial-of-service against shared infrastructure: a recursive agent hammering an internal API or a third-party rate-limited endpoint can degrade that service for every other consumer, turning an AI reliability bug into a shared-infrastructure incident.
Is Uncontrolled Recursion a Security Issue or Just a Bug?
It is both, and the security dimension is the part most teams underestimate: uncontrolled recursion is a resource-exhaustion vulnerability that an attacker can trigger deliberately, not just an accident that happens on its own. If an agent's recursion depth or retry logic responds to attacker-influenced input—a crafted document the agent summarizes, a malicious tool response, a poisoned prompt injected into a webpage the agent browses—then an external party can intentionally induce the same runaway loop that occurs by accident, achieving a denial-of-service or a cost-exhaustion attack against the target organization. This maps directly onto OWASP's LLM Top 10 categories: LLM04 (Model Denial of Service) explicitly calls out resource-exhaustion attacks against LLM applications, and OWASP's 2025 Agentic AI security guidance added excessive agency and uncontrolled resource consumption as named risks specific to autonomous agent architectures. A recursion bug that is purely accidental in testing becomes an exploitable attack surface the moment the agent processes untrusted input—which is nearly every production agent that reads emails, web pages, tickets, or files it did not generate itself.
What Does a Real Recursive-Loop Failure Look Like?
A real failure typically looks like a single ambiguous instruction cascading through dozens of agent-to-agent handoffs before anyone notices, because agent orchestration logs are often incomplete or scattered across services. In one widely circulated 2024 community writeup, a developer building a documentation-generation agent on top of an early multi-agent framework found their process had made over 12,000 recursive calls to a "clarify requirements" sub-agent after the initial task description was underspecified—each call slightly rephrasing the same unresolved ambiguity and re-delegating rather than surfacing it to a human. The process only stopped when it hit the LLM provider's rate limit, not because any internal control fired. This pattern—silent recursion bounded only by an external rate limit or billing cap—is common precisely because most teams instrument agent success and latency, but not call-graph depth or recursive self-reference, leaving the failure invisible until a bill or an outage forces a look.
How Safeguard Helps
Safeguard treats uncontrolled recursion as a supply chain and runtime risk that has to be caught before an agent workflow ships and watched continuously after it does. On the pipeline side, Safeguard's SAST and dependency analysis flag agent orchestration code—LangGraph graphs, CrewAI crews, custom recursive tool-call handlers—that lacks an enforced recursion_limit, a maximum iteration count, or a circuit-breaker check, so the gap is caught in code review instead of production. Safeguard also maps agent-to-agent and agent-to-tool call graphs across your codebase to surface cross-agent delegation cycles (planner → executor → reviewer → planner) that are invisible when each agent's code is reviewed in isolation. At runtime, Safeguard's monitoring correlates agent invocation volume, token spend, and tool-call depth per session so a recursive spiral is flagged in minutes rather than discovered on next month's invoice or after a downstream service is degraded. And because uncontrolled recursion becomes a genuine attack surface once an agent processes untrusted input, Safeguard's AppSec workflows treat agent input sources—scraped web content, inbound documents, third-party API responses—as tainted data and check whether that taint can reach control-flow decisions like retry counts or delegation logic. For teams building or auditing AI agent systems, that combination—static checks on iteration bounds, call-graph visibility across agents, and runtime cost/depth monitoring—turns a class of failure that is currently mostly invisible into one you can catch before it costs you a five-figure cloud bill or a production outage.