AI Agent Equals AI Model Plus Harness: What the Harness Does and Why

For a while the story of AI progress was told through model releases: bigger, more capable foundation models arriving every few months. That story is incomplete. A language model, large or small, supplies raw intelligence, but how much of that intelligence reaches the user depends on the software wrapped around it. That wrapper is called a harness, and a growing body of work suggests it can matter as much as the model inside. Recent research on adapting harnesses to smaller models argues that a carefully tuned harness can let a compact model recover much of a frontier model's performance on business tasks at a small share of the cost. Read the exact figures in the original papers, but the direction is consistent with what practitioners see: the most powerful model does not always produce the most capable system.

So the race is increasingly about who builds the best harness, and not only about who builds the largest model.

Why a smart model still needs a harness

A language model can produce an answer. On its own, it cannot browse a folder, choose among tools, hold working memory between calls, verify what it wrote, recover from an error, or keep going toward a goal. Those gaps are what agents exist to fill. In an agent, a harness surrounds the model and converts its intelligence into structured, repeatable, goal-directed action.

Model versus agent

A model takes an input and produces an output, and then its job is done. An agent keeps working after the first reply. It reads files, uses tools, runs commands, remembers earlier results, makes decisions and continues through several steps until the task is finished.

How can that happen when a model is built only to predict the next output? Through the harness, the engineering system around the model. It decides what context enters the model, which tools are available, how tool calls run, what gets remembered, when the model gets called again, and which actions are refused or need sign-off.

The harness also creates the working loop:

The cycle runs like this: the model reads what is in its context, picks an action, calls a tool, looks at what came back, folds that into its context and goes around again.

That loop is what separates answering from completing a task. It can also hang off a scheduler or an external trigger, so the agent starts by itself at a certain time or when an event occurs.

The equation: agent = model + harness

The model is the part that predicts. Given whatever context it is handed, it produces the most useful next output or action. The harness is the software around it, which converts that raw ability into controlled, multi-step behavior.

Look at what happens when the same model is dropped into different harnesses:

• With a plain chat harness, it is a conversational assistant.
• Add web search, retrieval, source evaluation and citation checking, and it becomes a research agent.
• Give it a repository, an editor, a terminal and test output, and it becomes a coding agent.
• Wire it to customer data, business rules, messaging tools, triggers and approval steps, and you have an operations agent.

The model never changed. The harness did. That also explains why two products built on the same underlying model can behave very differently. One retrieves the right evidence, picks the right tool, recovers from failed runs, keeps its context tidy and verifies the result. Another loses key information, keeps calling the wrong tool or declares victory without checking. A product's capability can't be judged by its model alone: the model sets what the system can understand, and the harness sets what it can accomplish.

Telling the layers apart

People often use model, agent and harness interchangeably, though they are separate layers.

Codex and Claude Code illustrate the pattern well among coding agents. Each pairs the vendor's own models with a harness handling repository context, file access, tools, shell commands, memory, execution, test feedback and repeat loops. OpenCode, Goose, Pi, Letta and AutoGPT follow the same pattern as runtimes or frameworks, and they differ in supported models, tool sets, memory designs and how open they are.

The agent is the complete system, the model supplies intelligence, and the harness governs how that intelligence touches the outside world.

Open weights and open source are different things

Products like Codex and Claude Code are ready-made agents in which the model and the harness are developed and tuned together by one company. An open-weight agent instead combines a downloadable model with an existing or custom harness. That gives developers more control over deployment, tools, memory, privacy, cost and behavior. The weights can run on your own infrastructure and, where the license permits, be fine-tuned. A typical pairing is Goose with an open-weight model such as gpt-oss-120b, or OpenCode with a Qwen or Gemma model.

An open-source agent is something else: the harness code is public. Anyone can read and change how it prompts the model, which tools it offers, how it stores memory, how its loops run, what it integrates with, and how it handles permissions and context. OpenCode, Goose and AutoGPT are examples of open harnesses.

The two properties are independent:

• An open-source harness can still call a proprietary model through an API. OpenCode can drive GPT or Claude models, so its interface, control logic and tool execution are open while the brain is closed.
• An open-weight model isn't an agent by itself. A model like gpt-oss-20b can predict and decide, but it can't browse folders, run tools, hold task state or finish a workflow until a harness such as Goose, OpenCode or a custom framework surrounds it.

In compact form: an open-source agent is an open harness plus any compatible model, and an open-weight agent is a harness plus downloadable weights.

Why open ecosystems matter

Several labs now release affordable open-weight models together with open-source agent tooling, forming hybrid open ecosystems. Such releases have made open stacks serious competitors to proprietary coding agents on selected agentic benchmarks, though not consistently better across the board. Vendors' own evaluations often show proprietary frontier models staying ahead on several coding tests. The significant point isn't that one model beats all others. It is that an affordable open-weight model, joined to a carefully designed harness, can compete with expensive closed systems.

What a good harness contains

Performance comes from the combination of model and harness, and the harness is made of several parts:

