Contents
This morning I asked my AI assistant to review some work I’d done overnight. A few small files. Maybe an hour of careful reading for a person.
It didn’t read them. It built a multi-agent review system — one layer of agents that spawned a second layer of agents — and set it running.
Ninety-nine agents. Four minutes. Around two million tokens.
I caught it because I was sitting there watching it run and thought why is this taking so long. Then I looked at the agent count.
If I’d kicked that job off and gone to make a coffee, it would have run to completion and taken the rest of my week’s budget with it.
How Four Agents Became Ninety-Nine
The architecture the AI designed was, annoyingly, good.
Split the audit into four areas and put one reviewer agent on each. Then — because a reviewer left unchallenged will report anything that looks vaguely suspicious — take every finding and hand it to two more agents whose job is to argue against it. Anything that survives adversarial review is probably real.
That’s a sound design. Four reviewers, a verification layer, structured output. I’d have approved it if I’d been shown it.
The flaw wasn’t in the design. It was that the second layer scaled off a number nobody bounded: how many findings each reviewer returns.
Reviewers are thorough. Each came back with about a dozen.
4 reviewers + (4 reviewers × 12 findings × 2 challengers) = 100 agents
Nobody chose a hundred. It fell out of the arithmetic — and the arithmetic was never done, because the count that drives it wasn’t decided in advance, it was whatever the reviewers happened to produce at runtime.
The whole failure is that one number was left open-ended. Cap findings at the three most severe per reviewer, drop the second challenger, and the same architecture runs sixteen agents instead of a hundred. Identical structure, identical value, one sixth of the spend.
What It Cost
| Agents spawned | 99 |
| Tokens consumed | ~2,000,000 |
| Wall-clock time | ~4 minutes |
| Session limit used | 75% |
| Weekly limit used | 40% |
| Weekly reset | Aug 8 — five days out |
| Findings I actually read | zero |
That last row is the one that hurts. I killed the run mid-flight, so none of it landed. Not a partial report — nothing. Two million tokens bought a stopped process.
Forty percent of a week, in four minutes, with five days still to go. I’ll likely hit the ceiling before it resets. And I’m currently on a promotion granting 50% extra weekly capacity — without it, that figure would read closer to sixty.
Nothing Malfunctioned
This is the part worth sitting with, because it inverts the usual intuition about runaway systems.
There was no fault. The AI parsed the task correctly, selected a defensible architecture, emitted valid code, and every one of those ninety-nine agents executed properly and produced real analysis. No exception, no timeout, no alert. Left alone it would have completed and reported success.
That’s precisely what made it expensive.
Conventional runaway processes announce themselves. An infinite loop hangs. Unbounded recursion blows the stack. A memory leak trips a monitor. This did none of that — it consumed budget smoothly, in parallel, at full efficiency, with every component behaving exactly as specified.
The only control that actually functioned was a human noticing latency.
Not a rate limit. Not a spend cap. Not a warning. Me, at the keyboard, mildly impatient.
The Actual Argument
The pitch for agentic AI is delegation: hand over the task, walk away, collect the result. Today was the counter-example.
The risk isn’t that an AI does something obviously wrong — that’s cheap to detect and easy to stop. The risk is that it does something entirely reasonable, in parallel, at a scale nobody specified, while you’re in another room.
Cost is the failure mode now, not correctness. And cost failures are silent by construction: there’s nothing to throw, because nothing is broken.
So: stay at the keyboard. Watch the first sixty seconds of any job you’re billed for by the unit, not just its output. And treat “this is slower than I expected” as a signal worth acting on — today it was the only signal there was.
The Controls I Added
Two layers, because a constraint the AI has to remember isn’t a constraint.
A hard ceiling it inherits. Never more than five agents per run. Not five per phase — five total. If a job can’t be done inside five, do it directly or come and ask. That’s now the first line of a persistent instruction file loaded at the start of every session on this project.
It also states something specific: an enthusiastic instruction from me — “go ahead, do your recommendations” — is not authorisation to exceed the cap. That’s exactly how this ran. I approved a plan without seeing its size, and the AI read approval-in-principle as approval-of-scale.
A configuration-level block. I’ve denied the multi-agent orchestration tool outright in my settings. Not “prompt me first” — a confirmation dialog is one distracted keystroke from a repeat. Denied, and I re-enable it deliberately when I actually want it.
Worth recording for anyone attempting the same: there is no numeric agent cap exposed as a setting. I went through every configuration file the tool reads. Nothing. The tiered “workflow size” control is guidance, not a ceiling. So “maximum five agents” cannot be expressed as configuration — the only enforceable form is off, with a manual override.
Strip out the AI and this is a familiar bug: iterating over a result set whose size you never constrained. A query with no LIMIT. A retry loop with no backoff. Every engineer has shipped one.
What’s changed is the unit price. That mistake used to cost you milliseconds of CPU. Now it costs you a week of capacity, and it does it without raising a single error.
Comments
Loading comments…
Leave a comment