Konstantin Semenenko
July 16, 2026
4
minutes read
Harness engineering is the environment around a single AI coding agent, tools, context, permissions, tests, verification, that makes a model controllable. Loop engineering sits above it: the repeatable system that runs agents on a schedule and checks results, replacing hand prompting. The harness is the machine, the loop is the program that runs on it, and the harness matters most: an audit of one leading agent found roughly 98% of its code is harness, not model logic. Build the harness first.
Harness engineering and loop engineering are two emerging disciplines that describe how teams actually run AI coding agents like Codex, Claude Code, and Cursor in 2026, and the distinction between them is worth getting right. Harness engineering is the engineered environment around a single agent: the file system, Git, shell, and tool access, the AGENTS.md and architecture rules, the context selection, sandbox, permissions, memory, tests, traces, and the verification that decides whether the work is actually done. Loop engineering sits one floor above: the repeatable outer system that runs those agents on a schedule or trigger, hands them work, checks the results, and decides the next step, so a person is no longer prompting each turn by hand. The cleanest way to hold it: the harness is the machine and its controls; the loop is the program that machine runs. Both terms are still settling, but the ideas are real, and this explains each, how they relate, and why the harness is where most of the reliability lives.
We build exactly this kind of controlled agent environment, our MCAF framework is a harness in these terms, so this is a practitioner's read on the two disciplines and where the actual leverage sits.
A harness is the engineered shell around a model that turns it from a text generator into a controllable agent. The model is the reasoning kernel; the harness is everything that makes its work legible, executable, and verifiable. In practice, a harness includes the instruction layer (task goals, project conventions, constraints, pointers to docs like AGENTS.md), the tool layer (file editing, shell, tests, build, Git, MCP access), the environment layer (dependencies, containers, runtime versions), plus context selection, sandboxing, permissions and secrets, task memory and state, logs and traces, and, crucially, the verification that decides whether a result meets its criteria before the agent declares success.
The key insight behind harness engineering is that the harness, not the model, dominates the behavior you actually experience. Claude Code, Cursor, Codex, and Aider often run on similar underlying models; what makes them behave differently is what their harnesses do. Recent research puts a sharp number on this: a systematic audit of one leading agent found roughly 98% of its codebase is the deterministic harness, permission gates, context pipelines, tool routing, failure recovery, and only about 2% is model-facing decision logic. That is the whole thesis of harness engineering in one statistic: the reliability of an agent is mostly the reliability of its harness, which is why "make the model smarter" moves the outcome far less than "make the harness better."
Loop engineering is the practice of designing the outer system that prompts the agent, instead of prompting it yourself. The idea crystallized in June 2026: a widely-shared post by developer Peter Steinberger argued that the relevant skill is no longer prompting coding agents but designing the loops that prompt them, and Google engineer Addy Osmani's essay "Loop Engineering" gave the practice its name and an anatomy, automations, worktrees, skills, connectors, sub-agents, and external state. Anthropic's Claude Code lead Boris Cherny was widely reported as describing his work as running loops that prompt the model rather than prompting it directly. By late June, both Anthropic and OpenAI had published their own framings of the pattern, which is a strong signal it moved from community argument to accepted practice.
Concretely, a loop is an outer cycle: take a task (from a GitHub issue queue, say), plan it, write the code, run build and tests, review the diff, send it back to the agent if there are problems, open a PR when it passes, then pick up the next task, on a timer or trigger, with sub-agents often specialized (a planner, a coder, a reviewer). The human sets the goal and the rules of the loop; the system runs the agents. The defining shift is from prompting (one instruction, one turn, by hand) to loop design (a system that decides what to prompt, when, and whether the result is acceptable). The layered framing that researchers now use captures it: prompt engineering, then context engineering, then harness engineering, then loop engineering, each layer building on the one below.
The relationship is the useful part, because the two are often conflated. Harness engineering builds the environment a single agent runs inside, what it can see, what it can do, and how its work is proven correct. Loop engineering builds the repeatable process that runs that environment over and over toward a goal. The harness answers "how does the agent work reliably?"; the loop answers "how does it keep working on its own?". A loop runs on top of a harness, so the loop uses the harness's tools, permissions, and verification on every iteration.
This dependency is why the harness comes first. A loop built on a weak harness does not multiply productivity, it multiplies failure: without solid verification and stopping conditions, a loop can repeat the same mistake many times, corrupt code, and burn tokens for hours, exactly the runaway-cost problem behind our $303,030 AI bill. The practitioners running these systems in production converge on the same advice: the hard part is not autonomy, it is verification, stopping conditions, and human-in-the-loop escalation, all of which live in the harness. A loop is only as trustworthy as the harness it runs on, which is why "a task without a check is just hope" has become a refrain in this space.
Naming these layers matters because it tells you where to invest. The instinct is to chase autonomy, build a bigger loop, add more agents, but the leverage is mostly one floor down, in the harness: the verification, the permission boundaries, the context discipline, the failure attribution. A team that builds an impressive loop on a thin harness gets an autonomous system that fails autonomously. A team that builds a strong harness first can add a loop on top and have it actually hold, because every iteration is verified and bounded.
This is the design principle behind how we build, and it maps directly onto the terms. Our MCAF framework is predominantly harness engineering: the rule that the agent may not guess, the layered checks and quality gates, the tool access, the AGENTS.md conventions, and the verification that binds task completion to evidence rather than to the agent's own say-so, the discipline in why AI-generated apps fail security review. An automated system that runs MCAF agents against a queue of issues, planning, coding, reviewing, retrying, is loop engineering on top. Get the harness right, and the loop becomes safe to build; skip it, and the loop just automates the failures. The controls that make either work are the same ones we cover in AI agent guardrails and AI agent observability.
Harness engineering and loop engineering are the two disciplines organizing how teams run AI coding agents. The harness is the engineered environment around a single agent, tools, context, permissions, memory, tests, and verification, and it dominates agent reliability so completely that an audit of one leading agent found roughly 98% of its code is harness, not model logic. Loop engineering sits above it: the repeatable system that runs agents on a schedule, feeds them work, checks results, and decides the next step, replacing hand prompting with loop design. The harness is the machine; the loop is the program that runs on it. Build the harness first, because a loop on a weak harness multiplies failure, and the hard parts, verification, stopping conditions, escalation, all live in the harness.
If you want AI coding agents run on a real harness, verified, bounded, and observable, with loops built on top only once that foundation holds, that is where our AI Dev Team work starts.
What is harness engineering? The practice of building the engineered environment around a single AI agent, its tool and file access, context selection, permissions, sandbox, memory, tests, traces, and verification, that turns a model into a controllable agent. The harness, not the model, dominates how an agent actually behaves on real tasks.
What is loop engineering? The practice of designing the outer system that prompts an AI agent on a schedule or trigger, instead of prompting it by hand each turn. The loop finds work, hands it to the agent, verifies the result, decides the next step, and repeats. The term was popularized in June 2026 by Addy Osmani, building on points from Peter Steinberger and Anthropic's Boris Cherny.
What is the difference between harness engineering and loop engineering? The harness is the environment a single agent runs inside (tools, context, permissions, verification); the loop is the repeatable process that runs that environment over and over toward a goal. The harness answers "how does the agent work reliably?"; the loop answers "how does it keep going on its own?". The loop runs on top of the harness.
Why does the harness matter more than the model? Because it dominates agent behavior. Agents like Claude Code, Cursor, and Codex often use similar models; their differences come from their harnesses. An audit of one leading agent found roughly 98% of its code is the deterministic harness (permission gates, context pipelines, tool routing, failure recovery) and only about 2% is model-facing logic.
Which should I build first, the harness or the loop? The harness. A loop built on a weak harness multiplies failure, it can repeat the same mistake many times, corrupt code, and burn tokens, because the hard parts (verification, stopping conditions, human escalation) live in the harness. Build a strong harness first, then add a loop on top once every iteration is verified and bounded.
