Building a Better Inner Loop — Bradley Gibbs

Once you stop prompting a coding agent after every step and switch to loop engineering, the work you were doing doesn’t disappear. Context, tool selection, environmental feedback, evaluation, retry, and stopping all have to move somewhere. Loop engineering is therefore a functional-allocation problem: which jobs belong to the model, which to deterministic software, and which must remain human. Better models expand the choices; they do not determine the architecture.

What follows are the general principles and architecture we’ve developed after ten months of testing and building looping pipelines for reliable, unattended code generation: how and where to add safeguards to catch common AI failure modes while they’re still cheap to correct, and how to build a Learning Loop that performs postmortems on all runs (both failed and successful) to detect new failure modes, design and propose safeguards against them, and make sure existing safeguards continue to earn their time and tokens. We close by picking apart “the model eats the harness” and providing some guidance to help you decide whether your model should eat a piece of your harness just because it can.

Systems-engineering concepts & other defined terms

Below is a glossary of systems-engineering and other terms to ensure we are using the same conceptual framework throughout this article:

Capability: an outcome that the system as a whole can produce.

Function: work that must be performed to produce that capability.

Functional allocation: assigning each function to a system element (NASA calls the human–machine division of this problem “human/systems function allocation”).

Responsibility: which element is expected to perform the allocated function.

Authority: what actions or decisions that element is permitted to take.

Configured system (the agent): the actual models, harnesses, tools, and deterministic components arranged to perform the work—the unit this article analyzes.

Operating envelope: the tasks, tools, permissions, and conditions within which a qualification or safeguard has been shown to hold.

Qualification: demonstrating—against known-good, known-bad, and bypass cases—that a check or evaluator can discriminate the condition it is trusted to decide, within a stated operating envelope.

Requalification: establishing that the reconfigured system still satisfies its requirements.

Authority separation: keeping evaluation, admission, and acceptance outside the producer’s control. Distinct from error independence, which must be separately earned.

From outside a system we see the system’s capabilities and externally required properties. Inside, we see functions allocated among components. Several components may be capable of performing the same function. That does not mean all should perform it. The allocation must be explicit; responsibility must be supported by appropriate authority; and some authority deliberately remains separated from the producer.

From prompts to loops

Prompt engineering and loop engineering can satisfy the same required capability envelope: pursue authorized coding work through feedback and return a result, an escalation, or an honest stop. The difference is inside the system boundary. With prompt engineering, the developer performs or coordinates nearly every required function. Loop engineering reallocates the ordinary running of that work to the model and harness, leaving authorization, genuine exception resolution, and acceptance with the human.<br>That reallocation can do more than preserve attention. It allows the inner loop to carry feedback across steps without requiring the developer to initiate every transition, making persistent, repeatable, parallel, and unattended pursuit of outcomes possible.

REQUIRED CAPABILITY ENVELOPE — THE INVARIANT<br>pursue authorized coding work through feedback; return a result, an escalation, or an honest stop

PROMPT ENGINEERING<br>LOOP ENGINEERING

HUMAN-ORCHESTRATED SYSTEM<br>DEVELOPER PERFORMS OR COORDINATES<br>with the model and tools

define the goal; authorize the work<br>preserve context across turns<br>direct the inner-loop work with the model<br>run tools; relay environmental feedback<br>evaluate progress against the goal<br>choose the next transition<br>decide when work is ready<br>resolve exceptions inline<br>accept the result<br>remember what failed for next time

LOOP-ENGINEERED SYSTEM

HUMAN<br>define the obligations and evidence<br>authorize the contract and future changes

CONFIGURED SYSTEM

harness — state, context, tools, bounds<br>Construction Loop — inner-loop work<br>performed by the model + harness<br>evaluator — what the evidence establishes<br>controller — repair, escalate, or stop<br>admission gate — what earns review

Learning Loop — evidence → proposed changes<br>proposals require human authorization

HUMAN<br>resolve genuine exceptions<br>review and accept the result

remains human<br>ordinary execution and coordination move<br>remains human

scroll horizontally to compare →

The...