Harness engineering / 02
The loop
The loop is the part of the harness that decides: call the model again, use a tool, ask a human, or stop. Loop engineering is designing the exits before designing the steps.
What it is
Every agent is a loop: read state, assemble context, call the model, act on what comes back, decide what happens next. Frameworks give you the while-loop for free. What they do not give you is the decide part: budgets (turns, tokens, time, dollars), a success predicate (what, checkably, means done), stuck detection (how you know it is spinning), retry semantics (what is safe to do twice), and the handback (what a human receives when the loop gives up).
Why it exists now
The loop is where agents fail in public. The runaway session that burns a few hundred dollars overnight. The agent that calls the same tool with the same arguments forty times. The one that announces success without doing the thing, because "the model said done" was the exit condition. None of these are model failures. They are loops nobody designed.
And retry semantics are not an academic detail. In any system that touches money, a non-idempotent step inside a retrying loop is a double charge. The engineers who have run payments recognize this instantly: an agent loop is an at-least-once delivery system, and it needs the same discipline.
The 20-minute kata
- Take one agent you have built or operate. Write its loop contract on one page: budgets (max turns, max cost, max wall-clock), success predicate (the checkable condition that means done, not the model's claim), stuck detector (same tool with same arguments twice? no state change in N turns?), retry policy (which steps are idempotent, and what happens to the ones that are not), handback (the message a human gets: what was tried, where it stopped, what it needs).
- Enforce one item in code. The turn budget is usually five lines.
- Give it a task that cannot succeed. Watch it exit on purpose, within budget, with a useful handback.
An agent that fails cleanly on an impossible task is more production-ready than one that succeeds on a demo.
What good looks like
- Done is a predicate the harness checks, never a sentence the model produces.
- Budgets exist on turns and on cost, and hitting one is a designed exit with state attached, not an exception.
- Stuck detection catches repeat-action and no-progress loops before the budget does.
- Retries wrap only idempotent steps; everything with side effects is keyed or gated.
- The handback carries the trail: what it tried, what it observed, where it stopped. An apology is not a handback.
- The golden set includes at least one impossible task that must fail-and-halt cleanly. The exit path is tested like a feature, because it is one.
How it's tested
"Tell me about a time your agent ran away or got stuck. What did you change about the loop afterward?"
The red flag: max_iterations is whatever the framework defaulted to, and nobody has thought about it since. Bonus red flag: no answer to "what happens if that tool call runs twice?"