Book a call (opens Google Calendar)
Book a call (opens Google Calendar) hey@pronovahq.com

The 4 AI "Loops of Death" That Kill Budgets (And How to Stop Them)

By Izzy Aly, Co-Founder, Systems and Architecture

Autonomous agents don't crash when they fail; they burn capital. The four loops that drain agent budgets, and the per-feature caps and kill switches that stop them.

Picture this: It's 2:00 AM. Your on-call engineer gets an alert, not because a server crashed, but because your OpenAI bill just spiked by €1,000 in four hours.

You rush to the dashboard. The agent hasn't crashed. It's reporting "200 OK" on every single API call. It's not solving the ticket. It's just... spending.

This is the Agentic Loop of Death.

If your business is moving from stateless chatbots to autonomous agents, or you're the owner or ops lead who signs off on one, this is the single most significant risk to your P&L.

Below: why these loops occur, the four types to watch for, the other ways an agent bill runs away, and how we cap agent budgets with per-feature token budgets, hard caps and kill switches.

The "Denial-of-Wallet" Reality

In traditional software engineering, an infinite loop hangs the CPU. You restart the service, maybe patch a while(true) bug, and move on. The cost is negligible.

In AI engineering, an infinite loop is a financial event. We call this a Recursive Integrity Failure.

The best-known case: a multi-agent system built on LangChain ran up a $47,000 bill, with its weekly API cost climbing from $127 to $18,400. Two of its agents got stuck in an infinite conversation loop, talking to each other for 11 days before anyone noticed, according to the engineer who reported it (Towards AI, 2025). It wasn't a traffic spike. It was a loop.

Why does this happen? Because agentic control flow is probabilistic rather than deterministic. When an agent gets confused, it doesn't throw a NullReferenceException. It tries to "think" its way out. It retries tools. It hallucinates corrections. It delegates to other agents.

This isn't just bad coding; it's Instrumental Convergence. AI theory predicts that a goal-driven agent will seek more resources (compute, API access, tokens) to guarantee success. Your agent isn't trying to break the bank; it's trying not to fail, at any cost. It treats "budget" as an obstacle rather than a constraint.

An agent tasked with "optimizing database performance" may realize that restarting the service clears the RAM, and restart your production database every 5 minutes. To the agent, that's a win.

And every single step costs you money.

The four loops of death: symptom, detection signal and fix A grid of the four agent loop types. Type I, the Dumb Loop: a retry storm on ambiguous errors, detected when the same Tool(Name, Args) call appears 3 or more times in a sliding window, fixed by killing the process and capping retries at 3 to 5. Type II, the Blind Loop: 200 OK but the state is unchanged, detected when the state hash at step t equals step t-1, fixed by forcing a stop or asking a human. Type III, the Anxious Loop: critic and generator spiral, detected by apology keywords and oscillating output, fixed by downgrading the model or escalating to a human. Type IV, the Bureaucratic Loop: agents ping-pong a task, detected by zero progress delta between agents, fixed by a supervisor that ends the branch. LOOP AND SYMPTOM DETECTION SIGNAL FIX I. Dumb Loop retry storm on errors same Tool(Name, Args) 3+ times in a window kill the process, cap retries at 3–5 II. Blind Loop 200 OK, state unchanged state hash at step t equals step t−1 force a stop or ask a human III. Anxious Loop critic–generator spiral apology keywords, oscillating output downgrade the model, or escalate to a human IV. Bureaucratic Loop agents ping-pong a task zero progress delta between agents supervisor ends the branch
The four loops of death: detection signal and fix Four stacked cards, one per agent loop type. Type I, the Dumb Loop: the same tool call 3 or more times; fix by killing the process and capping retries at 3 to 5. Type II, the Blind Loop: the state hash is unchanged between steps; force a stop or ask a human. Type III, the Anxious Loop: apologies and oscillating output; downgrade the model or escalate. Type IV, the Bureaucratic Loop: zero progress delta between agents; a supervisor ends the branch. LOOP AND SIGNAL FIX I. Dumb Loop same tool call 3+ times kill the process, cap retries at 3–5 II. Blind Loop state hash unchanged force a stop or ask a human III. Anxious Loop apologies, oscillation downgrade model or escalate IV. Bureaucratic Loop zero progress delta supervisor ends the branch
Fig. 1 — The four loops of death at a glance: what each looks like, the signal that catches it, and the fix.

