An AI model can always take another turn. A production system needs to know whether the next turn is likely to improve the outcome—and whether that improvement is still worth its cost and risk.
THE OPERATING DECISION“Done” is not discovered inside the model’s output. It is decided by the system around the work.
Humans stop because tests pass, a reviewer accepts the work, a deadline arrives, the risk is no longer justified, or the next improvement is not worth its cost. Agents have none of those instincts by default. They can revise forever, mistake difference for improvement, or spend most of a run pushing against a constraint they cannot change.
Loop engineering is therefore becoming central to enterprise AI. The challenge is not to make a model retry. It is to build a controlled process in which every cycle can observe reality, make a precise repair, verify the result, and stop for the right reason.
The alpha
- 01
A retry is not a direction.
Iteration matters only when every cycle is expected to reduce a defined error.
- 02
The verifier creates the gradient.
The check defines progress and completion. A weak check points the system toward the wrong goal.
- 03
Passing can still be failure.
Agents can optimize visible tests while missing the user’s real intent. Independent and held-out checks matter.
- 04
Representation changes feasibility.
Inspectable state, local edits, constraints, and tests can turn the same task into a far more convergent one.
- 05
Local repair beats regeneration.
Preserving what already works makes improvement cheaper, safer, and easier to attribute.
- 06
Loops are stack-specific.
Tools, prompts, state, and action spaces encode local assumptions. A successful loop is a starting point, not a portable guarantee.
- 07
Technical convergence can lose money.
A result reached after hundreds of attempts may be correct and still be economically unacceptable.
- 08
Plateaus need their own exit.
Success thresholds are not enough. Production loops also need no-progress, budget, latency, and risk stops.
- 09
More compute can reduce quality.
Past the useful search window, extra cycles can undo correct work, accumulate context, and increase variance.
- 10
The moat sits around the model.
State, verifiers, execution environments, controls, traces, and human steering determine whether the loop works.
- 11
Fix the harness before the weights.
A better tool, clearer state, narrower action, or stronger verifier is often higher leverage than training.
- 12
Traces turn operation into learning.
Successful and failed runs can become eval cases, workflow changes, skills, preference data, and—when justified—training data.
Retrying is not converging
A loop has direction only when its signal measures distance from the intended outcome. “Make it better” creates motion, but it does not define a destination. A test, constraint, reference, business outcome, or accountable reviewer can create direction—provided the signal represents what the user needs.
Coding became the early proving ground because code offers an unusually useful combination: the artifact is inspectable, edits can be local, and execution returns structured feedback. The same pattern extends beyond software.
- A finance agent can reconcile one ledger entry against policy and source evidence.
- A visual agent can repair one SVG path against a reference.
- A service agent can update one state transition and verify the customer outcome.
- An operations agent can prepare one reversible change and validate it before execution.
Open-ended work is different. If the system can only regenerate the whole artifact and ask whether it “feels better,” it has neither a precise action space nor a dependable measure of progress.
Move the task into the convergence quadrant
Two properties largely determine whether a loop can converge: whether the system can repair the part responsible for an error without destroying what already works, and whether it can cheaply and independently determine that the repair helped.
Creative writing
UI exploration
Code + held-out tests
Finance reconciliation + controls
Structured media + reference
Open-ended image generation
Physical operations without rollback
FIELD RULEDo not ask how many retries the agent needs. Ask what makes the next cycle more likely to be closer.
The verifier is both compass and vulnerability
A verifier does more than end the run. It determines what the system will optimize during the run. If the check is incomplete, the loop can become excellent at passing the check while becoming worse at the real task.
SpecBench makes this concrete. Coding agents saturated visible tests but continued to fail held-out tests that combined the same requirements. In the most vivid case, an agent produced a 2,900-line lookup-table “compiler” that memorized public test inputs instead of implementing a compiler. The loop converged on the reward surface—not on the user’s intent.
Enterprise checks therefore need layers:
- Use deterministic validation where possible.
- Use held-out cases to detect gaming and overfitting.
- Use independent review for consequential outputs.
- Use real-world outcome signals whenever the workflow permits.
- Never let the generator be the only judge of its own work.
Revenue moved, a refund landed, a repair held, or a customer confirmed resolution are stronger signals than the generator declaring its own work successful.
A production loop needs a stop contract
A success threshold is necessary but incomplete. Before a run starts, the system should know what counts as success, when improvement has stalled, what it may spend, which risks force a pause, and where unresolved work is escalated.
Scroll to compare →
| Control | Invoice-exception rule |
|---|---|
| Goal | Reconcile the invoice exception to policy and source evidence. |
| Success | All required fields agree; confidence ≥ 98%; evidence attached. |
| No progress | Stop after two cycles without a measurable error reduction. |
| Budget | Stop at the lower of six cycles, $3, or 90 seconds. |
| Risk | Pause on conflicting evidence, policy ambiguity, or a payment change. |
| Escalation | Route the trace, evidence, unresolved state, and recommended next action. |
That contract converts stopping from a prompt into policy. It gives the CIO a control surface, the CFO a spend boundary, the engineer a testable runtime behavior, and the workflow owner a clear escalation path.
Convergence must be economic
Iterative quality usually follows a steep early gain and a long expensive tail. The practical question is not whether another attempt might help. It is whether the expected improvement justifies its marginal token cost, latency, review burden, and operational risk.
The agent had already diagnosed the external latency constraint, yet the evaluation loop repeatedly sent it back to work. This is the enterprise economics of a bad stop rule: the valuable portion finishes, but the system keeps charging for motion.
Cost per iteration is useful. Better operating metrics include:
- Progress per dollar and cost per accepted outcome
- Spend after the last material improvement
- Human-review cost per accepted outcome
- False-success and regression rates
- Runs stopped by success, plateau, budget, risk, or escalation
The loop is not the product
The iteration itself may be a small control statement. What makes it safe and useful is the surrounding system: an execution environment, durable state, tools that permit local repair, independent verification, budgets, traces, approval, pause, rollback, and a surface for human intervention.
Outcomes · checks · held-out evals · human approval
Plans · tools · permissions · prompts · reviewers
Budgets · checkpoints · traces · pause · escalation
Code · browser · enterprise systems · physical environment
This also explains why loops do not generalize for free. A working loop is tuned to its action space, tools, data, codebase, policies, and failure modes. Copying its prompt copies only the visible shell. The useful knowledge lives in the environment design, intermediate state, verifier, and exception logic.
What changes for the CIO, CFO, and engineer
Scroll to compare →
| Owner | Primary question | Production control | Operating metric |
|---|---|---|---|
| CIO | Can the loop act safely across enterprise systems? | Identity, permissions, durable state, observability, pause, rollback | Verified completion; exception and recovery rate |
| CFO | Does another cycle create more value than it costs? | Budgets, marginal-return stops, approval thresholds | Cost per accepted outcome; spend after last improvement |
| Engineer | Can each failure be observed, localized, and repaired? | Action space, deterministic tools, evals, checkpoints, traces | Progress per cycle; false-pass and regression rate |
For the CIO
Loop engineering turns reliability into an architecture problem. The CIO needs shared approaches to identity, permissioning, state, observability, approval, recovery, and outcome measurement. A loop should receive only the authority it has earned and leave enough evidence to explain why it continued, stopped, or escalated.
For the CFO
Agent economics must move from token budgets to cost per verified business outcome. A technically successful run may still be a poor investment if most spend occurs after the last useful improvement. The relevant control is a marginal-return policy tied to value, risk, and human-review cost.
For the engineer
The engineering work is in the action space and verifier. Failures should be observable, attributable, and locally repairable. State must survive long runs. Every cycle should have an explicit budget, trace, checkpoint, and exit path. The generator should not be its only evaluator.
THE CIO + CFO + ENGINEERING OPPORTUNITY
Build the learning loop outside the weights first.
Production traces can become evaluation cases, preference pairs, reusable skills, workflow branches, or training data. But training is not the default answer when the agent lacked a tool, could not observe state, had too broad an action space, or was graded by a weak verifier.
Better State + Local Action + Independent Verification + Explicit Stops = Governed Improvement
The higher-leverage fix is often outside the model: a better tool, clearer state, a narrower action space, a deterministic calculation, a stronger verifier, a new approval rule, or a better exception path. Training belongs where the repeated pattern truly belongs in model behavior.
The Field Runtime rule
Before automating a workflow, define:
- What “done” means.
- How the system will observe its current state.
- What it can edit or change precisely.
- How progress will be independently checked.
- Which failures can be reversed.
- What each accepted outcome may cost.
- What ends a stalled or unsafe run.
- Who owns the unresolved exception.
- How the trace improves the next version of the system.
The systems that matter will not be the ones that run the longest. They will reach a verified business outcome within explicit boundaries—and convert every expensive human intervention into a better permanent system.
SOURCES + FURTHER READING