This is the first article in a series of 2 articles on this topic. Part 1 will explain what a harness is, what components it includes and why it is so important. Part 2 will go into the principles for building your own harness for your own needs, whether you use AI for writing, summarizing documents, processing data, or anything else. You do not need to know programming or have coding knowledge to read and understand this content.

What is Harness?

In today's AI world, the formula Agent = Model + Harness is often used by LangChain and Addy Osmani (formerly at Google, now at Anthropic) to describe this structure. If you have ever heard the concept of AI Agent but still feel confused about how it specifically operates, this formula will help you define it more clearly. Addy Osmani even summarizes in an extremely concise and memorable way that if you are not the model, you are the harness.

LangChain defines a harness as any piece of code, configuration, and execution logic that is not a model. It sounds abstract, but you can imagine it like this, the model is like the engine of a car, and the harness is the chassis, brake system, steering wheel and gauges. A strong engine without brakes or steering wheel means no one dares to sit and drive.

So specifically, what is usually in this harness? According to LangChain and Addy Osmani, it includes the system prompt, the loaded document, the model tool used, along with the file location and status. In addition, the harness also contains rules for how to divide work and move work between steps, automated testing steps run by code, as well as a logging and cost measurement system.

What is the difference between prompt, context and harness?

It can be imagined that the process of working with AI is currently divided into three layers and each new layer will cover the previous layer. The first layer is prompt engineering, which is how you write commands to send to the model clearly and correctly. Next is context engineering, this step goes beyond simple commands to pay attention to loading the right documents, the right context into the model, neither too much nor too little. And the top layer is harness engineering, where you build an entire working environment around the model, with steps, checks, barriers, and saved states.

To make it easier to imagine, let's try to set up a real-life situation of asking AI to read photos of invoices and then create a spending table. If you just write "read the invoice and create a table", you are at the prompt engineering level. But if you include the desired table template and specific spending categories, you have now entered context engineering. And when you add a piece of code to add up the lines to see if they match the total amount on the invoice. If there is a difference, force the model to read it again and save which invoice has been processed, then that is harness engineering.

Writing a longer prompt only solves the first level. If you want to load the correct context or build a working environment around the model, you need to look beyond the command.

Why is changing a harness sometimes more valuable than changing a model?

Reality shows that sometimes just by changing the way the working environment is organized, that is, changing the harness, the results far exceed expectations compared to switching to a stronger brain. LangChain said their programming agent climbed from about 30th to about 5th on the Terminal Bench 2.0 rankings just by changing the harness, while keeping the model the same. Also on this chart, the same model but when running in different harnesses, the scores are significantly different.

Advertisement

OpenAI in the article "Harness engineering" in February 2026 told about their team using agent Codex to write most of the source code for a product, they realized that every time the agent made a mistake, the way to fix it was to add tools, add rules or add missing checks, not tell it to "try harder".

Anthropic in the article "Effective harnesses for long-running agents" published on November 26, 2025 points out that agents run many sessions or do too many things at once and then run out of context midway, leading to them thinking they are done when in fact they are not, or even marking completion without actually checking. The way Anthropic handles it is not to change the model, but to add progress recording files and JSON to-do lists to the system, forcing the agent to do each part one by one and only allowing it to be marked as completed when it has been checked and confirmed.

In short, the model determines the maximum capacity ceiling that the system can achieve, but the harness is what decides whether you can reach that ceiling or not.

What if there is no harness?

When bypassing external control layers, the model often encounters a series of quite common errors that are not specific to any specific task. One of the biggest problems is context overload. If you try to cram all the instructions, references, and examples into a single call, the model will easily miss the information in between. The "Lost in the Middle" study conducted by Liu and colleagues at Stanford, published in the journal TACL in 2024, shows that the model processes information best when the data is at the beginning or end of the context chain, while performance drops significantly when important information is inserted in the middle. You can imagine this, like when listening to a long meeting recording, the decisions that are finalized in the middle of the talk are often the parts that are most likely to fall out of the summary.

Another common mistake is the model trying to do too many things at once. According to Anthropic, when delivering a large amount of work in a single call, the model often gets unfinished work or crashes midway. This leads to the phenomenon of the model filling in information to make the answer look more complete, also known as filling in information. For example, in a meeting no one mentions a deadline, but when asking for a summary, the model can automatically add a specific date to the beginning just to complete the sentence structure.

Advertisement

Additionally, the model tends to self-report work completed when in fact it has not. Anthropic points out that the model often says "checked" but there is no evidence that it actually performed that check. Similarly, when the model is left to evaluate the quality of its own work, it often scores more leniently than objective standards, according to Addy Osmani's observations. In the long term, the model can also drift over time by imitating bad patterns already in the data, causing small errors to accumulate into large errors, a phenomenon OpenAI calls entropy.

