Designing agent loops is good advice, but a loop that runs forever is not a product. How to build agents that ship outcomes, not activity.
There is a popular piece of advice making the rounds among AI builders: stop prompting your coding agent and start designing the loop that prompts it. It is good advice as far as it goes. But a sharp essay by Dann Waneri adds the part everyone skips: a loop that runs forever, burning tokens and producing tidy logs, is not a product. Motion is not progress. This post unpacks why “the loop is not the product” and what it changes about how you should build agents.
The essay draws a distinction worth sitting with. Autonomy used to mean delegated judgment—you trusted someone to decide what mattered. What agents actually give you is delegated execution: they will do the thing, repeatedly, tirelessly, without ever asking whether the thing is worth doing. That gap is where budgets quietly disappear.
A loop that runs 30 times and produces nearly identical output looks productive on every dashboard. Tokens consumed, turns completed, tasks attempted—all up and to the right. None of those metrics answer the only question that matters: did anything actually get better for a real user? An agent can generate a beautiful audit trail of activity while moving the product exactly nowhere.
The economics have shifted under our feet. A simple model query in 2023 might have cost four cents. A multi-agent workflow in 2026 can run well over a dollar for the same conceptual task—a 30x jump—and the essay notes that a majority of enterprises report their AI costs blew past projections. The reason is structural, not a pricing accident.
Humans compound in value: what you learned last week makes you faster this week. Agents do the opposite. Most start fresh on every run, re-ingesting and re-deriving the same context, paying again for ground they have already covered. Each iteration re-reads previous work, and that context-reconstruction cost is largely invisible—expensive randomness hidden behind good logging. If you are not measuring it, it is still being spent.
The essay names three failure modes, and they map cleanly onto things you can fix in your own systems:
This is the trap most agent projects fall into. You build observability, you watch the graphs climb, and you mistake utilization for value. The essay’s line is worth taping to your monitor: a loop that produces identical output thirty times looks productive on every dashboard. If your instrumentation only tracks what the agent did and never what changed for the user, you have built a very expensive way to feel busy.
The fix is to instrument outcomes, not effort. Define the improvement you expect before the loop runs—a metric that moves only when real value is created—and measure against it. If you cannot name what “better” means in advance, the loop has no business running unattended.
One of the essay’s sharper observations is that the humble cron job already solved problems agent loops pretend are new. A cron job runs at 2am, does exactly what you said, and fails loudly or silently—but it has a defined task and a defined end. Agent loops often have neither. Borrowing that discipline is most of the battle: clear exit conditions, a defined notion of “done” before you start, and a hard stop when the work is complete.
This does not mean abandoning agents for shell scripts. It means giving your agent the same boundaries a cron job has by default. The flexibility of an LLM is only an asset when it is fenced by the predictability of good engineering.
The author practices what they preach. They built an SEO agent but refused to let it burn tokens autonomously into the void. Instead, the agent handles the tedious middle—the drafting, the gathering, the repetitive transformation—and the human handles judgment at the edges. As the essay puts it, “the loop runs. But it runs to me. Not into a void.”
That is the whole design philosophy in one sentence. The components that make it work are unglamorous and exactly what the AWS-bankruptcy crowd also needed: clear exit conditions, a defined “done,” human checkpoints with real decision authority, and cost governors at the infrastructure layer rather than in the prompt.
The essay points to an uncomfortable real-world signal. Spotify’s workforce shrank while revenue grew 19% year over year, with a filing attributing improved profitability to lower personnel costs. On a spreadsheet that looks like a triumph of automation. But it raises the question the dashboards never ask: which acts of human judgment quietly stopped happening, and what does that cost the product a year from now?
This is what the author calls product debt. When loops and automation replace not just labor but judgment, the bill does not come due immediately. It accumulates silently as small decisions go unmade, edge cases go unconsidered, and quality erodes in ways no activity metric captures. The danger of a loop that “works” is that it can hollow out the thinking behind a product while every chart still points up.
If there is one habit to take from all of this, it is to design the exit condition before you design the loop. Most agent projects start from the entry point—what triggers the loop, what prompt kicks it off—and treat stopping as an afterthought. Flip it. Decide what “done” looks like, what evidence proves the outcome was reached, and what hard limits force a halt even if “done” is never achieved.
Concretely: write the success metric and the kill condition first, in plain language, before a single agent runs. “This loop stops when X is true, or after N iterations, or when cost exceeds Y—whichever comes first.” A loop with three explicit exits is an engineered system. A loop with none is just a way to convert your budget into logs.
If activity metrics lie, what should you track instead? The shift is from counting what the agent did to verifying what changed downstream. Instead of “the SEO agent generated 40 meta descriptions,” measure whether the pages it touched actually moved in rankings or click-through. Instead of “the support agent resolved 200 tickets,” measure reopen rate and customer satisfaction on exactly those tickets. The output is only a proxy; the outcome is the product.
Good instrumentation also makes the invisible costs visible. Track tokens-per-unit-of-value, not just total tokens, so you can see when a loop is getting more expensive without getting more useful. Track how often the agent re-derives context it already had. When you can see cost climbing while improvement flatlines, you have found a loop running into the void—and you can kill it before it kills your budget.
A useful mental model: a capable agent is less like an autopilot and more like a fast, tireless intern. You would never give a new intern your company credit card and tell them to “go optimize the infrastructure, immediately, without checking in.” You would scope their work, review their plan, and let them own the repetitive execution while you keep the judgment calls. The same posture is exactly right for agents.
This framing resolves most design questions on its own. Should the loop run unattended forever? No intern works that way. Should it spend money without approval? Obviously not. Should it handle the tedious middle so you can focus on the edges? That is precisely what a good intern is for. Build agents like you would manage a talented junior teammate, and most of the failure modes in this article simply never get the chance to happen.
“Design better loops” is only half the advice. The other half is: point the loop at a real customer need and prove it moved the needle. The builders who win the agent era will not be the ones whose loops run the longest or burn the most tokens—they will be the ones whose loops actually ship something to someone who asked. Build the loop, by all means. Just make sure it runs to a destination, not in a circle.
For more practical perspectives on building with AI, browse the HelloBuilder resources.
Get the weekly digest for AI builders & vibe coders. Curated tools, resources, and stories. Skip the scroll.
