Published on · updated on · AI agents

Same model, different agent: what a harness is

What an AI agent's harness is, where the idea comes from, what we were already doing before LLMs, and why agents now need more control around the model.

Agent = model + harness

In February 2026, the LangChain team explained how they had improved their coding agent on Terminal-Bench 2.0, a benchmark of 89 tasks an agent has to solve by typing commands into a computer’s terminal. The agent went from solving 52.8% of the tasks to 66.5%, and from outside the top thirty on the leaderboard to the top five. The engine behind the agent, a large language model (LLM), stayed the same from start to finish. It was OpenAI’s GPT-5.2-Codex. What changed were the instructions, the tools and the code around the model (Trivedy, 2026a).

That code around the LLM is called the harness. Vivek Trivedy, at LangChain, summed it up in a formula that has been repeated a lot since, agent = model + harness, and in an equally short definition. The harness is all the code, configuration and execution logic that isn’t the model itself (Trivedy, 2026b). The LLM can be bought from a provider such as OpenAI, Anthropic or Google, or it can be an open model running on your own servers or on the device itself. The harness is always designed by whoever builds the agent. That design goes a long way toward deciding whether an agent gets it right once or gets it right every time.

In this article we look at what a harness is, where the idea comes from and why, in our experience, it matters more and more. In the next one we’ll cover the keys to building a good one.

What a harness is

A harness is the set of straps that hitches a draft animal to a cart, and as a verb it means to control and make use of a force (Wiktionary). The image fits agents well. A harness doesn’t make the horse any stronger, but without it that strength never reaches the cart or goes where you need it. The word also brings to mind the safety harness that holds a climber or someone working at height. That second reading is useful too, because part of an agent’s harness is there precisely to hold it back.

There’s a lot around the LLM. There’s the loop that calls it over and over, runs what it asks for and decides when to stop. There are the instructions and documents in front of it at each step, the tools it uses to act beyond text, such as searching the web, reading a document or querying another system, and the memory that carries over from one session to the next. And there are the limits, which mark what it may not do or needs confirmation for, and the checks that decide whether the work is done right. Trivedy explains it from the other side, starting with what an LLM can’t do on its own. It doesn’t remember anything from one conversation to the next, it doesn’t run code, and it can’t look up current information unless someone gives it the means (Trivedy, 2026b).

Harness

  • Instructions and context

    What the LLM sees at each step.

  • Tools

    What it can do beyond text.

  • Memory

    What carries over from one session to the next.

LLM (language model)

From a provider, or open and run on your own servers. Reads what is in front of it and proposes the next step.

The loop calls the LLM, runs what it asks for and decides when to stop.

  • Limits and permissions

    What is forbidden or needs confirmation.

  • Checks

    What decides whether the work is done right.

  • Traces

    What lets you see what happened and why.

Figure 1. An agent is an LLM plus its harness. The LLM may come from a provider or run on your own servers, and whoever builds the agent designs the rest.

Designing all of that is called harness engineering. Addy Osmani, who has written several essays on it for O’Reilly, describes it as the work of designing, testing and tuning the scaffolding that lets a model finish real work (Osmani, 2026).

Where the word comes from

The word comes from software development. A test harness is what you need to put a piece of code through its paces, such as the programs that start it and feed it data, stand-ins for the pieces that don’t exist yet, and whatever checks the result. The glossary of ISTQB, the international body that certifies software testers, defines it as the test environment made up of the drivers and stubs needed to run a test (ISTQB). The same word has been around for years in language model evaluation. According to its documentation, EleutherAI’s lm-evaluation-harness is the engine behind Hugging Face’s Open LLM Leaderboard (EleutherAI).

Applied to agents, the term spread within a few weeks in early 2026. Osmani credits it to Trivedy (Osmani, 2026), although it showed up in several places almost at once. On February 5, Mitchell Hashimoto, cofounder of HashiCorp, wrote that he had started calling a habit of his harness engineering. Every time an agent makes a mistake, he takes the time to make sure it can’t make it again, with better instructions or with tools that let it check its own work (Hashimoto, 2026). On February 11, OpenAI described how one of its teams had built an internal product over five months without writing a single line of code by hand. The engineers on that team stopped programming and started designing the environment the agent worked in (OpenAI, 2026). Trivedy’s two LangChain articles followed over the next few weeks, and in April Birgitta Böckeler pulled the ideas together in an article on Martin Fowler’s site that is now one of the go-to references on the subject (Böckeler, 2026).

Today the word has three uses worth keeping apart. There’s the harness that comes built into products for creating and running agents, such as Claude Code or Codex. There’s the one each team adds on top for its own project, with its own instructions, permissions and checks, which is the one Böckeler analyzes. And there’s the evaluation harness, the test bench that scores models and agents, a direct descendant of the test harness.

What we were already doing before LLMs

The term is new. The problem it names is not.

Shakey, the robot that the research institute SRI developed between 1966 and 1972, was the first mobile robot able to reason about its own actions (Computer History Museum). A planner worked out the sequence of actions needed to reach a goal, such as pushing a block to a doorway. Since the world didn’t always behave the way the plan expected, its creators added PLANEX, a system that monitored execution and let the robot react when an action didn’t have the expected effect (Fikes, Hart and Nilsson, 1972). Plan, act, check the result and correct is still the cycle of any agent.

