Loop Engineering vs Harness Engineering: What's the Difference?

Your agent stalls mid-task and asks what to do next, again, even though you already told it the plan once. The retry logic looks fine on paper. Somewhere between deciding what to try and actually trying it, something broke, and it is not obvious which.

That gap has a name: loop engineering vs harness engineering, two disciplines that live inside the same agent but control different things. Mixing them up is why “just add more retries” fixes some agents and does nothing for others.

TL;DR: Loop engineering, in Addy Osmani’s phrasing, sits one floor above the harness: it is where you replace yourself as the person prompting the agent, through the retry policy, stop condition, and step budget that decide what happens next. Harness engineering is the execution layer below it, the tools, sandbox, and context assembly that carry an action out. Most production agents need real investment in both, not one instead of the other.

What loop engineering controls

Loop engineering is the design of the system that decides what an AI agent does next, instead of a person typing each instruction by hand. Developer Addy Osmani, who named the practice in June 2026, put it plainly: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

In practice, that means building rules for a small set of decisions: what task to pick up next, how many times to retry a failed step, when a result counts as good enough to stop, and when to give up and hand the run to a person. None of those rules touch how one action gets carried out.

Think of loop engineering as the layer that answers “what happens next, and when do we stop.” A project manager answers the same questions for a human team. Here, the judgment gets encoded into a running system instead.

That system wraps around an AI agent loop, the mechanism that lets one goal turn into a repeating sequence of steps. Loop engineering is the deliberate design of that mechanism’s rules, not the mechanism itself.

What harness engineering controls

Harness engineering is the design of everything an agent needs to actually carry out the step the loop just chose. Developer Vivek Trivedy’s formula captures it in five words: agent equals model plus harness. Read that formula the other way and it gives you a working test: if a piece of the system is not the model itself, it belongs to the harness.

That covers a concrete set of things: which tools the agent can call, the sandbox or filesystem it runs actions inside, how much history gets assembled into its context for each call, and the logging that lets someone see what happened. None of that decides what to try next.

A well-built harness separates “the agent tried to run the right command” from “the agent tried it, and it worked, inside a sandbox that did not touch anything else.” A harness that accumulates unused tools and stale permissions becomes its own drag on a coding agent, the kind of bloat that slows every run down.

Loop engineering sits one floor above the harness

Osmani did not leave the relationship between the two terms to guesswork. In the same essay that named loop engineering, he calls harness engineering “the cousin of this, agent harness engineering, which is making the environment one single agent runs inside …”, then places the two directly against each other: “Loop engineering sits one floor above the harness.”

That line is the cleanest way to hold both terms in your head. The harness is the floor an agent stands on: one run, one environment, one set of tools and constraints. Loop engineering is what happens above that floor, deciding when to run again, spawn another instance, or stop entirely.

You can have a solid harness with no loop around it, a single well-built agent run that does one job cleanly and stops. You can also have a loop wrapped around a weak harness, a scheduler that keeps calling an agent whose tools and sandbox are not actually reliable. Neither half fixes the other.

The shape of the system above the harness, whether it is one loop or several coordinated ones, is its own design question. Named agent architecture patterns cover a few common shapes that loop engineering can take once the harness underneath is solid.

One agent step, two layers

Picture an agent fixing a failing test. The loop decides this is the next task to pick up, based on a queue of failures it is working through. That decision, which failure to try next, is loop engineering.

The harness then takes over for the actual attempt. It hands the agent read access to the right files, a sandboxed shell to run the test in, and a tool schema for editing code. None of that involves deciding what to work on. It is the machinery that lets the chosen task run at all.

The test fails again. Now the loop decides what that failure means: retry with a different approach, escalate to a person, or move to the next item in the queue. The harness’s job, meanwhile, is making sure the retry itself, another sandboxed run with fresh file access, executes cleanly.

Watching one step this way is the fastest way to stop mixing the two up. Ask which question you are actually answering. “What should happen next” is loop engineering. “How does this attempt actually run” is harness engineering.