1. Type I: The Tool-Call Retry Storm ("The Dumb Loop")

The Problem:

The most common failure. An agent calls an external function (a database query, an API) and receives an ambiguous error, such as 500 Internal Server Error or Unknown Parameter.

Driven by rigid instruction-following ("You must complete the task"), the agent decides the best course of action is to try again. And again. And again.

The Real-World Impact:

Because the error message provides no new context, the next generation collapses onto the previous action. The context window fills with identical error logs, displacing the original instructions. The agent hammers your internal APIs until it hits a rate limit or burns your credit card.

It gets worse when the agent caused the error itself. If an agent hallucinates a parameter (e.g., inventing a User ID), it will likely hallucinate the same parameter on a retry with the same context. Blind retries reinforce the hallucination. To fix this, you don't need a retry; you need a state change.

The Fix:

You cannot rely on the LLM to realize it's stuck. You need a Structural Heuristic in your orchestration layer.

  • Implement N-Gram Tool Repetition detection: If Tool(Name, Args) appears identical >=3 times in a sliding window, kill the process.
  • Hard Circuit Breakers: Exponential backoff isn't enough. You need a hard stop on consecutive failures: 3 to 5 retries per task is usually plenty. And don't trust the clock: a 60-second timeout is too slow for an agent that can fire 10 API calls per second.
  • Log every retry: Use structured metadata (task_id, attempt_number, error_type, token_count). If an agent is retrying more than 10% of the time, something is wrong with the prompt or the tool configuration, not with the retry count.

2. Type II: State Stagnation ("The Blind Loop")

The Problem:

This is more insidious because the agent is technically succeeding. It executes actions, gets valid "200 OK" responses, and thinks it's working. However, the system state remains invariant.

Example Scenario:

An agent is tasked with summarizing a log file.

  1. The agent reads logs.txt.
  2. File is empty.
  3. The agent thinks, "I need to read the logs to summarize them."
  4. Agent rereads logs.txt to "make sure."
  5. Repeat ad infinitum.

The Real-World Impact:

The agent perceives itself as active. It burns tokens during reasoning steps ("I will check the file again"), but the state at step t+1 is almost identical to the one at step t. You pay for activity, not progress.

The Fix:

State Hash Invariance. Calculate a hash of the agent's observation + working memory at each step. If the hash at step t equals the hash at step t-1 for consecutive turns, the agent is spinning its wheels. Force a "stop" or inject a "System 2" interrupt to ask a human for help.

3. Type III: Self-Correction Hallucinations ("The Anxious Loop")

The Problem:

This loop kills teams using "Reflexion" or "Critic" architectures (where one agent generates code and another critiques it).

A hyper-sensitive "Critic" agent rejects an output. The "Generator" agent attempts to fix it. But LLMs suffer from intrinsic self-correction failure (Huang et al., arXiv:2310.01798): if the Critic hallucinates a flaw, or the Generator doesn't know how to fix it, they spiral.

The Real-World Impact:

The transcript fills with apologies: "I apologize for the confusion. Let me correct that." The agent oscillates between two incorrect answers or rewrites the same code with variable names changed, trying to satisfy a vague critique. It's the AI equivalent of a nervous breakdown.

The Fix:

Cognitive Interrupts. Monitor the transcript for high frequencies of apology keywords or oscillating output content (using cosine similarity on the "thought" trace). If detected, downgrade the agent to a simpler model or escalate to a human.

4. Type IV: Multi-Agent Oscillation ("The Bureaucratic Loop")

The Problem:

As you scale to Multi-Agent Systems (MAS), you encounter the "Ping-Pong" effect.

  • Agent A (Planner) delegates a task to Agent B (Executor).
  • Agent B determines that the task is out of scope or lacks permissions, so it delegates it back to Agent A.
  • Agent A sees that the task is still undone and delegates it back to Agent B.

A second version comes from conflicting intents. A "Security Agent" locks a suspicious account while a "Support Agent" restores access to resolve a ticket. They enter a Deadlock State, two bots spending your money fighting each other. Standard observability sees "high activity" and healthy throughput.

The Real-World Impact:

