Harness Architecture

An AI language model can, by itself, do only one thing: generate the next piece of text from a given text. It cannot open a file, launch a program, or remember anything beyond the current conversation. To turn it into a useful tool, one builds a program around it. This program takes in the user’s task, passes it to the model in suitable portions, carries out what the model proposes, and hands the result back. This scaffolding is exactly what is called the harness architecture. The English word “harness” refers to the gear placed on a draft horse: the horse supplies the power, the harness directs it in a useful direction.

Why two companies using the same model produce different results

Many companies use the same models they purchase from providers such as OpenAI, Anthropic, or Google. Yet their products differ significantly in quality. The difference almost always lies in the surrounding scaffolding. Whoever presents the model with the right information at the right time gets noticeably better answers out of the very same model.

This becomes especially clear with coding assistants. In tests where AI systems are asked to fix real bugs in software, the same model’s success rate can vary by ten percentage points or more depending on the harness. A system that first searches through the code and then automatically tests the change afterward performs far better than a system that simply asks once and adopts the answer without checking it.

This leads to an economic argument. Training a model of one’s own costs hundreds of millions of dollars and is out of reach for most companies. Building a good harness costs developer time. This is why competition among many AI companies is shifting precisely to this area.

Loop, tools, and memory

The core of almost every harness architecture is a loop. The scaffolding sends the task to the model. The model responds either with a result or with a request to use a tool. The scaffolding actually carries out this step and sends the result back to the model. This repeats until the task is completed or a defined upper limit is reached.

Tools here are simply ordinary functions: a web search, a calculator, database access, executing program code. The model only proposes which tool it would like to use and with what inputs. It is not permitted to execute anything itself. This separation matters, because it allows the scaffolding to block dangerous actions or to ask the user for confirmation.

A third building block is managing the context window. This refers to the limited amount of text a model can read at once. With long tasks, at some point not everything fits anymore. The scaffolding then has to decide what to keep, what to summarize, and what to store in external memory. A common misconception is that larger context windows make this problem obsolete. In practice, models' accuracy drops when the text becomes very long, which is why targeted selection continues to work better than dumping everything in.

From coding agents to customer service

Harness architectures are most visible in coding tools such as Claude Code, Cursor, or GitHub Copilot. These systems independently read files, modify code, run tests, and correct themselves after error messages. The model behind them is often the very same one that responds in an ordinary chat window. Only the harness is different.

The pattern is also widespread outside software development. An AI customer service system that looks up order status works on the same principle. So do research assistants that visit multiple websites and merge the results.

In technical articles and company announcements, the word “scaffolding” often appears instead of “harness.” The same thing is meant. When a provider reports that its system has improved on a benchmark, it is worth asking whether a new model is behind it or merely a better harness. Both are often sold in the same breath, yet technically they are fundamentally different things.