The Harness Does Two Jobs

Nov 5, 2026 · @Nunzio Fiore

The jump didn't come from the models alone

Over the last two years, agents have improved more than the models that power them. The difference was made by what surrounds the model, and today it has a name: harness.

A harness is the system that lets a language model act as an agent. In the definition Google Research gives in the Harness² repository, it is "the system around a model that lets it act as an agent": the prompt that tells it who it is and what to do, the tools it can call, the memory it keeps between sessions, the skills that describe how a job is done, the sub-agents it can delegate to. The model is the engine. The harness is the car.

The simplest proof is this: the same model, inside two different harnesses, gives different results. That's why people talk about harness engineering, and why this word deserves a whole article: because the harness does two jobs, and almost everyone only tells one of them.

The harness's two jobs

The first job is making the model capable. The second is keeping it within limits. Almost all research talks about the first; a company needs both.

The inner circle is what's meant when people say harness engineering: the prompt that gives the agent its role and instructions, the tools it can call, the memory between sessions, the skills that describe how a job is done, the sub-agents to delegate to. The better it's built, the more the same model delivers.

The outer circle is what decides what the agent can reach, and on whose behalf: tool-by-tool permissions, the identity of the person asking, credentials the model never sees, the company's rules, outcome verification, the log. It doesn't make the agent smarter. It makes it possible to let it work.

The two circles have different owners. The first is improved by whoever builds the agent, and the agent itself can improve it too, under approval. The second only the administrator changes, and no automatic cycle touches it. Keeping the two circles separate is the architectural decision everything else follows from.

Where the word originates

Harness has two meanings in English, and both matter. In software it's the testing scaffold: the test harness, the code that surrounds a program to run it under controlled conditions and observe its behavior. Outside software it's tack: the straps that hold the horse, guide it, and at the same time leave it the strength to pull.

When the word moved over to agents, it carried mostly the first meaning, the scaffolding that makes the work possible. The second stayed in the background, and that's a pity, because it names the part that matters most in a company.

Italian has a single word that holds both senses together: imbracatura. It holds, it guides, and it lets you move. In the following pages we'll use "harness", because that's the word the market speaks, but the sense we give it is that one.

The road of harnesses

In two years the harness went from industrial secret to something an agent can rewrite on its own. There are four stages.

Private harnesses. The first widely used coding agents, like Claude Code and Codex, showed how much the scaffolding matters: context management, the test-and-fix cycle, the tools. That scaffolding was, and is, locked inside the product.
Modular harnesses. Projects arrived where every piece of the harness can be taken apart and reassembled: prompt, tools, memory and orchestration as separate components, to combine.
Open harnesses. The same components became open source, and with them the possibility of studying how a harness is built and adapting it to one's own tasks.
Self-improving harnesses. This is the step taken by Harness², a research framework from Google Cloud AI Research and Northwestern University, with Apache 2.0 code.

Harness² deserves a few more lines, because it changes the question. The idea is to keep the model's weights fixed and let only the scaffolding evolve. On today's task, the agent runs once and leaves a trace; then it proposes variants of its own harness, tests them against each other, and keeps the combination that performs best. It does this without an external verifier and without knowing the right answer: it compares behaviors, not results against a known solution. The second level concerns tomorrow's tasks: the lessons learned go into a second-degree harness, which the agent carries forward and uses to improve next time. Hence the exponent in the name.

In the benchmarks reported by the authors, on professional work tasks, improvements reach up to 11.8 points, with GLM-5 and Gemini 3.5 Flash as base models. The framework builds on an existing harness instead of replacing it, and every improvement cycle consumes model calls: a cost to budget for when evaluating it.

The verifier question

A harness that improves itself raises a question that didn't exist before: who decides if the change is good?

In Harness², the answer is the agent itself, which compares the variants against each other and chooses. This is the most interesting part of the work, because in the open world, where tasks arrive without an already-known answer, an external verifier often doesn't exist. Removing the verifier is what makes the method general.

In a company, the same choice has a different cost. An agent working on the ERP, on email, or on documents produces effects on real people and systems, and its account of how it went is convincing even when it's wrong. Here the verifier can't be removed: it has to be a person accountable for it, with the time and the evidence to decide.

