The $47K agent loop: why logging, monitoring, and max_tokens all failed to stop it

ADARSH PRASHAR — Sun, 07 Jun 2026 15:28:36 +0000

In November 2025, four AI agents ran for eleven days and produced a $47,000 bill.

You've probably seen the story. A market-research pipeline: four LangChain agents coordinating over A2A. Two of them — an Analyzer and a Verifier — started ping-ponging. The Analyzer produced analysis, the Verifier asked for more, the Analyzer produced more. No termination condition, no budget cap. Eleven days later the invoice showed up.

The number is what makes it travel. But the number is not the interesting part. This is the interesting part, from the post-mortem:

They had logging. They had monitoring. They did not have a hard limit.

Sit with that. The team was not flying blind. The data was all there — every call, every token, every dollar, streaming into a dashboard the whole time. None of it mattered, because observability is a witness, not a circuit breaker. It can tell you the building is on fire. It cannot close the gas valve.

I want to walk through why the usual defenses don't catch this, and what the thing that actually catches it has to look like. Not the product pitch — the mechanism. If you run agents in production, this is the failure mode that should keep you up at night, and it's more structural than it looks.

The failure mode: a thousand perfectly valid calls

A runaway agent is not one big anomalous request. It's a thousand small, individually reasonable ones.

Every single call the Analyzer and Verifier made was well-formed. Each was under its max_tokens. Each returned a 200. Each looked, in isolation, exactly like a healthy agent doing its job. The pathology only exists at the level of the run — the loop that never closes — and almost nothing in a normal stack is watching at that level.

That's why the obvious guards slide right off it:

max_tokens is per-call, not per-run. It bounds the size of one response. It has nothing to say about ten thousand responses. A loop is the size of a tweet, ten thousand times.
Cost dashboards are post-hoc. They render spend after the calls have already happened and the money is already gone. By design they trail reality. The fire has to start before the smoke detector has anything to detect.
Alerts need a human in the loop, awake, watching. "Spend exceeded $X" fires into a Slack channel at 3am on a Saturday. Nobody saw it for eleven days because seeing it was a person's job, and people sleep, and go on vacation, and assume the thing that's been fine is still fine.

Each of these is useful. None of them is a stop. They are all instruments on the dashboard; not one of them is the brake pedal.

What a stop actually requires

If you want to stop a runaway run — not narrate it — the enforcement has to satisfy three properties. Miss any one and you're back to writing post-mortems.

1. It has to be deterministic. No model in the decision path. The whole problem is an unbounded non-deterministic system; you do not get to bound it with another non-deterministic system and call it safe. "We added an LLM that decides when to stop the LLM" is not a control, it's a second thing that can fail. The limit is total_cost > ceiling evaluated in compiled code, or it is not a limit.

2. It has to be pre-call. The check runs before the next request leaves your process, and refuses it. Anything that runs after the call has, by definition, already let the call happen and the dollars leave. Post-hoc enforcement is a contradiction — the enforcement and the spend race, and the spend wins.

3. It has to be per-run, not per-call. The unit that goes wrong is the run: total dollars, total loop iterations, total wall-clock, accumulated across every call the run makes — plus a kill switch you can pull from outside. That's the altitude the pathology lives at, so that's the altitude the budget has to live at.

Deterministic, pre-call, per-run. That's the shape of a brake pedal. I'll say the obvious thing: this is not novel computer science. It's a hard-coded resource governor, the kind of thing operating systems and databases and trading systems have had for decades. The novelty is purely that the agent world skipped it.

I've built this before, in a less forgiving domain

I've spent years building deterministic risk engines that wrap non-deterministic systems — the kind where a mistake costs real money, in real time, with no undo. And the lesson was always the same: the thing that kept those systems safe was never the smart part. It was a dumb, hard-coded, deterministic layer wrapped around the smart part, with the authority to say no.

The smart part proposes. The deterministic layer disposes. Every irreversible action is gated. You do not let the clever, probabilistic component hold the kill switch, because the whole reason you need a kill switch is that the clever component is the thing that goes wrong.

Agents are exactly this pattern wearing new clothes. The LLM is the strategy. The risk engine belongs in compiled, statically-typed code that the LLM cannot talk its way past.

What it looks like in practice

That conviction is why I've been building RiskKernel — an open-source, self-hosted runtime that puts that deterministic layer in front of an agent you already have. I'll keep this concrete rather than salesy, because the shape is the point and you could build a version of it yourself.

You point an existing agent at it with one environment variable:

OPENAI_BASE_URL=http://localhost:7070/v1

Now every call routes through a governor. You set a per-run budget — dollars, loop count, wall-clock seconds — and the moment the run crosses a ceiling, the next call is refused with an HTTP 402 instead of being forwarded. Enforced in Go, never by a model. Bring your own provider key; nothing leaves your machine except the call you were already making.

One detail I think is worth stealing regardless of what you use: a call that already reached the provider is never silently discarded. You paid for it, so it's returned to you — and it's the following call that gets refused. The ledger stays honest; the budget never double-counts the request that tipped it over. The brake engages on the next rotation of the loop, not by throwing away work you already paid for.

And because the failure mode I actually lose sleep over is a long, legitimate run dying halfway through, it checkpoints: you can kill -9 a run and resume it without re-spending or restarting from zero. That's the part that makes a long agent run safe to leave running, which is the whole game.

The honest part

The honest edges, today: single instance on SQLite, one API token, no streaming yet (the proxy returns a clean 501 for stream: true — mid-stream enforcement is genuinely hard and I'd rather ship it right than ship it loud); native providers are Anthropic and OpenAI, with the long tail via an upstream gateway. It's Apache-2.0, and it phones home to no one — the only outbound traffic is to your provider and the backends you point it at. I'd rather you know the edges than discover them.

It is also not trying to be your observability stack or your policy firewall. It emits OpenTelemetry to whatever you already run; it interoperates with the gateways and the dashboards. It competes on exactly one thing: deterministically stopping a run before it hurts you.

The takeaway

If you run agents, the question to ask isn't "will I find out when one goes runaway?" You will — eventually, in the logs, in the bill, in the post-mortem. The question is "what stops it before I find out?"

Logging is not that thing. Monitoring is not that thing. max_tokens is not that thing. A deterministic, pre-call, per-run limit with a kill switch is — and it's a few hours of work to put one in front of an agent you already have, whether you use what I built or roll your own.

Eleven days. Forty-seven thousand dollars. A dashboard that saw all of it. Don't be the dashboard.

RiskKernel is open-source (Apache-2.0) and self-hosted — pip install riskkernel or docker run. If you put it in front of an agent and the guardrails are too strict or too loose, I'd genuinely like to hear where — that feedback is what the next release is made of.