Primer
What Is an Agent Harness?
Last updated: October 19, 2026
A model does not become an agent on its own. The harness around it decides what it can see, what it can do, and how it recovers when a step goes wrong.
The model is not the agent
In the framing used by Harness², an agent is a model plus a harness. The model supplies capabilities learned from its training. The harness supplies the working system around it: instructions, tools, memory, skills, delegation and middleware. Change the harness and you change the agent, even if the model weights never move.
This is why benchmark scores measure a system, not a model in isolation. Two runs with the same model and different harnesses are not the same experiment.
Model, harness, framework, agent
The four words are related, but they are not interchangeable.
| Term | What it refers to | What it is not |
|---|---|---|
| Model | The weights and inference behavior that produce tokens. | Not the tools, memory or procedure around it. |
| Harness | The system around the model that enables it to act as an agent: prompts, tools, memory, skills, orchestration and more. | Not the model weights, and not a benchmark score. |
| Framework | Software abstractions you use to build and run a harness, such as model/tool integrations or orchestration APIs. | Not the harness itself, and not an optimizer by default. |
| Agent | The operating combination of a model and a harness. | Not a property of the model alone. |
Harness² adds a fifth role: an optimizer of harnesses. It is not a model and not a general agent framework. It edits the harness while the model stays fixed.
The eight components that decide behavior
Component guide →Harness² exposes eight editable components. They are not all prompts; they cover context, tools, delegation and middleware.
System prompt
Context constructionThe agent's persona and top-level procedure — how the executor approaches a task before any individual tool is called.
Guardrails
Context constructionConstraints and checks on what the agent may do, and what it must verify before delivering.
Memory
Context constructionWhat the agent carries forward or retrieves across steps and tasks, as opposed to what is recomputed each time.
Tool guidance
Tool interfaceHow tools are described to the model, when each should be used, and what good input looks like.
Subagents
OrchestrationHow work is split and delegated to specialized or parallel agents.
Skills
Context constructionReusable procedures the agent can load for a class of tasks instead of rebuilding the method each time.
Scripts
Tool interfaceExecutable helpers that make deterministic operations repeatable instead of asking the model to perform them by reasoning.
Plugins
MiddlewareMiddleware that runs inside the tool loop and changes behavior across tools rather than one prompt.
Why the same model scores differently
A benchmark does not hand the model a bare question. It hands the agent a working environment: a procedure, tools, prior context, and constraints. Those choices determine whether the model notices a source file, verifies a calculation, reopens its own output, or delegates a separable subtask.
That is the practical meaning of harness performance. The model's capability is necessary but not sufficient; the harness decides how much of that capability reaches the task. The reported Harness² results are evidence for this claim: the model weights stay fixed, the harness changes, and the benchmark score moves.
Harness² as a case study
Harness² turns harness editing into two connected loops. At the task level, a contrastive Propose–Probe–Compose step proposes edits, runs candidate harnesses on the same task, and composes a refined harness from behavioral contrasts — without ground-truth feedback. At the harnessing level, the adopted harness and evidence-supported lessons are retained in a persistent improvement harness for future tasks.
The framework is explicit about what stays fixed: model weights. Across three professional benchmarks and four model–harness configurations, the README reports that a single step improved GLM-5 and Gemini 3.5 Flash over their base harnesses, with gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB's partial pass rate. Those are relative gains, not absolute scores.
A checklist for reading harness claims
- What changed? A prompt, a tool interface, memory, delegation, middleware — or several at once?
- What stayed fixed? Model weights, model version, executor and judge should be explicit.
- Relative to what? A gain over a base harness is not an absolute score, and "up to" is not an average.
- Was a verifier available? Ground-truth feedback and a rubric-free open-world task are different settings.
- Could the model see the answers? Public benchmarks and unrestricted executor networks make this a real question.