Agents and Harnesses

Recently, it has become more and more clear that the experience of agent-based products is only partly attributable to the underlying AI model. The system around it, called the harness, plays a crucial role. I experienced this first-hand earlier this year with OpenClaw. It ran on the same model I had been using for months, but with a different system around it, and it felt like a different product.

In just a few years we have gone from prompt engineering, to context engineering, to what is now called harness engineering. Each step adds another layer around the model. This blog post is a high-level intro and exploration of that evolution: how agents went from being a model plus tools to a model with a whole system around it called a harness, what that harness is made of, and what I am keeping an eye on next.

The evolution of agents

Last year (2025) was famously called the year of agents. A common definition of agents back then was Agent = Model + Tools. By having access to tools, the AI models (Large Language Models) would go from doing chat completion, to having agency and being able to do things. A lot of hype was created by all the new exciting use cases enabled by the combination of the growing ecosystem of tools developed for agents and increasingly capable models that got better at using these tools.

Fast forward to 2026, and a new definition of agent started to get popularized. Today tools are only a subset of components in the system around the models that create what we call an agent, and a more common definition is Agent = Model + Harness.

This was the shift I had felt with OpenClaw and Codex: memory and loop engineering, not tools, were what made the difference. Therefore, I have been spending a bit of time trying to understand this system around the model called the harness, and the next section unpacks my insights.

The harness

A common definition of an agent harness is the software infrastructure that wraps around a Large Language Model (LLM) (Parallel, Databricks). LangChain has an even simpler one: If you're not the model, you're the harness (LangChain).

Some popular harnesses include:

• Claude Code, Codex, and Pi, which are all harnesses built for coding.
• Buzz, which is a harness built by Block for agent-human collaboration.
• OpenClaw and Hermes, general-purpose personal agents.
• QM, a multi-agent workspace harness by YCombinator.
• DeepSeek-harness, a general agent harness, where all components are swappable plugins.

After having spent some time studying the harnesses above and the articles linked throughout this post, it's clear that we are still very early when it comes to harness engineering, and the pieces that these systems are made of. There does, however, seem to be a consensus that the following components play an important role in this system we call the harness.

Key components of agent harnesses

Memory

A limitation of today's AI models is their limited ability to remember things across sessions. Large Language Models have what is called a context window, which is essentially their short-term memory, and when a chat session ends, that context is wiped, much like RAM on a computer that shuts down. Enabling the model to remember important pieces of information from previous sessions is a huge unlock, especially when it comes to making more personalized experiences. I experienced this first-hand when I played with OpenClaw, and it was the first agent that gave me the feeling that it remembered things I had said in the past and used them in a useful way. Memory is also essential in long-running coding tasks, where decisions and findings from shaping exercises and experiments can be noted down and help improve the next task. Agent memory can be implemented in many different ways, but one that I find particularly interesting is the LLM wiki, where the model incrementally builds and maintains its own persistent wiki. Notably, there is something special about memory compared to the other components: it compounds. As LangChain points out, an agent without memory can be replicated by anyone with access to the same tools, and since it is the harness that manages memory, owning your harness really means owning your memory.

Context management

The context window of frontier Large Language Models is up to around 1 million tokens. That means the models can hold roughly 7 books in their context. When that gets close to full, you get context rot, i.e. the performance decreases because some of the information ends up being noise. Once you go over the context window, the default is to just truncate the window, which can really hurt the performance. An example of that is when OpenAI found that they could triple their scores on the ARC-AGI-3 benchmark, by enabling two context-related settings, namely keeping reasoning across tool calls and turns and replacing rolling truncation with compaction - a summary of the previous actions. These are two examples of context management strategies that a harness can help configure and handle.

(Visual from OpenAI on Context Management)

System Prompt

There are some instructions and context that you want to give to the model every single time you start a session. One can think about these as the house rules that the model must know and respect. This can be things such as tone of voice when responding, the context that the model is being used in, things to always do, like running tests before committing, and so on. By using AGENTS.md and CLAUDE.md, one can configure the system prompt in the harness.

Orchestration

When dealing with complex and long-running tasks, an agent's work will typically span over many model calls and user turns. Without a high-level plan, the model can lose sight of its goal. Part of the orchestration layer is therefore to ensure that the agent creates a plan with tasks before starting the implementation. Additionally, the harness can enable the model to use sub-agents, fresh agents that can work on more narrow and scoped tasks, which again helps prevent context rot, allowing the main agent to focus on the goal.

Tools

As explained earlier, tools are what let the model act on the world: search the web, browse a page, call an API. Seen from inside the harness, they look a little different. The model never runs a tool itself. It only produces text, so a tool call is really a request, such as "read this file" or "run this command", that the harness picks up and executes. The result is appended to the context and the model is called again with it. A whole ecosystem is now being built around tools, with MCP as the default protocol for connecting agents to external ones.

Verification

Verification is the way the model verifies its own work. Depending on the task, it can be done in many different ways, but it will often require some review of files, checks and tests. In programming it can be running a set of unit tests, or using the browser to verify it visually. It can also be running an evaluation test set and checking that the scores actually improve.

Other components

The components above are some of the most important pieces of most open source agent harnesses today. Other pieces include sandbox environments, permissions & guardrails, and observability, which are already built into these harnesses, but I had to stop the list somewhere :)

The pieces together in a loop

Below I have tried to visualize a common loop in a harness using the components above, and how I currently think they fit together:

Interesting to watch

My sense is that we are still very early when it comes to harnesses. The components of a harness are co-evolving every day. As I wrote this blog post, some questions came to mind that I am keeping an eye on:

• Will end users end up with just 1-2 AI systems/applications, built on a limited set of harnesses, or will it look more like the app store with multiple tailored AI systems all with different harnesses?
• As the complexity of harnesses grows because of the many sub-components, and the systems get more intertwined with the models, how do we evaluate agents and specifically the harness? The article on Harness Engineering for Self-Improvement gives interesting insights into some of the approaches and how harnesses can be optimized in a self-improving way.
• Will harnesses end up looking much like traditional SaaS where code, not weights, is still the default development format, and become an important moat for AI labs?
• If the above turns out to be true, how can one stay agent(harness)-agnostic to avoid vendor lock-in? There are already services and frameworks being built around this, like Deep Agents and Harnessrouter, which I think are worth keeping an eye on.

Conclusion

It is clear to me that Large Language Models are no longer just the product. As the models become more capable, the system around them, i.e. the harness, needs to co-evolve with them to enable the models to do even more advanced work.

The field, just like model development, is evolving quickly, and I expect this to continue and even accelerate. In just a few years we went from prompt engineering, to context engineering, to now harness engineering. In the end, I think Andrej Karpathy was spot on when he, in late 2025, pushed back and said that this was not the year of agents, but the decade of agents. There are still so many things around the models that need to be built to get the full potential out of them.