Agentic Harness

An AI language model can, by itself, do only one thing: generate text. It responds once to an input and is then done. For this to become an assistant that carries out a task on its own across many steps, it needs a program built around it. This program is called an agentic harness. The English word “harness” refers to the gear used to hitch up a draft animal or a machine. The harness hitches the model into a loop: it takes the model’s output, executes it, collects the result, and sends it back into the model.

Why the shell around the model co-determines how good an agent is

You often read that a particular model is especially good at coding. In reality, such tests almost always measure two things at once: the model and the harness it’s embedded in. The same model can solve markedly more tasks with a well-built framework than with a poor one. Providers have repeatedly shown that improvements to the harness alone can noticeably raise success rates on test suites.

The reason lies in the typical weaknesses of language models. They invent details, lose track after many steps, or endlessly repeat an unsuccessful idea. A good harness catches exactly that. It limits the number of attempts, gives clear feedback on errors, and summarizes long histories before the model’s working memory runs out of space.

Economically, this is an important point. Anyone building an AI product usually has little influence over the model itself, since it comes from a large provider. The harness, on the other hand, is one’s own engineering work. That is precisely where the difference between two products that use essentially the same model at their core arises.

The loop of thinking, acting, and observing

At its core, the same loop always runs. The harness sends the task to the model and gets a suggestion back, such as: “Open the file invoice.txt.” Such suggestions are called tool calls. The harness executes them, because only it has access to files, programs, or the internet. It sends the result back to the model as a new message. Then the next round begins.

This involves several fixed components. First, a list of allowed tools, such as reading files, executing commands, or starting a search. Second, a memory that keeps track of all steps taken so far. Third, stopping rules: after a certain number of steps or a certain cost, the agent stops. Fourth, safety boundaries, so that the model cannot execute arbitrary commands on a real machine.

A common misconception is that the harness is just a bit of glue code. In practice, it involves a great deal of fine-tuning. Exactly which error message is returned, in what form the current state of work is summarized, when a human is asked for permission: such decisions determine whether an agent works reliably or goes off the rails after ten steps.

From coding assistants to customer service

The best known examples are coding tools that run in a terminal or a development environment. They read files, change code, run tests, and react to error messages until the tests pass. These tools are almost entirely harness. The model behind them is the same one that also answers in the chat window.

The pattern also appears outside of software development. A research assistant searches, reads pages, searches again, and in the end writes a summary with sources. A customer service agent reads order data, checks rules, and triggers a refund. The same principle always applies: the model decides, the harness acts.

In trade press, you mostly encounter the term in discussions about benchmark results, i.e. standardized comparison tests. There you’ll find the note that a result was only achieved with a particular harness. Anyone who understands this reads such figures more cautiously. A model is never simply good or bad on its own—it is always good or bad within a particular framework.