It isn't easy to debug because each agent appears to behave rationally given its local context. You only see the problem when the bill arrives or the latency spikes to infinity.

The Fix:

The Supervisor Pattern. Eliminate peer-to-peer delegation. Use a hub-and-spoke topology where a central "Supervisor" agent manages state. The Supervisor acts as a natural circuit breaker. If Agent B returns a result with zero progress delta, the Supervisor terminates the branch rather than passing it back to Agent A. The same hub settles conflicting intents: one owner decides whether the account stays locked.

Peer-to-peer ping-pong versus the supervisor pattern Two set-ups side by side. Left, peer-to-peer: Agent A, the planner, delegates a task to Agent B, the executor, which hands it back, and the loop repeats with no progress while the bill keeps running; dashboards read the activity as healthy. Right, the supervisor pattern: a central supervisor holds state and routes work to Agent A and Agent B. A result with zero progress delta stops at the supervisor, which terminates the branch instead of passing it back. The same single owner settles conflicts such as one agent locking an account while another restores it. PEER-TO-PEER SUPERVISOR PATTERN Agent A Planner delegates hands it back Agent B Executor No progress, the bill keeps running Supervisor holds state, one owner Agent A Planner Agent B Executor Zero progress delta: branch terminated Each agent looks rational Dashboards read it as healthy. One owner at the hub It also decides lock or restore.
Peer-to-peer ping-pong versus the supervisor pattern Two set-ups stacked. Top, peer-to-peer: Agent A, the planner, delegates to Agent B, the executor, which hands the task back; no progress, and the bill keeps running. Bottom, the supervisor pattern: a supervisor holds state and routes to Agent A and Agent B, and a result with zero progress delta terminates the branch at the supervisor instead of bouncing back. PEER-TO-PEER Agent A Planner Agent B Executor No progress, the bill keeps running SUPERVISOR PATTERN Supervisor holds state, one owner Agent A Agent B Zero progress: branch terminated
Fig. 2 — Peer-to-peer delegation lets two agents ping-pong a task indefinitely. A supervisor that owns state ends the branch when progress stops.

Loops aren't the only way the bill runs away

Loops get the headlines, but they're one of several behavioural failures. Traditional infrastructure costs scale with capacity. LLM costs scale with behavior: a prompt change, a user who pastes in a 50-page document, an agent that retries 21 times on one task. That's why LLM costs are so hard to forecast: in Benchmarkit and Mavvrik's 2025 survey of 372 companies, 85% missed their AI cost forecasts by more than 10% (Benchmarkit and Mavvrik, September 2025). Their 2026 edition puts it at 89% (Mavvrik, July 2026).

Unbounded user sessions

Each message appends to the context window, and by message 40, you can be sending 100K tokens per request. That one power user who treats your chatbot like a therapist? They might be costing you more than your next 500 users combined, with no traffic spike to warn you.

The fix: Summarize the conversation after a threshold (e.g., every 20 messages), and give users a generous but finite session length.

Prompt injection and "Denial of Wallet" attacks

A malicious (or even just creative) user can craft inputs that force your model into expensive behavior. The OWASP Top 10 for LLM Applications lists this as "Unbounded Consumption" (OWASP LLM10:2025). "OverThink" attacks plant decoy problems in the content a reasoning model reads, inflating its hidden reasoning tokens while producing output that looks completely normal. The researchers measured increases of up to 46x (Kumar et al., arXiv:2502.02542). Because the output appeared correct, no one investigates until the invoice arrives.

The fix: Output and input bounds (Step 4 below), plus an alert on reasoning tokens that spike without a matching rise in output length.

Context window bloat

As context windows grow, the temptation is to stuff everything in. System prompts grow. Retrieved documents pile up. It's a slow, invisible tax on every single API call. A system prompt that grew from 500 tokens to 5,000 tokens over three months of "just adding one more instruction" increases your base input cost by 10x before the user even types anything.

The fix: Measure the token count of every component (system prompt, retrieved context, history, user input) and set a budget for each.

Model and deployment misconfiguration

Using your largest model when a small one would work. Leaving a test deployment running over the weekend. Setting the temperature to 1.0 when 0.3 would give you tighter, more predictable responses. These aren't engineering failures. They're configuration oversights that compound at scale.

The fix: Use the cheapest model that meets your quality bar, and build a "kill switch" into every deployment. If you can't shut it down quickly, you can't control it.

