# Agent Loops Don't Have a Token Problem. They Have a Feedback Problem. > Source: > Published: 2026-09-16 18:17:33+00:00 *Read this article on [Signadot](https://www.signadot.com/blog/agent-loops-feedback-problem/?utm_source=devto&utm_medium=blog&utm_campaign=blog+repost).* **Loop-based development means agents run longer, in parallel, and without anyone watching each attempt. What that costs is decided by the verification surface under the agent, not the token price.** The slogan making the rounds in AI coding is “write loops, not prompts.” In loop-based development, the agent doesn’t wait for a person between attempts. A small program hands it a goal, runs whatever it produces against a set of checks, feeds the failures back, and repeats until the checks pass or a limit stops it. The loop runs for as long as it takes, many loops run at once, and nobody reads the intermediate attempts. That’s the point of the pattern, and it’s what makes it faster than a person steering an agent turn by turn. It’s also exactly the shape of a spend problem. The past year has already brought the first retrenchment on agent token spend: flat-rate seats giving way to metered pricing, usage caps on agent products, engineering leaders asked to explain what a merged PR actually costs. Those bills came from interactive sessions, where a person was in the room and could close the laptop. A loop removes that person by design. Whatever an agent can spend in an hour with someone watching, a loop can spend all night, across a dozen parallel runs, with no one watching at all. Two loops running identical code against the same repo can still produce very different bills. What separates them isn’t the loop. It’s what the loop can observe about the system it’s changing. For teams running distributed services on Kubernetes, that gap is the entire cost structure, and most of it is decided before the loop ever runs. Each step in agentic development has moved the human one step further from the per-attempt decision. Prompt-driven work kept the developer inside every iteration, reading output and typing corrections, so spend was capped by one person’s attention and patience. Spec-driven work, the wave that Spec Kit, Kiro, and OpenSpec belong to, moved the developer’s investment up front into specifications and repo conventions, and the human came back to review finished tasks. Loop-driven work makes the loop itself the artifact the developer writes. They no longer write the code, and increasingly, they no longer write the individual task. They write the thing that generates work, checks it, and retries. The three properties that make a loop worth writing are the same three that make it expensive. It’s unattended, so a loop that’s thrashing on the wrong fix has nobody to notice. It’s long-running, so the spend clock doesn’t stop on its own. It’s parallel, so whatever one loop costs, you’re paying for many at once. None of that is an argument against loops. It’s an argument that the engineering has moved out of the prompt and into the wrapper: which checks the loop runs, what it gets back when one fails, and the condition under which it stops. The easy assumption is that cheap generation settles the cost question. It doesn’t. Generation is fast and cheaper per unit than developer hours, but tokens are a real and growing line item, and a loop is an agent left running on purpose. Budgets that survived interactive sessions don’t survive loops by default. The first response most teams reach for is guardrails: iteration caps, no-progress detection, spend ceilings. Those are necessary, and they aren’t sufficient. A cap bounds how much a wasteful loop can waste. It does nothing to make the loop less wasteful. What actually sets the bill is two numbers multiplied together: how many iterations a loop needs before it reaches a verified result, and what each of those iterations costs. Because they multiply, halving both doesn’t halve the bill, it quarters it. And a floor under either term is a floor under the total that no guardrail can lift. *Total loop cost is the product, not the sum. Pulling high-fidelity feedback into the inner loop shrinks both terms at once.* A loop that receives a bare failure signal has to guess at the cause. It changes something plausible and runs again, and the next bare failure says almost nothing about whether the guess was close. A loop that receives the actual error, produced by the actual system, with enough context to localize the fault, fixes the real problem and moves on. Feedback quality also caps how good the finished change can be, which matters more than the iteration count does. [A loop can only fix what its feedback can see](https://www.signadot.com/blog/coding-agents-are-only-as-good-as-the-signals-you-feed-them/). Give it unit tests and mocks, and it will stop when the unit tests and mocks pass, which is a different thing from a working change. Token price and context size are part of what an iteration costs, and they’re the loop author’s to tune. The part the platform decides is how long each iteration waits for an answer and what the environment behind it costs. Close the loop in CI, after the code has already left the agent’s session, and every cycle buys a pipeline run plus a place in someone else’s queue. Cadence lands in minutes to hours. Close it inside the session, against a runtime the agent can call directly, and cadence lands in seconds. The two terms aren’t independent, either. Pushing high-fidelity feedback out to CI doesn’t just make each cycle expensive, it leaves the agent iterating on partial signals in between, which inflates the iteration count too. Pulling high-fidelity feedback into the inner loop compresses both terms at once. It’s the only move available that does. Total loop cost is the number of iterations multiplied by the cost of each one. Guardrails cap the damage. Only better feedback, reachable faster, changes the product. For a self-contained program, both numbers come close to free. The test suite runs on a laptop in seconds, and what it reports is the complete answer, because the complete system is on the laptop. It’s also why the most convincing loop demos tend to be single-repo projects. A microservice change can’t be judged that way. Whether it’s correct depends on what its callees return, how the queues and data stores it writes to behave, and what the routing and policy layers in front of it do to its traffic. The feedback an agent can reach in seconds, local tests and mocks, is low fidelity: it covers only the code inside the service boundary. [Integration tests pass while staging breaks](https://www.signadot.com/articles/integration-tests-pass-but-staging-breaks/) for precisely this reason. The feedback that would have caught it has production fidelity, and it has traditionally lived in CI and on [shared staging, where every run waits behind someone else’s](https://www.signadot.com/deep-dives/why-shared-staging-is-expensive/). So the two options cloud-native teams have had trade directly against each other: fast and low fidelity, or high fidelity and slow. A loop pays for both terms, so neither end of that tradeoff is good enough. The conventional environment options [run out of room at agent concurrency](https://www.signadot.com/blog/closing-the-loop-coding-agents-cloud-native/) for structural reasons, not tuning. What the loop needs is the option that doesn’t trade: an environment with production fidelity that the loop can reach from inside the session. *Local tests and CI trade fidelity for speed or speed for fidelity. A production-fidelity environment the loop can reach from inside the session is the option that doesn't trade.* Whether a loop finishes with a change that actually works, and what it costs to get there, are decided by four things the platform team builds. The loop passes through all four on every iteration. *Every iteration passes through the four layers. The runtime sets how long each one takes, the feedback sets how many it takes, the definition of done says when to stop, and the controls cap the total.* Every iteration needs an environment that behaves like production without costing like production. [Lightweight ephemeral environments](https://www.signadot.com/guide-to-ephemeral-environments-kubernetes/) on a shared cluster get there: deploy only the services the change touches, then use request routing to steer the loop’s traffic through those services and through a stable shared deployment of everything else. Environments come up in seconds, and marginal cost tracks the pods you changed rather than the full stack. This is the platform team’s lever on cost per iteration, and it’s where the fidelity comes from. Agents don’t click through dashboards, and they shouldn’t be inventing their own passing criteria. The checks a change must satisfy belong in [declarative validation workflows](https://www.signadot.com/blog/introducing-plans-microservices-validation-superpowers-for-coding-agents/) that platform teams write, version, and hand to agents as the sanctioned way to prove a change. The organization decides what passing means, and reviewers get a record of which checks ran rather than the agent’s word that it finished. This is what tells the loop when it’s allowed to stop. This is the lever on iteration count. A simple pass or fail tells a loop to try again without telling it what to change. The runtime should return structured results: which check failed, logs and traces scoped to the requests this loop itself issued, and the behavior change at the boundary that broke. Every increment of precision removes a guess, and every guess removed is spend that never happens. Budgets, iteration ceilings, stall detection, and a durable record of every check a loop ran and every result it got. These don’t shrink either term. They put a hard ceiling on the product, which is what lets you run hundreds of loops and put a number in a plan instead of supervising one loop nervously. The role split follows from the cost structure. Application developers decide what to build and state the goal in a form a loop can check itself against. Platform engineers own everything the loop passes through: which checks run, where they run, what a loop is allowed to spend, and what evidence gets attached to the output. Those have to hold across every loop in the organization rather than being reinvented inside each one. Platform teams have run this play before. CI/CD went from something every team wired up itself to a shared system with an owner and a contract. The verification layer for loops is the same transition with one new requirement: it has to work during authoring, before a PR exists, at whatever concurrency the loops generate. Start with the runtime, because the other three stand on it. Validation workflows inherit the fidelity of wherever they execute, and feedback inherits the accuracy of whatever produced it. That layer is what we build at Signadot: a [Kubernetes-native validation platform](https://www.signadot.com/product/platform/) with lightweight ephemeral environments and governed validation workflows, so agent loops can prove changes against the live system in seconds. The [docs](https://www.signadot.com/docs/overview) walk through how the pieces fit together. If your agents already produce changes faster than your team can verify them, the size of your next bill was decided by the feedback surface, not the token price.