2026-08-04
The Budget Is Part of the Harness
An agent with unlimited retries does not have more autonomy. It has permission to hide a broken process behind more activity.
Spend is a system signal
Most teams treat an agent budget as a finance setting. They choose a monthly ceiling, watch a dashboard, and negotiate a larger number when the limit becomes inconvenient. That is cost control after the operating decision has already been made. It says how much loss the company will tolerate, not what the machine should do when work stops converging.
In an agent-run factory, spend is evidence. A task that consumes attempt after attempt is telling you something: the destination is unclear, the context is missing, the proof is rejecting the same mistake, or the agent is exploring a space too large for the value at stake. More tokens can occasionally finish the job. They can also bury the diagnosis under a successful-looking final attempt.
The budget therefore belongs beside permissions, tests, and release gates. It is one of the controls that defines acceptable behavior. A factory should know not only what an agent may touch, but how much uncertainty it may purchase before the work changes route.
Budget the attempt, not just the month
A monthly cap is too far from the decision. By the time it bites, dozens of unrelated tasks have competed for the same pool and nobody can tell which one deserved another run. The useful boundary sits around a unit of work: this request, this verification cycle, this recovery path.
Give each route an explicit allowance based on consequence and expected value. A routine dependency update should not be able to consume the same search space as a difficult production repair. A low-risk copy change should not trigger an endless argument between builders and reviewers. When the allowance is exhausted, the system should stop, preserve the evidence, and say why it could not proceed.
Stopping is not failure. Unbounded activity is failure with a larger invoice. A clean stop turns uncertainty into an object a person can judge. It shows the attempts, the rejected evidence, the unresolved decision, and the exact boundary that held. That is far more useful than a late summary claiming the agent tried very hard.
A retry must buy new information
Factories often waste money by repeating the same attempt with a longer prompt. The builder fails a check, receives the failure text, makes a plausible adjustment, and returns to the same check. If nothing about the evidence, context, tool access, or plan changed, the next run is not a new strategy. It is another spin of the same wheel.
Require every retry to state what changed. Maybe the system narrowed the failing case. Maybe it retrieved a missing contract, switched to a smaller plan, or asked an independent agent to challenge an assumption. Those are purchases of information. Rephrasing the request and hoping for different behavior is not.
This rule makes loops visible. If a task cannot name the new information behind its next attempt, route it out of the loop. Escalate the missing decision to a person, split the work, or reject it. The point is not to ration intelligence. The point is to refuse motion that cannot explain how it gets closer to acceptance.
Proof needs its own budget
Teams under cost pressure usually protect generation and squeeze verification. That is backwards. Cheap output with weak proof is not a bargain; it is an inventory of unknown liabilities. If the builder can spend freely while the verifier gets one shallow pass, the budget has already decided that producing work matters more than knowing whether it holds.
Reserve capacity for independent proof before building begins. The verifier needs enough room to reproduce the result outside the builder's chosen conditions, exercise awkward edges, and explain a rejection precisely. The builder must not be allowed to consume that reserve by overrunning its own allowance.
This separation also improves the accounting. You can see whether cost accumulates in construction, recovery, or acceptance. A factory that builds cheaply but repeatedly fails expensive verification has a planning or specification problem. One that builds and verifies cleanly but burns money on release recovery has a different problem. A single monthly total hides both.
Make every overrun change the factory
The first overrun is a surprise. The second is a choice. When a task crosses its boundary, the factory should retain the reason and change what happens next time. Add the missing context to the repository interface. Turn the repeated rejection into a deterministic check. Split a request shape that consistently arrives too large. Move a consequence decision to the human gate where it belongs.
This is where agent-run delivery compounds. People forget why a task was painful, especially after somebody finally forces it through. Machinery can keep the lesson. The next agent receives a smaller search space, a sharper contract, and an earlier stop condition. Cost falls because the system got better, not because a procurement team demanded cheaper guesses.
Our position is blunt: organizations will not win autonomous delivery by purchasing the largest pool of inference. They will win by turning spend into governed attempts, independent proof, and durable learning. The model supplies capability. The budget tells the factory when capability is producing evidence—and when it is merely producing heat.