Why "Wait and See" Is a Dangerous Strategy

You might be thinking, "We'll just monitor the logs." Here is the hard truth: Standard APM tools will not save you. A standard Datadog or New Relic setup sees HTTP 200 responses from OpenAI and assumes everything is fine. Unless you've added LLM-specific tracing, it tracks latency and uptime, not semantic progress or token burn velocity.

If you are building agents without a way to see what each session spends and why, you are effectively handing a corporate credit card to a stochastic intern and leaving the room.

Not every risk is financial, either. Agents trained to be "helpful" can drift into overly casual tones over long conversations: the JSON is valid, the reputational damage is immediate. And when an agent performs a complex task like reconciling payments without a structured audit trail, you lose the record of why it acted. Most logging tools only capture the final output, not the reasoning trace. For high-risk systems, the EU AI Act's Article 12 requires automatic record-keeping, and under the Digital Omnibus the Annex III high-risk obligations now apply from 2 December 2027 (Regulation (EU) 2026/1744). If someone asks why a decision was made, "The AI did it" is not an answer.

Optimization is a diet. Governance is a seatbelt.

Most teams focus on optimization: cheaper models, shorter prompts, caching. These are good practices. But cost optimization only reduces your average spend. Cost governance prevents your worst-case spend. You should do both, but only one of them saves your life in a crash.

How we cap agent budgets

Stop looking at your "Total Monthly Spend." Most teams treat LLM spend like an aggregate AWS bill. But in the world of agents and reasoning loops, costs scale with complexity, not traffic. A single agent stuck in a tool-calling loop can burn through $50 in minutes. Deploy that agent to 1,000 users and you have a financial catastrophe on your hands. You need to start thinking in Unit Economics per Feature.

Step 1: Back into your "Safe Zone"

Before you write a single line of enforcement code, you need a ceiling. Look at your revenue or your project budget, and decide what share of it AI is allowed to cost. Do the math: if your product generates €500,000/month and you cap AI at 5%, your total AI budget cap is €25,000.

That is your "Global Hard Limit." Now, you have to allocate it.

Step 2: Segment budgets by "Product Surface"

This is where most teams fail. They set a budget for "OpenAI" or "Anthropic."

But your users don't interact with "Anthropic." They interact with a code assistant, a support chatbot, an internal data analyst. Assign a specific financial envelope to each surface based on the value it delivers.

  • The "High-Value" surface: your Code Assistant drives retention, so you tolerate higher spending here. Model: your most capable one. Budget: €15,000/month. Limit strategy: soft limits. We want this to work, even if it gets expensive.
  • The "Low-Value" surface: your generic FAQ bot. Model: the smallest one that meets your quality bar. Budget: €2,000/month. Limit strategy: hard kill switch. If this spikes, shut it down. It's not worth the overage.

Step 3: Enforce limits at the gateway layer

Policy without enforcement is just a suggestion. You cannot rely on the model providers for this. Provider spend limits work per organization, project or workspace, not per feature; they won't stop your "Search Feature" from eating your "Support Feature's" lunch. You need a gateway between your code and the LLM, with three tiers of defense for every feature, a "Traffic Light" system:

  1. The Soft Alert (70% of budget): When the "Support Bot" hits €1,400 of its €2,000 budget, the tech lead and the feature owner get a Slack notification. No action has been taken, but it is being monitored.
  2. The Rate Throttle (90% of budget): Traffic is slowing down. Consider switching the model routing dynamically from your large model to a smaller one to stretch the remaining budget. You degrade quality slightly to preserve uptime.
  3. The Hard Stop (110% of budget): The circuit breaker trips. The API returns a cached response or a static "We are experiencing high load" message. This prevents the surprise invoice.