• Context selection. Choosing what goes into each model call so the relevant file, record or document is present and noise is not.
• Tools. Reading and editing files, running terminal commands, calling APIs, browsing documentation and running tests.
• Planning loops. Splitting a large objective into smaller tasks the model can handle.
• Verification loops. Checking whether output is correct and actually works.
• Memory and state. Recording completed actions, earlier results, failed attempts and remaining tasks.
• Guardrails. Blocking unsafe, unauthorized or irrelevant actions and asking a human for approval when needed.
• Evals. Measuring which prompts, tools, context strategies, loops and recovery methods produce the most reliable behavior.

Design choices that shape a harness

Every harness makes decisions that quietly set the ceiling on what the agent can do, and a few deserve attention early.

How many tools, and how described. Giving a model twenty overlapping tools usually hurts more than giving it five clear ones. Names, descriptions and argument shapes are effectively prompts, so unclear tool definitions cause wrong calls.

How much to remember. Long histories crowd out useful context. Harnesses typically trim, summarize or store notes outside the prompt and pull them back when relevant. What is kept, and for how long, strongly affects whether an agent stays coherent on a long task.

Where to put the human. Some actions, like reading a file, are safe to automate. Others, like deleting data or sending money, deserve an approval step. Setting those lines is a harness decision and not a model decision.

What counts as done. A loop needs a stopping rule, such as passing tests, a verified answer or a step budget. Without one the agent either quits early or runs on.

A practical way to start

If you are building an agent, begin with the smallest harness that can complete one real task end to end: one model, two or three tools, a loop with a step limit and a written definition of success. Then collect ten to twenty real tasks, run them, read the traces and fix the most common failure first. Swapping the model comes later, once you know the harness is not the limiting factor. This order keeps you from blaming the model for problems that actually live in the tooling around it.

How file access works

A model can't touch the files on a computer directly. The harness exposes controlled tools that list directories, search file names, fetch relevant content, open and edit files, execute code and save results. The model chooses what information or action it needs next. The harness validates and runs that request, returns the result and adds it to the context. The exchange repeats until the model decides the task is finished:

The model requests an action, the harness executes it, the result returns, and the model picks the next action.

For example, asked to fix a failing test, the model might request a directory listing, then ask to open the test file, then the module under test, propose an edit, and request a test run. At each step the harness decides whether the request is allowed, performs it and reports what happened.

The evaluation harness matters just as much

Building an agent harness is only half the job. The other half is an evaluation harness that shows whether the agent works. It tests, under production-like conditions, whether the full system can choose the right tools, recover from failures, keep cost under control, follow safety rules and finish tasks consistently. That is more than passing an isolated benchmark.

An agent harness has many interacting parts, and each is a place where a regression can hide: prompts, context rules, tools, memory policies, planning loops, verification, permissions and recovery. Without an evaluation set a team can't tell whether changing one of them helped or quietly introduced a new failure. So the two harnesses form a feedback cycle:

1. Collect representative tasks, including realistic workflows, hard cases and failures seen before.
2. Run the full system, current model and harness together.
3. Inspect results: success, traces, tool calls, errors, cost and latency.
4. Change one component, whether a prompt, tool, model, memory policy, loop or routing rule.
5. Run the evaluations again on held-out tasks and regression cases.
6. Keep only changes that verifiably improve the needed balance of accuracy, reliability, safety, speed and cost.

Put briefly: build, evaluate, find failures, improve the harness, evaluate again.

Reading a trace

Evaluation is easiest when you can read what the agent actually did. A useful trace records every model call, the tool requested, the arguments, the result returned, the tokens used and the time taken. When a task fails, scan the trace for the first wrong step and not the last. Often the root cause is early: a missing file in the context, a vague tool description or a wrong assumption that every later step inherits. Fixing that one point in the harness usually repairs a whole family of failures, which is why trace review is one of the most productive habits a team can adopt.

Does the model still matter?

Yes. Newer models keep improving reasoning, coding, instruction following, tool-call accuracy, context capacity, speed, cost efficiency and multimodal skills, and a harness can't reliably create a capability the model lacks. But the model is no longer the entire product.

When several models are all good enough for a task, the harness may account for most of the remaining difference between products. Retrieval that finds the right file, tools whose actions are obvious, state handling that remembers finished work, verification that catches bad edits, permissions that stop dangerous steps and recovery that survives failures each add up.

That suggests a simple division of labor, which also makes a handy checklist for reviewing any agent project. Ask what the model can plausibly do, what the harness must add so that ability shows up reliably, and what evidence the evals give that it did.

• The model defines the outer limit of what the system can do.
• The harness converts that limit into dependable, repeatable results.
• The eval confirms whether the finished system really delivered, which is a separate question from whether the model is smart.

That is why so much application engineering now targets harnesses and evals. The harness is where a team builds lasting advantage, through private context, safer tools, domain workflows, memory, error recovery and user experience.

The answer to the central question

Can a model become a true, functional agent without a harness? No. A model alone lacks the environment to execute actions, reach external systems, remember completed steps, observe the effect of its decisions and keep working toward a goal. The model is the brain and reasoning engine. The harness is the body, tools, memory, feedback loops, permissions and guardrails that turn predictions into controlled action.

Or in one line: an AI agent is an AI model plus a harness.