Harness Engineering

An AI model on its own can only generate text. It cannot open a file, start a search, or verify anything by itself. For it to do such things, it needs a program built around it that hands it tools, receives its responses, and triggers the next steps. This program is called a harness. Harness Engineering is the work of designing, testing, and improving this surrounding structure. The model itself remains unchanged; only how it is harnessed is improved.

Why identical models perform differently

In recent years it has become clear that the same model can deliver very different results depending on its environment. In coding tasks, the difference between a bare-bones and a carefully built harness often accounts for double-digit percentage points in success rate. That is a difference for which one would otherwise have to wait for an entire model generation. This allows companies to make progress without training a model themselves.

This also shifts the question of what a test score actually measures. When a provider advertises a benchmark result, meaning its performance on a standardized task test, that result always reflects both things: the model and the harness. Two scores are therefore only comparable if the environment is disclosed. A common mistake is attributing a high score solely to the model.

There is also an economic dimension. A harness determines how often the model is called at all, and every call costs compute time and therefore money. A poorly built harness might have the model read the same file ten times. A good one remembers the result and saves the rest.

Tools, loops, and emergency brakes

A harness usually operates in a loop. It sends the task to the model, reads its response, and checks whether it contains a request for a tool. If so, it executes the action, such as running a code test or a web search. The result goes back to the model, and the loop starts over. This repeats until the task is solved or a limit is reached.

The design consists mainly of decisions about details. Which tools does the model get, and how are they described? How much of the prior conversation may remain in the model’s working memory before the oldest parts are dropped? Is an error returned as raw text or summarized beforehand? Each of these decisions noticeably changes behavior.

The emergency brakes are also important. These include a maximum number of iterations, a cost limit, and rules about which commands must never be executed. Without such limits, a system can get stuck in an endless loop. Much of this is classic software engineering, not machine learning.

Harnesses in coding assistants and agent products

Harness Engineering is most visible in coding assistants. Tools like Claude Code, Cursor, or OpenAI Codex sometimes access the very same models. What distinguishes them is exactly this surrounding structure: how they search within a project, when they run tests, how they present changes for confirmation.

The term also appears in news coverage, usually in connection with agents. This refers to AI systems that carry out multiple steps independently, one after another. When an improved harness is mentioned there, it doesn’t mean a new model version was released, but that the control logic was rebuilt. This should be distinguished from prompt engineering, where only the wording of the instruction is changed.

For users, this is especially relevant when comparing products. A good question to ask a provider is: What tools does your system have, and when does it stop? The answer often reveals more about quality than the name of the model being used.