The traffic-light rule for one feature budget A budget bar from 0 to 110% of the Support Bot's 2,000 euro monthly budget with three thresholds. At 70%, 1,400 euros, a soft alert: a Slack notification to the tech lead and the feature owner. At 90%, 1,800 euros, a rate throttle: route traffic to a smaller model. At 110%, 2,200 euros, a hard stop: the API returns a cached or static response. Context: a global cap of 25,000 euros a month, 5% of 500,000 euros of revenue, with the high-value surface on 15,000 euros with soft limits and the low-value surface on 2,000 euros with a hard kill switch. SUPPORT BOT, €2,000 A MONTH 0% 70% 90% 110% normal spend alert throttle 100% budget 70% · €1,400 Soft alert Slack to the tech lead and feature owner 90% · €1,800 Rate throttle route to a smaller model 110% · €2,200 Hard stop cached or static response Global cap: €25,000 a month, 5% of €500,000 revenue. High-value surface €15,000 on soft limits; low-value €2,000 on a hard kill.
The traffic-light rule for one feature budget A budget bar from 0 to 110% of the Support Bot's 2,000 euro monthly budget, then three tiers. At 70%, 1,400 euros, a soft alert: Slack to the tech lead and feature owner. At 90%, 1,800 euros, a rate throttle: switch to a smaller model. At 110%, 2,200 euros, a hard stop: a cached or static response. The global cap is 25,000 euros a month, 5% of 500,000 euros. SUPPORT BOT, €2,000 A MONTH 0% 70% 90% 110% normal spend Soft alert 70% · €1,400 Slack to the tech lead and feature owner Rate throttle 90% · €1,800 route to a smaller model Hard stop 110% · €2,200 cached or static response Global cap €25,000 a month, 5% of €500,000
Fig. 3 — The traffic-light rule for one feature budget, enforced at the gateway: alert at 70%, throttle at 90%, hard stop at 110%.

Step 4: Bound every session and every call

The next layer stops one user or one request from eating a feature:

  • Per-session and per-user limits: no single user or session may consume more than a defined share of your daily budget. A circuit breaker that cuts a session off at, say, €5 turns a runaway loop into a failed task.
  • Output token bounds: always set max_tokens. On every call. No exceptions.
  • Input size limits: a 200K token input to a customer support chatbot is either a mistake or an attack. Either way, don't process it.

Step 5: The "Staging" budget

The most dangerous code is the code you haven't shipped yet.

We see this constantly: a developer runs a test script over 5,000 prompts on Friday afternoon, goes home, and by Monday has burned €5,000 in a development environment. Your Staging and Dev environments need the strictest budgets of all: €50/day per engineer, hard stop.

If an engineer needs to run a massive eval, they must request a temporary increase in the limit. This adds a layer of friction, forcing them to double-check their math before hitting "Run."

Step 6: Show everyone the bill

At the end of every week, a dashboard should show exactly who spent what:

  • Team Alpha (Search): €400 (Under Budget).
  • Team Beta (Agents): €1,200 (Over Budget due to loop error).

We call this "Showback." You aren't the "bad guy" policing spending; you're giving teams the data to own their own P&L.

When Autonomous Agents Might Not Be Right For You

We are huge proponents of agentic AI. But we also believe in using the right tool for the job. You might want to pause on full autonomy if:

  1. Your Budget is Fixed: If you cannot absorb a variable cost spike of 20–30% in a single month due to a testing error, stick to deterministic code or human-in-the-loop workflows (Copilots) for now.
  2. You Lack "Hard Kill" Infrastructure: If you can't remotely terminate a session based on budget thresholds, you are not ready for production agents.
  3. Low Tolerance for Hallucination: Agents in loops hallucinate more as their context window fills with errors. If accuracy is paramount, you need stricter guardrails.

The other way round, the full set of guardrails may be more than you need yet: if your LLM spend is under €1K/month, if you're not running agents or multi-step workflows, or if a platform team has already built internal cost controls. But if you're spending €5K or more per month, running autonomous agents, and you don't have hard budget caps in place? You're one misconfigured deployment away from a terrible Monday morning.

Engineering For The Loop

The "Loop of Death" isn't a bug; it's an emergent property of the technology. It will happen. The difference between a minor hiccup and a five-figure bill is your infrastructure.

That's why the agents we build for clients ship with three controls from day one:

  • Financial Circuit Breakers: Hard budget limits per session and per feature.
  • Loop Detection: Repeated tool calls and stagnant states trip a stop, not a retry.
  • Audit Logs: A record of exactly why the agent got stuck, for debugging and for compliance.

You don't have to choose between innovation and bankruptcy. You need to build with your eyes open.

Topics
Author
Izzy Aly · Co-Founder, Systems and Architecture
Share

Keep reading

All posts →