A tweet landed on my timeline this week:
"Loop engineering is a psyop. Get everyone building multi-agent workflows that loop indefinitely, burn tokens at 10x the normal rate, post record usage numbers right before IPO season."
It's a good tweet. Funny, cynical, shareable. And completely wrong about where the blame lands.
The companies aren't conspiring to burn your tokens. You burned them yourself. When you shipped without a definition of done.
Here's what's actually happening.
Every infinite agent loop is a while loop where someone forgot to write the exit condition. That's not an architecture problem. That's a requirements problem. It has always been a requirements problem.
while True:
result = agent.run(task)
# done when...?
That question mark is where the money goes. Not into the loop. Into the blank where the engineer was supposed to write the exit condition and didn't.
I've seen this pattern before AI was anywhere near a production system. Developers shipping vague scope, running into edge cases nobody defined, patching indefinitely. The difference is that before agents, the meter wasn't running. You burned salary hours. Now you burn tokens. The invoice arrives faster. The reckoning arrives louder.
AI didn't create lazy requirements. It just made the consequences cost-per-token.
Token burn isn't a side effect of bad architecture. It's what happens when you skip the hard part of defining when done actually means done.
Loops don't eat tokens because they're greedy. They eat tokens because the engineer never drew a boundary.
Think about what an orchestrator agent actually does when it hits ambiguity. It doesn't stop. Stopping would require knowing what done looks like. Instead it retries. Reformats the tool call. Spins up the verification agent. The verification agent finds something. The correction agent corrects it. The orchestrator checks the correction. Nobody defined what "correct" means.
Gartner's number — 5 to 30x more tokens per task in agentic workflows versus the chatbot pilots that justified the budget — isn't surprising once you understand the mechanism. The pilot had a defined task. The agent has a vague one. The difference is the blank where the exit condition was supposed to be.
I built spec-writer specifically because of this problem.
Before I write a single line of code — before I open Claude Code, before I wire up a cron job, before I think about which model to call — I run spec-writer. It takes a vague feature description and forces it into a structured spec: what does this do, what does it not do, what does done look like in one sentence.
That last question is the whole game. If you cannot answer "what does done look like?" in one sentence before you start, the loop will answer it for you. Expensively. Incorrectly. Indefinitely.
The spec isn't bureaucracy. It's the exit condition written before you open the terminal.
When I built seo-agent, I could have left it running 24/7. I didn't. Not because of the money. Because I couldn't answer the basic question: what would it actually be doing between runs?
SEO audits have a natural cadence. You crawl, you surface what's broken, you fix it, you wait for Google to reindex. Running the agent continuously doesn't change that cadence. It just burns tokens between the moments that matter.
So I wired a cron job. It runs on schedule. It surfaces what's broken. Then it stops. The output lands in front of me. I decide what matters. I go into the codebase with Claude Code and write the fix and the test.
The agent handles the tedious middle. I handle the judgment at the edges.
That's not old fashioned. That's the only architecture where the loop actually closes. Because "done" was defined before the first token fired.
The psyop framing is tempting because it gives you someone to blame. The companies. The VCs. The IPO calendar. Easier than sitting with the uncomfortable version:
Most people deploying agents cannot answer "what does done look like?" in one sentence. Not because they're bad engineers. Because nobody forced them to write it down before they started.
The spec is the forcing function. The exit condition is the discipline. The cron job is the honest architecture that admits the loop should stop.
"Fully autonomous 24/7 AI agent" is not the flex. Toward what? Optimizing toward what? You built a thing that spins and you're proud it never stops spinning.
Define what done looks like before you start. That is literally the job. That has always been the job. No amount of multi-agent hype changes the fact that you skipped the requirement and made the token meter pay for it.
Vague exit conditions aren't architecture. That's a missing requirement with a UI on top.
The loop is not the product. The exit condition is.
Top comments (0)