![Cover image for [Agent Design #1] What Is Harness Engineering? What Comes After Prompting](/assets/images/posts/e5b7d384-3107-41fb-a62e-34369bc15f27/harness-engineering-1.jpg)
Teams get different output quality with the same model. One team has AI handle an entire refactoring, while another has to rewrite even simple fixes by hand.
The difference isn’t the prompt wording. It’s the execution environment around the model—in other words, the harness.
In one sentence, harness engineering is designing the entire loop in which a model uses tools, gets its results verified, and works toward completion. If prompt engineering is “how to communicate effectively,” harness engineering is “how to set up a workplace where the work gets done well.”
This article explains exactly what a harness is, what its components are, and how to judge whether a harness is good.
Let’s start with the key takeaways.
- A harness is the execution loop wrapped around a model. Its components are tools, permissions, context management, and feedback.
- Agent performance is determined by model intelligence × harness quality.
- The core of a good harness is a feedback loop that lets the model verify its own results.
- The reality behind coding agents such as Claude Code and Cursor is the harness itself.
What Exactly Is a Harness?
Originally, a harness meant the tack used on a horse. It doesn’t increase the horse’s power; it converts that power into useful work, such as pulling a cart.
The term test harness comes from the same lineage.
An LLM harness works the same way. It leaves the model—its intelligence—unchanged and refers to all the software that wraps it so that its intelligence leads to real work.
Specifically, it includes things like these.
- Tool layer: functions the model can call, such as reading and writing files, running shells, and searching.
- Permission layer: policies governing what to ask about and execute, and what to approve automatically.
- Context layer: what to show the model, what to hide, and when to summarize.
- Loop layer: the repeated structure that turns tool results into the next action, along with termination conditions.
We call Claude Code or Cursor “AI coding tools,” but the model itself is the same model behind the API. The product’s substance is the harness.
Performance = Model × Harness
There are already many cases where benchmark scores diverge sharply with the same model. Agent benchmark leaderboards show success rates differing by dozens of percentage points depending on the harness, even for identical models.
The reason is simple. Agent tasks are chains of dozens of tool calls, and the harness intervenes at every step.
| When the harness is poor | When the harness is good |
|---|---|
| Pour the entire tool result into the context | Summarize and pass on only what is needed |
| Repeat the same attempt even after failure | Feed the error message into the next attempt |
| Judge completion by the model’s claim | Verify with tests and builds, and terminate only after they pass |
Models make mistakes probabilistically. The harness doesn’t eliminate mistakes; it ensures they are caught during verification and corrected by the model itself.
Three Conditions of a Good Harness
From a practical perspective, three conditions determine harness quality.
First, a verifiable feedback loop. When the model changes code, you need to run the tests and show it the results.
Just as people cannot trust code written without compiling it, an agent without feedback only accumulates confidence in itself. That’s why codebases with strong test coverage see the greatest impact from agent adoption.
Second, context budget management. The context window is finite, while tool results pour out without limit.
Trimming long outputs, summarizing old content, and isolating exploration work in subagents are the harness’s responsibilities.
Third, a safe failure path. Permission policies and sandboxes must define the “range in which mistakes can be recovered from.”
For example, automatically approve reversible operations and ask a person only about destructive ones.
The Relationship with Prompt Engineering
This doesn’t mean prompt engineering has become useless. It simply operates at a different layer.
A prompt optimizes a single request. A harness optimizes a loop of dozens of successive requests. Writing a system prompt becomes a subset of harness design.
The center of gravity has shifted from “What should we say?” to “What environment should we provide?” The better models become, the stronger this trend gets. Instructions can become shorter, while tools and verification loops become even more valuable.
Conclusion
If an agent’s output is disappointing, inspect the harness before refining the prompt. Can the model verify its results? Is the context full of clutter? Does failure feed into the next attempt?
In the next article, we’ll cover context engineering, which takes a deep dive into the context layer.