What Happens When Your AI Agent Overspends: A Post-Mortem

TL;DR

• AI agent overspending isn’t hypothetical. Documented incidents include a $47,000 bill from a multi-agent infinite loop, a $12,000 Kubernetes spiral, and function-call loops that continued spending after the client process was killed.
• These incidents share a root cause: no pre-execution spending enforcement. Dashboards showed normal activity. Alerts never fired. The money was gone before anyone noticed.
• Monitoring tells you what happened. Guard rails prevent it from happening. The difference is whether you’re reading a post-mortem or writing one.
• This post breaks down three real incidents and maps each one to the specific control that would have stopped it.

Incident 1: The $47,000 Conversation

What happened. A team deployed a multi-agent research system using LangChain. Two agents — an Analyzer and a Verifier — were designed to collaborate: the Analyzer produced research summaries, the Verifier checked them for accuracy.

The Verifier flagged an Analyzer output as incomplete. The Analyzer asked for clarification. The Verifier responded with instructions. The Analyzer asked again. And again. And again.

For 11 days.

The cost curve tells the story:

The system appeared healthy the entire time. No errors. Normal latency. Both agents were functioning exactly as designed — they just had no termination condition for the case where they couldn’t agree.

Why monitoring didn’t catch it. The dashboards tracked errors, latency, and uptime. All green. The billing dashboard updated daily, but nobody had set a billing alert with a threshold low enough to trigger before the damage was catastrophic. By the time the weekly cost review happened, $18,400 had already been spent.

The deeper problem: there’s no visual difference between “two agents productively collaborating” and “two agents trapped in an infinite clarification loop.” Both look like activity. Both generate tokens. Both cost money.

What would have prevented it.

A daily spending ceiling of $200 would have capped the total damage at $200. The system would have hit the ceiling on day 5, stopped, and reported that it had exhausted its budget. The team would have investigated, found the loop, and fixed the termination condition — for $200 instead of $47,000.

A per-transaction cap would have caught it even earlier. Each message exchange cost a few dollars in tokens. A cap of $10 per transaction wouldn’t have triggered on any individual exchange, but a circuit breaker that escalated to human review after 50 consecutive transactions in a period would have.

Incident 2: The $12,000 Kubernetes Spiral

What happened. An AI agent was tasked with fixing a zombie process in a Rust microservice. The underlying issue was a syntax error — a small fix. The agent’s approach was less small.

It decided the fix required a clean deployment environment. So it provisioned a new Kubernetes cluster. The deployment failed because of the original syntax error. The agent interpreted the failure as an environment problem and provisioned another cluster with different configuration. Then another. Then another.

At $50 per minute of compute time, the bill reached $12,000 before a human noticed the cluster count climbing.

Why monitoring didn’t catch it. The agent was using legitimate cloud APIs. Every API call succeeded. The monitoring system tracked whether the agent completed its task (it didn’t) but had no mechanism to flag how much the agent was spending trying to complete it.

Cloud cost dashboards had a 4-6 hour reporting lag. By the time the daily cost digest arrived, the spiral had been running for hours.

What would have prevented it.

A hard per-transaction cap of $100 would have blocked the first cluster provisioning that exceeded it. The agent would have received a rejection explaining the limit, and either tried a cheaper approach or escalated to a human.

More importantly, a recipient firewall that restricted which services the agent could pay would have prevented it from autonomously provisioning cloud infrastructure. The agent was authorized to fix code. It should not have been authorized to spin up Kubernetes clusters.

Incident 3: The Unkillable Function Loop

What happened. A developer set up a GPT-4 agent with function calling to process a batch of documents. The processing logic contained a retry mechanism: if a function call returned an unexpected result, the agent would retry with adjusted parameters.

One document consistently returned unexpected results. The agent retried. And retried. For 12 hours.

The developer noticed the cost climbing ($260) and killed the client process. The spending continued. The server-side loop was still processing queued function calls, and killing the client didn’t cancel the in-flight requests.

This is a less dramatic number than the other incidents, but the pattern is more alarming: the developer actively tried to stop the spending and couldn’t.

Why monitoring didn’t catch it. The developer assumed that killing the client process would stop the spending. It didn’t. Server-side function execution continued independently. There was no kill switch that operated at the transaction level — only at the client level, which wasn’t enough.

What would have prevented it.

A periodic budget reset with a daily cap would have stopped the bleeding automatically. If the agent’s daily budget was $50, spending would have halted at $50 regardless of whether the client was alive.

More fundamentally, a spending system where the agent must actively authorize each transaction — rather than one where transactions queue and execute autonomously — would have let the developer halt spending by simply not authorizing the next transaction. In Botwallet’s model, the agent holds half the signing key. Stop the agent, and no new transactions can be signed. The server can’t spend on its own.

The Pattern Behind All Three

These incidents look different on the surface. An infinite loop, a resource spiral, an unkillable retry. But they share the same structural failure:

No pre-execution spending enforcement.

All three systems checked after spending happened. Dashboards updated after API calls completed. Billing alerts triggered after thresholds were crossed. Cost reviews happened after invoices arrived.

The fundamental mistake: treating agent spending as a monitoring problem instead of an authorization problem.

Monitoring answers: “how much did the agent spend?” Authorization answers: “should the agent be allowed to spend this?”

The difference is whether the answer comes before or after the money is gone.

The Pre-Execution Model

Botwallet’s guard rails are built around one principle: every transaction is checked before it executes, not after.

Here’s how each control maps to the incidents above:

The last row is the one that matters most. Guard rails enforced in application logic are suggestions — the agent, or anyone controlling the agent, can work around them. Guard rails enforced cryptographically are physics. The agent holds half the key. The server holds the other half and checks policy before co-signing. No policy approval, no signature, no transaction.

Writing Your Own Post-Mortem vs. Preventing One

Every overspending incident follows the same timeline:

1. Agent starts working. Everything looks fine.
2. Something goes wrong. Agent keeps spending.
3. Time passes. Cost accumulates exponentially.
4. Human discovers the damage. Reaction time determines the final bill.

Steps 2 through 4 are the blast radius. Guard rails collapse them to zero. The transaction that would have started the spiral gets checked against policy, blocked, and reported — before any money moves.

The setup takes five minutes. The alternative takes a post-mortem, a budget review, and an explanation to whoever approved the cloud spend.

The teams behind these incidents weren’t careless. They built monitoring. They reviewed dashboards. They had billing alerts. In the emerging agent economy, where agents transact autonomously at machine speed, retrospective controls aren’t just insufficient — they’re irrelevant.

None of it mattered because all of it was retrospective.

An agent with no spending limits is an open credit line with no human at the register. The question was never if it would overspend. The question was how much damage it would do before someone noticed.

Set the limits before you deploy. Not after you get the bill.