The common point of all the above errors is that they cannot be completely corrected by writing a longer prompt. The smaller the model, especially those that run right on your personal machine, the more it needs to be broken down into simple steps and have an external, independent testing mechanism.

What blocks does a harness consist of?

Once we understand why simple prompts are not enough to keep the model on track, we can look at the specific structure of a harness system. You can imagine this, if the model is an engine, the harness is the vehicle frame, brake system and controller that help that engine run safely on the road. According to the list compiled from LangChain and supplemented by Addy Osmani, a complete harness usually includes 7 main functional blocks.

• Input and context: Clean data, load only the correct documents for each step.
• Divide steps and coordinate: Cut big tasks into small steps, decide which step to run first.
• Tools: What the model is allowed to use: read files, search, run commands.
• Check by code: Machine rules can check 100%: format, total, forbidden words.
• Check with a separate review: Another model (or same model, different role) scores the test according to the criteria.
• Status and log: Save progress to file, log to know where the failure is, continue running when interrupted.
• Barriers and reviewers: Limit permissions, if something cannot be undone, the human presses the last button.

The first block is input and context processing, where the system will clean the data and only load the correct documents needed for each specific step, instead of throwing the whole data warehouse in at once. Next is the step division and coordination block, which is responsible for cutting a large complex job into smaller steps, and deciding the order of execution so that the model does not get lost midway.

In addition, the tool block clearly defines what the model is allowed to operate, such as reading files, searching for information or running commands, helping to limit the scope of AI operations to what is safe. The biggest difference lies in the two testing blocks, which are testing with code and testing with separate checks. Code testing is used to identify computer rules that can be tested with 100% accuracy, such as data formats, sums, or banned word lists, while separate testing will use another model (or the same model but acting as a supervisor) to grade the work based on softer criteria.

Finally, there are two blocks that ensure persistence and safety, including status and logs, along with barriers and reviewers. Status and logs help save progress to files and record detailed logs, so you can know exactly where the system broke down and continue running when disconnected. Roadblocks and reviewers serve as the final layer of defense, where permissions are tightly limited and any action that cannot be undone requires human confirmation before execution.

Workflow or agent, which one needs more harnessing?

To answer this question, it is first necessary to clearly distinguish the two concepts that Anthropic defined in the article "Building effective agents". Workflows are processes with predetermined steps in code, meaning that humans have drawn a road map for AI to follow. In contrast, an agent is a model that decides for itself what the next step should be, automatically reasoning and choosing a direction based on the results of each previous step. This difference directly affects how we design harnesses, especially the complexity of test blocks and barriers.

For clear, repetitive tasks like reading invoices, summarizing meetings, or translating documents, workflow is often a more stable and cheaper option. Because the steps are predefined, the harness only needs to focus on ensuring each step executes correctly, without needing too many complicated mechanisms to monitor the freedom of the model. However, when faced with open tasks where the number of steps that need to be taken cannot be predicted, the agent will be effective. But this flexibility is also a double-edged sword, because operating costs will be higher and errors can accumulate from step to step, causing the system to easily fall into chaos without solid barriers.

In actual implementation, Anthropic has shown the two most commonly used harness design patterns to handle these workflows. The first pattern is prompt chaining, which is a sequence of gated steps, where the next step is only allowed to run when the code confirms that the previous step has passed. This helps prevent the AI ​​from continuing to run on a false result. The second model is the evaluator-optimizer, which operates according to the mechanism of one side doing and the other side scoring, specifically the model writes the content, then another model will score based on clear criteria and then return it for repair. These two samples show that the harness is not simply running commands, but is a continuous feedback system to keep the output quality always within a safe zone.

The most important advice Anthropic gives to developers is to start simple, only adding complexity when absolutely necessary. Building an overly complex harness from the start is expensive and increases the risk of being difficult to control, while a simple system with clear checkpoints often provides more sustainable results for users.

So is choosing a model still important?

The short answer is still important, because the model is the factor that sets the capacity ceiling for the system. If the model is too weak, the harness cannot save it. However, for most daily needs, the gap between a decent model with a good harness and a strong model without a harness is larger than one might think.

Addy Osmani also reminded that when new models are released with superior capabilities, some parts of the harness will become redundant, so the harness must also be reviewed from time to time.

Choosing a model is like choosing an engine for your car, but whether the car can run far or not depends on other factors around it. I think focusing too much on hunting for the latest model and ignoring building a stable harness for your own work is a common mistake, because the real value lies in the harmonious combination between these two factors.

Please wait for part 2 so I can share the principles to help you build your own harness for your own work.