Harness Engineering vs. Loop Engineering: Where the Boundary Is Moving
The agent harness builds the machine. The loop makes it converge.
Everyone is talking about agents that can work for hours, but almost no one is talking about the thing that decides whether they actually finish or quietly burn your budget. The future of production AI will belong to teams that know the difference between building the harness that keeps an agent safe and designing the loop that makes it converge.
Abstract: Agent engineering is entering a new phase. For the past year, harness engineering has been the language of production AI: context, tools, orchestration, state, evaluation, and recovery. But as agents move from short interactive sessions to long-running autonomous work, the center of gravity is shifting toward loop engineering: the discipline of designing the cycles that start, verify, resume, and stop agentic systems. This article maps the boundary between harness engineering and loop engineering, explains why the distinction matters, and shows how to diagnose which layer is broken when an agent acts unsafely, forgets, loops forever, burns tokens, or declares victory too soon. The core argument is simple: the harness builds the machine, but the loop determines whether that machine actually converges.
Harness Engineering vs. Loop Engineering: Why the Future of Production AI Depends on Knowing Which Layer Is Broken
Harness Engineering vs. Loop Engineering: Where the Boundary Is Moving
Something quiet happened between spring and July 2026. The center of gravity in agent engineering shifted.
For most of the year, “harness engineering” was the umbrella term. If you were doing anything beyond prompting, you were building a harness: tools, context windows, guardrails, state, evaluation. The harness was the machine outside the model, and everything that made an agent reliable lived inside it.
Then loop engineering arrived and started absorbing parts of that territory. Tasks people used to call "harness work," such as scheduled execution, sub-agent spawning, maker/checker verification, and durable state across runs, are now filed under loop engineering. Harness engineering did not disappear. It shrank, or depending on who you ask, it got promoted one layer down.
This article compares the two, maps what is migrating between them, and explains why the boundary dispute is not just semantics. It determines what you reach for when an agent breaks.
The One-Line Distinction
A harness is the environment in which an agent runs. A loop is the cycle that drives the agent toward a goal.
Everything else is a boundary argument.
The harness answers static questions: what does the model see, what can it touch, what persists, what happens if it breaks. The loop answers dynamic questions: what happens next, when does it stop, who checks the work, how does it resume.
The cleanest version of the split comes from Addy Osmani. He defines harness engineering as making the environment a single agent runs inside, and loop engineering as that harness running on a timer, spawning helpers, and feeding itself. In his framing, the loop sits one floor above the harness (Osmani, “Loop Engineering”).
The rival version comes from Towards AI and a line of practitioner critiques. They argue the loop lives inside the harness, and that the harness is “the machine outside the model,” including the loop, tool feedback, error retries, and observability. Same components, opposite nesting (Towards AI, “Loop Engineering vs. Harness Engineering”).
Both are partially right, which is exactly why the field is arguing.
If you are a paid subscriber, thank you. Your support makes this work possible.
If you are a free subscriber and find these articles useful, please consider upgrading. A paid subscription is $80 per year or $8 per month.
Free subscribers typically receive access to the full versions of paid articles after one to two months.