The two positions don't contradict each other. They describe two different jobs of the harness. The first job is making the model capable, and there automatic improvement is a powerful lever. The second job is keeping the model within limits, and there the final word stays with whoever is accountable for the result. A company harness has to do both.

The harness of an AIsuru agent

An AIsuru agent is a complete harness, with the inner circle built by the people in the company and the outer circle enforced by the platform.

Piece by piece, with the name it has in the catalog:

Harness component	In AIsuru	Who writes it
Prompt	The agent's instructions: role, limits, way of answering	Whoever knows the process, no code needed
Tools	The MCP connectors from the catalog and company connectors	The administrator prepares, the author activates
Memory	Persistence, the structured memory per agent, and the Document Archive	The agent writes, people read
Skills	The procedures written once and always followed the same way	Whoever knows the work
Sub-agents	Network, Agent Link, and the team of agents created on request	The owner, from chat
Trigger	Scheduler: on schedule, on event, on request	The agent's author
Gateway	Credentials, tool-by-tool permissions, identity, rules, log	Only the administrator

On top of this harness runs the evolution cycle of the Vibe Coder, the same scheme as Harness² with one difference at its core.

The agent works, measures itself on the questions it couldn't answer and on the statistics, proposes changes to its own prompt, to the content and to the skills. At step four there's no automatic comparison between variants but the owner, who approves or discards; at step five every applied change stays logged and can be rolled back. The outer circle doesn't enter the cycle: permissions, credentials, rules and identity live in the gateway, where no proposal from the agent ever arrives.

Testing several variants before proposing them, and the boundary

There's a precise idea the two paths converge on: testing several variants on real cases before proposing them. Today the evolution cycle of an AIsuru agent presents the owner with one proposal and its reasoning. The next step, which we're working on, is to present two or three prompt variants already tested on the latest unanswered questions, with each one's outcome next to it. The owner still decides, but decides with evidence, not opinion.

The boundary stays where it is, and it needs to be stated clearly. Inside the harness that evolves are the prompt, the content, the skills and the application views: what concerns how the agent works. Outside, in the gateway, are the tool-by-tool permissions, the credentials, the company rules and the identity of whoever asks: what concerns what the agent can reach. The first half can improve on its own, under approval. The second only the administrator changes, and no automatic cycle touches it.

Can evolve, with the owner's approval	Doesn't change, lives in the gateway
The agent's prompt	The tool-by-tool permissions
The content and knowledge	The systems' credentials
The skills, i.e. the procedures	The inherited company rules
The built views and applications	The person's identity and the log

It's the same separation Harness² applies to the model's weights: keep them fixed while the scaffolding changes. We apply it to the perimeter too: keep it fixed while the agent improves.

Three harnesses compared

The differences aren't about quality but about destination: every harness is built for someone, and that someone decides everything else.

	Developer harnesses	Harness²	AIsuru
For whom	One developer at a time, in their own environment	Researchers and technical teams measuring performance	People in departments who build agents, administrators who govern them
What it optimizes	Performance and composability on code	Performance on new tasks, without a verifier	Governance of the action, with performance inside
Who decides changes	The developer, by hand	The agent, by comparing variants	The owner, who approves or discards with evidence
Identity and permissions	Those of the local user	Outside the framework's scope	Per person, per tool, with a log of every action
Memory and procedures	Context files and skills	Second-degree harness carried across tasks	Persistence and Skills, separate per agent and per company
Where it runs	Developer's terminal	Own infrastructure, with the cost of the calls	European cloud, private cloud, on-premise, even network-isolated

Under "developer harnesses" sit coding agents and the modular, open harnesses from the path described above: excellent tools for those who program, none of which is built for a hundred people with different permissions on the same systems.

The harness has two jobs

The most honest way to close is to say where we start from. The harness makes the model capable and keeps it within limits; research is making big strides on the first job, and we follow it with interest. We are built around the second, with the first inside, because that's what a company asks for when it lets an agent work on its own systems: to know who decided, with what permissions, and to be able to re-read it.

To see how the harness of an AIsuru agent is built on your own processes: demo@memori.ai, subject DEMO SUITE.

Sources