---
title: "Loop engineering is not prompt engineering with a timer"
canonical: https://maxtokens.ai/posts/loop-engineering-harness-loops/
date: 2026-06-30
tags: [agents, infra, llm, cost, routing]
description: "Loop engineering pays off only when a harness around the agent checks the result, caps cost, and decides when the work is actually done."
---
Loop engineering does not begin when an agent simply repeats a prompt. It begins when that repetition is surrounded by a control system: start the work, check the result, enforce limits, retry, and escalate when needed.
The core mistake is treating model confidence as evidence. A model can say "done." A harness has to check whether the work is actually done.
The useful part of the current loop engineering conversation is that it shifts attention away from the prompt and toward the system around the agent. A serious agent is not an improved prompt. A serious agent is a loop with a harness around it.
A loop by itself can burn money, repeat bad assumptions, and polish the wrong answer. A harness can say no.
## A loop is not a product
Loop engineering starts with a shift: the agent is no longer steered manually from the chat.
Instead, there is an external control layer around it. That layer gives the agent state, receives the result, checks it, and decides what happens next: continue, stop, retry, or escalate to a human.
Addy Osmani describes this as a move from prompt-by-prompt human steering to a system that runs the agent loop itself. That is the useful part of the idea: the prompt stops being the architecture. It becomes one component inside the loop.
Prompt engineering asked: "What should we write to the model?"
Context engineering asked: "What should the model see?"
Harness engineering asked: "What environment can the model safely act inside?"
Loop engineering asks a colder question: "What repeats, what is measured, and who is allowed to decide that the work is done?"
The basic agent loop is not new. Anthropic's documentation describes it as a cycle: the model requests tool use, the application performs the action, returns the result to the model, and the process repeats until the task is complete or an iteration limit is reached.
The new part is not the loop itself. The new part is the external control layer around it.
## Four words that should not be mixed together
I would separate four things.
**Loop** is the repeated agent cycle: the model receives state, acts, reads the result, and decides whether another step is needed.
**Harness** is the environment around the loop: tools, state, tests, permissions, limits, logs, stop rules, and escalation paths.
**Verifier** is the part of the harness that decides whether the work can be treated as done: a test, dry run, validator, evaluator model, business-rule check, or human review.
**Scheduler** is only the mechanism that starts the loop: a timer, event, webhook, cron job, or manual trigger.
Problems start when a scheduler is treated as a harness. Cron can wake an agent every hour. By itself, it does not know what success means, does not cap spend, does not detect drift, and does not decide when the task should go to a human.
Repeating a weak process on a schedule is not architecture. It is just more weak attempts.
## The harness decides when "done" means done
Loop engineering begins where the model stops checking its own work.
In code, the difference is obvious. A model can say a patch is correct. A test suite can exit with code 0. A model can claim that a migration is safe. A dry run can reject it.
The production rule is simple: an external signal says what happened, and the agent explains that result. The agent does not replace verification with its own self-assessment.
LangChain describes a verification loop as a separate layer: a grader checks the agent's output against a rubric, tests, or other rules, and sends feedback back into the loop when the result fails. In the docs-writer example, the checks include links, CI, and diff boundaries. LangChain also states the tradeoff clearly: verification increases latency and cost, but it is justified when quality matters more than speed.
Claude Code hooks solve a related problem from another direction. Hooks are shell commands that run at specific lifecycle points. They provide deterministic control instead of hoping that the LLM remembers to do the important thing.
The same shape applies outside software development. A sales-research agent should not decide that an account is qualified just because the generated note looks plausible. The harness should check required fields, source freshness, exclusion rules, and budget.
An analytics agent should not mark an analysis as done because the chart looks neat. The harness should check row counts, metric definitions, time windows, and whether the result actually answers the original question.
The model can explain. The harness should verify.
## /loop and /goal made the pattern visible
Anthropic did not move the conversation forward by inventing the loop. It moved the conversation forward by making the loop visible as a product feature.
In Claude Code, /goal defines a completion condition. Claude continues working across turns, and after each turn a smaller fast model checks whether the goal has been reached. If not, Claude starts another turn instead of returning control to the user. The documentation also distinguishes /goal, /loop, and a Stop hook: /goal starts the next turn after the previous one finishes, /loop runs on an interval, and a Stop hook can decide what to do through your own script or prompt.
That distinction matters.
/loop is repetition.
/goal is repetition with a completion condition.
A Stop hook is an external way to decide what should happen after a turn.
None of these features is an architecture by itself. But they make the old manual pattern visible. You no longer have to pretend that an agent must always finish the job in one response to one prompt.
A product feature is not a harness. It is a reason to build one.
## More iterations are not a strategy
The bad version of loop engineering is simple: keep the agent moving and hope that enough iterations eventually converge to a good result.
Sometimes this works. Loops are useful on tasks with clear checks: code porting, performance experiments, security scanning, regression hunting, data transformation. Armin Ronacher makes a similar point: loops are especially natural for mechanical transformations, experiments, and tasks where each iteration produces a useful signal for the next one.
But "make it better" is not a success criterion.
"Improve the landing page," "find more alpha," "clean up the report," and "make the strategy stronger" are all invitations to spend money unless the harness turns the goal into measurable gates.
Before I would let a loop run unattended, I would require at least:
- an iteration limit;
- a time limit;
- a cost limit;
- a scope where the agent is allowed to act;
- a verifiable success function;
- a failure condition that stops the loop;
- an escalation path;
- a log of decisions and results.
Remove any of these, and the loop has fewer reasons to stop.
A budget limit is not only financial hygiene. It defines product semantics. A $0.20 answer and a $200 answer are different products, even if the final text looks similar.
Good loop engineering makes failure cheap and visible.
## A minimal production loop
I would describe a minimal production loop not as a prompt, but as a contract:
- **Trigger:** what starts the loop.
- **Scope:** where the agent is allowed to act.
- **State:** what is preserved between iterations.
- **Tools:** which actions are allowed.
- **Verifier:** what counts as evidence.
- **Budget:** the limit on turns, time, and money.
- **Stop condition:** when the work is considered done.
- **Failure condition:** when the loop admits that it did not succeed.
- **Escalation:** who receives the task, and what context they receive.
- **Log:** where the trail of decisions remains.
This is a boring list. That is the point. An agent loop without this list is just a model that has been allowed to continue for longer.
## Harness changes should make a prediction
The most useful research anchor here is not another post about loop engineering. It is the paper on Agentic Harness Engineering.
In that paper, the harness is not changed by feel. It is changed through observability: harness components are represented as editable files, trajectories become an evidence corpus, and each change is shipped with a self-declared prediction that can be checked against the next set of outcomes.
That is the right discipline for loop engineering: a harness change should not be just a rationale. It should be a checkable contract.
For example:
This validator should reduce false success on failing tests.
This budget limit may increase escalations on long refactors.
This memory-retrieval step should improve repeated account research, but may introduce failures from stale sources.
This kind of note does not turn the system into a scientific laboratory. It just makes the next rollout readable.
Without predictions, teams tune loops by feel. They add a retry. Expand context. Swap the model. Give access to a new tool. The last demo run worked, so the change feels right. Then another task regresses. Nobody knows whether the loop improved or the error moved somewhere less visible.
AHE is interesting because it looks for gains beyond the system prompt. In the arXiv version of the paper, ten AHE iterations raise pass@1 on Terminal-Bench 2 from 69.7% to 77.0%, and the ablations localize the gains in tools, middleware, and long-term memory. The prompt-only change regresses.
That is an important hint: the problem is often not that the model "misunderstood the instruction." The problem is often the harness: tools, memory, middleware, checks, limits, and state.
But AHE should not be read as proof that self-improving harnesses are solved. The authors themselves describe the setting as high-variance, limit the claim to the benchmark environment, and warn that the gains do not automatically prove broad generalization across other coding-agent environments, languages, and deployment settings.
The useful conclusion is more modest: prediction, rollout, verification, and rollback are good harness discipline even if you never let an agent evolve the harness automatically.
## Loops hide causality
Loop engineering needs that discipline because loops hide causality.
A single answer has one visible failure point. A loop has a prompt, context, model, tools, memory, state, scripts, retry policy, stop condition, verifier, and escalation path.
When the result improves, any of those elements could be the reason. When the result breaks, any of them could be the culprit.
That is why the harness log becomes the place where you can see why the agent system changed.
Not "we improved the prompt," but "we added check X because it should fix failure mode Y, and we expect side effect Z."
Not "we gave it more context," but "we added source A to the retrieval hierarchy because it should reduce false clarifications on tasks B, but may increase cost on routes C."
Not "we increased the budget," but "we raised the limit to 12 turns for the migration route because p90 successful tasks finish by turn 10, and after turn 14 the success rate falls."
This is where loop engineering stops being a nice label and becomes ordinary engineering.
## The useful version is deliberately boring
The useful version of loop engineering is less glossy than the term.
It looks like shell scripts, test suites, budget counters, task queues, status files, rollback notes, and a rule that the model does not grade its own homework.
That does not make the approach less valuable. That is the approach.
The agent systems I would trust in 2026 are not infinite thinkers. They are constrained executors inside explicit loops.
The internal agent proposes and acts. The external harness observes and judges. The verifier decides whether there is enough evidence. The budget shows when ambition has turned into waste. Escalation admits where automation has reached its edge.
Loop engineering deserves attention only when it sharpens that boundary.
Otherwise, the new label is just prompt engineering with a timer.