Loop engineering vs harness engineering at a glance

The table below lines the two disciplines up side by side, using the same run to anchor both columns.

Read across any row and the two are not competing for the same job. They are answering different questions about the same run, one deciding, one executing.

Where the lines blur

The two layers are not sealed off from each other. A loop’s stop condition usually depends on something the harness reports back, like whether a test actually passed, so the decision layer is only as good as the signal the execution layer hands it.

Context assembly is a good example of the blur. Deciding what information the agent sees on its next call is technically a harness job, but a badly assembled context, too much irrelevant history, can quietly break the loop’s ability to make a good next-step decision.

This is also where a shorter version of the split helps. MindStudio’s comparison of the two frames it this way: the loop is the agent’s behavior, the harness is the agent’s environment. Behavior only looks reasonable when the environment reporting into it is accurate.

Step budgets blur the line the same way. A loop’s decision to keep going or stop is often just arithmetic, cost so far against a cap, but that running cost number only exists because the harness metered every tool call underneath it. Take away the metering and the loop is guessing.

Why teams confuse the two

Towards AI’s comparison of the two disciplines opens with a sharp observation: an agent that spins in circles forever and an agent that never starts without you typing something share the same root cause. Read that back through the two layers and the shared cause has an address: whichever layer was never actually built.

That is usually where the confusion starts. A team notices an agent behaving badly and reaches for the easiest fix to name, more retries, a longer timeout, a stricter prompt, without first checking which layer actually broke.

Weak harness engineering tends to produce unsafe or brittle single runs: an agent that tries the right thing but executes it in a way that corrupts state or skips a permission check. Weak loop engineering tends to produce runs that never end, or never begin without a person nudging them along.

Naming which failure you are looking at, a bad decision or a bad execution, is most of the fix. The rest is picking the right layer to change, instead of tuning the one that was already working.

Team structure makes this worse in practice. The person who owns the scheduling code and the person who owns the tool integrations are often not the same person, and neither one has full visibility into the other’s layer. A bad run can sit unassigned between two owners for longer than it should.

Do you need both

Most production agents need real investment in both layers, not one instead of the other. A loop with no harness underneath it has nothing reliable to decide about. A harness with no loop around it can only do one job once, then stop.

The two are not competing for the same budget, even though teams sometimes talk about them that way. They answer different questions, and a team that only ever asks one of them keeps hitting the failure mode the other one was supposed to catch.

A useful test before you invest further in either layer: describe the last bad run out loud. If the sentence is “it tried the right thing and could not execute it cleanly,” that is a harness gap. If the sentence is “it kept repeating itself and would not stop, or it would not start without me,” that is a loop gap.

None of these eight questions is optional once agents are running in production. Skipping the loop side leaves you babysitting every run. Skipping the harness side leaves you with a scheduler confidently retrying something that was never going to work in the first place.

The same split shows up one layer over, too. Prompt engineering still matters inside both: a loop still needs well-worded prompts for its decision calls, and a harness still needs well-worded tool descriptions for its execution calls. Neither newer discipline replaces it.

Which one are you missing

The split holds up because the two disciplines answer different questions about the same run. Loop engineering, in Osmani’s phrasing, sits one floor above the harness: it is where you replace yourself as the person prompting the agent. Harness engineering is that floor underneath, the tools, sandbox, context assembly, and permissions that carry one attempt out.

To place your own problem, describe the last bad run in one sentence. “It tried the right thing and could not execute it cleanly” points at the harness. “It kept repeating itself and would not stop, or it would not start without me” points at the loop. That sentence is usually enough to tell you which layer to change, and which one was already doing its job.

Watch for the places the two lean on each other. A stop condition is only as good as the signal the harness reports back, and a step budget is only arithmetic if something underneath metered every tool call. When the decision layer looks wrong, check whether it was handed accurate information first.

Neither layer covers for the other. Invest in the loop alone and you get confident retries of unreliable work; invest in the harness alone and you get one clean run with nothing deciding when to run it again. Name the layer, then fix that one.