Other ways of organizing that control came later. In 1986, Rodney Brooks proposed robots built from layers of behavior running at the same time, from avoiding obstacles to more elaborate tasks (Brooks, 1986). In 1995, Anand Rao and Michael Georgeff described BDI agents, with an explicit cycle that reviews what has changed, decides which goal to pursue, commits to a plan and drops whatever it has achieved or has become impossible (Rao and Georgeff, 1995).

Anyone who designed voice assistants before LLMs will recognize almost every piece. In a 2018 Alexa app you already had to keep track of what had been said in the conversation, decide when to end it, steer people back when they went off script, give the assistant a consistent personality and connect it to other services. Almost all of that lived in dialog management. Personality was also shaped when writing the responses, and even when choosing and tuning the synthetic voice. And we wrote all of it ourselves. The model only classified each sentence into an intent and pulled out the important details, such as a date or a city. The assistant did exactly what the flow allowed, which is why nobody talked about a harness. We covered this in building a chatbot in 2018 and building one today.

In October 2022, a team from Princeton and Google proposed ReAct, a method for a language model to alternate between reasoning and acting, and to use what it gets from each action to decide the next one (Yao et al., 2022). Many of today’s agents descend from that idea.

With an LLM the division of labor shifts, because the model brings autonomy and also unpredictability. It no longer picks from a set of planned responses. It writes them, decides which tool to use and when something is finished, and the same request can get different answers. The old functions are still needed, but now they serve to bound what the model proposes and to make the service behave in a predictable, safe way. On top of that come risks that didn’t exist before. The best known is prompt injection, instructions hidden in a web page or document that the agent reads and may end up following. OWASP puts it first on its list of risks for LLM applications (OWASP, 2025).

Memory

2018 assistant

Variables saved at each step of the flow.

LLM agent

The harness decides what is kept and what the LLM sees each turn.

When to end

2018 assistant

An end point planned in the flow.

LLM agent

The LLM proposes ending and the harness checks it is really done.

Detours and errors

2018 assistant

Help prompts when a request isn't recognized.

LLM agent

The LLM improvises and the harness keeps the reply within bounds.

Personality

2018 assistant

Hand-written responses and a chosen, tuned voice.

LLM agent

Style instructions and checks on what the LLM generates.

Other services

2018 assistant

Calls programmed at specific steps of the flow.

LLM agent

The LLM picks the tool and the harness controls permissions and confirmations.

Figure 2. The functions are much the same as in a 2018 assistant. What changes is who decides at each moment and how much control is needed around it.

Deep down, the problems are the same ones Shakey had. You need to know whether an action worked, notice when the job is done, set limits and recover from errors. What has changed is how much the engine can do on its own and, with that, how much control is needed around it. In our projects, that part takes up more and more time, and it’s usually what separates an impressive demo from a service you can put in front of customers.

The pieces of a harness

There are several ways to classify them. An academic survey published in May 2026 sorts them into four layers, covering execution, context, the connection to tools and environment, and constraints (Xie et al., 2026). We merge context and tools, because when you design an agent you decide them together, which leaves us with three families.

  • The execution core. The loop, the choice of model and how much it should reason at each step, and the ability to pick the work back up if something fails halfway.
  • Context and capabilities. The instructions, the information the LLM has in front of it at each moment, the tools, the specialized knowledge loaded only when needed (what Anthropic calls skills), memory, and subagents, other agents that take on part of the work.
  • Control. Permissions, checks, traces that record what the agent did and why, defenses against malicious instructions, human confirmations and evaluation.

The first two families give the agent what it needs to work. The third is what lets you trust it and, in our experience, the one that has grown the most since the engine became an LLM.

The harness of a voice agent

In a voice agent, the harness also includes pieces that don’t exist in a chat. It has to detect when the person has finished speaking, let them interrupt, fill with a phrase the seconds while the agent looks something up, and measure the latency of each step. We covered this in is it my turn to speak? and in three ways to build a voice agent. As in 2018, personality is spread across the instructions, the checks on each response and the voice that delivers it, as we explain in who’s talking when your agent talks? And since what’s said out loud can’t be taken back, the limits have to kick in before the response reaches the speaker. With the same LLM, two voice agents can feel very different depending on how well all of this is handled.

How we can help

At Monoceros we design and build agents, and a good part of that work is the harness. We decide what the model sees, what it can do, what it’s not allowed to do and how to check it has done its job well. Before launch, we evaluate it with real conversations to find out what each layer adds and what can go.

References

Written by

Carlos Muñoz-Romero

Co-founder at Monoceros Labs

Co-founder of Monoceros Labs. A computer engineer with a master's in data science, he leads Fonos's voice technology. Previously Chief Innovation Officer at BEEVA (now BBVA Technology).

Share this article:

Related posts

Thinking fast, thinking slow

Models that decide fast and models that think slow

Fast models, reasoning models and the new family of models that only make decisions, like Jev: what each brings to a voice agent, where latency rules, and how to combine them.

2018 and today: what's changed in building a chatbot

Building a chatbot in 2018 and building one today

From Alexa intents and flows to agents built on language models: what has changed in building a chatbot or voice assistant, and what hasn't.

Several agents for one call

How many agents does it take to answer a phone call?

Multi-agent systems: when splitting a task across several AI agents pays off, when it creates more problems than it solves, and what changes on a phone call.