From Harness to Loop: Engineering AI Agents That Converge, Not Just Execute

The previous article compared Vibe Coding, SDD, Harness Engineering, and Loop Engineering. This piece expands on Harness and Loop, clarifying the problems each solves in software engineering terms.

Core Distinction: Harness Enables Execution, Loop Ensures Convergence

SDD (Spec-Driven Development) defines goals, boundaries, and acceptance criteria for the entire development process. Harness and Loop operate at the task-execution level: Harness supplies the controlled environment — context, tools, permissions — so an agent can act; Loop uses real verification evidence to classify deviations, route responsibilities, apply fixes, and re-verify until the task reaches a proven done state. Without Harness, designs never become code; without Loop, agents may stop after a single change without confirming correctness.

Harness Engineering: More Than a Prompt

Giving an agent a prompt and repository access is not a complete Harness. Harness Engineering is an engineering support environment around the agent, comprising six capability areas:

Context preparation (design docs, interface specs, acceptance cases)

Toolchain access (build, test, static analysis, lint)

Permission boundaries (allowed files, commands, network)

Risk controls (resource limits, rollback triggers)

Observability (logs, diffs, test reports)

State persistence (task status, evidence history)

Harness makes test results, build logs, and code diffs available. Deciding how to act on those signals belongs to Loop.

The Missing Feedback Loop: From One-Shot Execution to Convergence

With Harness, an agent can read specs, modify code, run tests, and see failures. Yet it often stays in a one-shot mode:

receive task → modify code → run command → return "done"

Real tasks require judgment after each signal:

On test failure: retry, change code, or change approach?

On missing spec: guess or escalate to architect?

Multiple issues: which to tackle first?

After a fix: which verifications to re-run?

When to confirm done, pause, or hand off to human?

Loop Engineering addresses how a task moves from initial state through execution, checking, and correction to a provably completed state.

Loop differs fundamentally from simple retry. Retry re-executes with same inputs; Loop changes the next action based on new evidence — adjusting plan, adding context, switching tools, updating code, or even revising the design baseline. The core of Loop is that every round yields new evidence and every correction moves the task closer to the completion condition.

Tool-Level Loops vs. Loop Engineering

Tools like OpenCode's Ralph Loop (auto-continue until agent declares done, max iterations, or human cancel) and ULTRAWORK Loop (adds Oracle review) provide execution control mechanisms. Codex Goal mode further externalizes goal, run state, and budget, enabling multi-session persistence until completion or confirmed blockage. These are execution mechanisms, not yet full Loop Engineering. A complete engineering loop also integrates design baselines, verification evidence, issue classification, responsibility routing, and explicit stop states.

Loop Must Maintain State, Evidence, and Stop Conditions

Without state and stop conditions, loops degrade into infinite retries, wasting tokens and amplifying errors. A controlled loop continuously maintains:

Goal & Baseline: Current task, scope, design version, acceptance criteria

Execution Progress: Completed actions, current phase, pending items

Verification Evidence: Build, test, static check, diff, and review results

Deviation Classification: Design issue, implementation issue, environment issue, or risk issue

Next Action: Responsible role, fix content, re-verification scope

Runtime Constraints: Remaining budget, human confirmation points, stop reasons

Verification evidence and stop conditions are paramount. An agent claiming "tests passed" is not evidence; builds, tests, and checks must be executed by Harness tooling, preserving command, exit code, output, environment, and code version. Evidence should be independent: agent-written tests can find bugs but cannot serve as sole acceptance for critical features. Pre-agreed acceptance cases and existing regression suites, run by independent test roles or CI pipelines, are required. CI isolates execution, but if tests are also agent-generated, they are not inherently independent.

Tasks need more than "success" and "continue" states. At minimum: completed — all acceptance criteria verified waiting_human — requires approval (e.g., dependency change) blocked — external dependency unavailable failed — cannot proceed within budget/constraints

A mature Loop makes the agent aware of when to finish, when to pause, and when to admit it cannot continue.

Harness vs. Loop Boundary in Practice

Both involve tests and feedback. The difference: Harness provides capabilities and signals; Loop uses signals to change task state and next action. Example: Harness ensures the test command runs and returns failure logs; Loop decides whether the failure is a code bug, a design gap, or an environment problem, assigns the fix, determines which tests to re-run, and judges whether current evidence suffices to close the task.

As agents take on cross-file, cross-module, long-running tasks, engineering focus naturally shifts from Harness to Loop. A runnable environment alone cannot guarantee the agent isn't persisting in the wrong direction; only with checking, correction, and exit mechanisms can tasks reliably converge.

Concrete Example: Adding Rate Limiting to a Login Endpoint

Task: Same account and source IP limited to 5 login attempts per 60 seconds; 6th returns 429 with audit log; existing auth results and other endpoints unchanged.

The interface contract and acceptance criteria belong to SDD. Harness supplies the login module code, dependency manifest, build/test environment, and restricts modifications to the current module and build files — no production access.

A minimal Loop in pseudocode:

task.status = running
plan = create_plan(spec)
while task.status == running:
    change = agent.execute(plan, harness)
    evidence = harness.run(required_checks)
    if evidence.all_passed:
        task.status = completed
    else:
        issue = classify(evidence)
        stop_state = resolve_stop_state(issue, budget)
        if stop_state:
            task.status = stop_state
        else:
            plan = route_and_replan(issue)

The flow allows dependency updates with re-test, enters waiting_human for approvals, blocked for unavailable repos, and only reaches completed when rate-limit tests, login regression tests, and build checks all pass.

Putting Loop into Practice

Roles (architect, frontend, backend, test) form a responsibility-routed feedback chain, not isolated chats. Start with a single well-bounded real task, a versioned design and acceptance baseline, and minimal context/tool/permission config for each role. Run the "execute → check → classify → correct → re-verify → stop" loop until it stably delivers. Only then consider dynamic roles, complex workflows, and cross-project reuse.

Common Pitfalls That Create Illusion of Progress

Calling a long system prompt "Harness"

Repeating the same failed command and calling it "Loop"

Accepting agent's self-declared success without test/acceptance evidence

Defaulting all issues to the developer role without classification

Running without budget or stop conditions

Recording only final answer, discarding check results and correction rationale

Longer runtime and more tool calls do not mean closer to done. Loop effectiveness is measured by whether deviations shrink, evidence accumulates, and task state advances toward a defined exit condition.

Summary

Harness Engineering and Loop Engineering solve different problems. Harness enables agents to execute in a context-rich, tool-ready, bounded environment. Loop drives convergence by identifying deviations from evidence, routing issues, applying fixes, and re-verifying. Together with SDD:

SDD defines the correct outcome;
Harness provides controlled execution conditions;
Loop uses feedback and evidence to push tasks to completion.

The next phase of AI programming isn't about generating more code in one shot — it's about continuously delivering verifiable software results.