What Is an Agent Harness, and What Does Harness Engineering Do?
An agent is a model plus a harness: the prompts, rules, memory, tools and scripts around it. Where the term harness engineering comes from, the eight parts Google's Harness² paper edits, and what the practice looks like in a repository you already have.
What Is an Agent Harness, and What Does Harness Engineering Do?
Changing what surrounds the model can move results as much as changing the model. In the WorkBuddy-Bench table of a Google paper this month (Harness², arXiv:2610.14224), GLM-5 scored 64.2 under its base harness and 75.7 after one harness-improvement step, above the base-harness score of Gemini 3.5 Flash (72.4). The paper treats the harness, not the model, as the thing to optimize. This is the first post of a six-part series on that paper. It defines the term, lists what a harness is made of, and says where "harness engineering" came from.
A harness is everything except the model
Three definitions are worth holding side by side. The Harness² repository README writes: "A harness is the system around a model that enables it to act as an agent: prompts, tools, memory, skills, orchestration, and more." The paper's own text says "the system surrounding a base model that enables it to act as an autonomous agent" and cites Weng (2026) for the formula "Agent = Model + Harness". Addy Osmani's essay, republished by O'Reilly on 15 May 2026, puts it as "every piece of code, configuration, and execution logic that isn't the model itself", and credits Viv Trivedy with the one-line version, "Agent = Model + Harness".
Read together they say the same thing. A model by itself takes text in and gives text out. It becomes an agent when something gives it state, runs its tool calls, feeds results back, and enforces limits. All of that something is the harness.
The eight parts
The Harness² paper does not leave the harness as a blob. On its OpenCode substrate it lists eight editable parts: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins. Each is a file or directory in the agent's workspace. The code caps the always-on text (system prompt, guardrails, memory and tool guidance) at 24,000 characters. The cap is counted in characters, and the source gives the reason as "every token here competes with the agent's own output budget".
Below are the related posts we have written.
| Part | What it controls | Where we have covered it |
|---|---|---|
| system prompt | the instructions that are always in context | our notes on CLAUDE.md |
| guardrails | rules the agent is not allowed to cross | the AI coding rules guide |
| memory | what carries across tasks | context budget |
| tool guidance | how the tools are described | Claude Code MCP |
| skills | reusable workflows loaded on demand | Claude Code skills |
| scripts | deterministic helpers the agent runs | hooks and scripts |
| plugins | code that acts inside the tool loop | hooks and scripts |
| subagents | delegated workers in their own context | model mix |
This is a list from one paper's implementation, not a standard. Another tool may expose fewer of these as files, or more. Part 2 of this series counts, tool by tool, how many of the eight the official docs describe as open through a file or a setting.
Where "harness engineering" comes from
We checked the sources rather than repeating one. Mitchell Hashimoto's post "My AI Adoption Journey" (5 February 2026) has a section titled "Engineer the Harness", and in it he writes that he has "grown to calling this 'harness engineering.'" That is the earliest use of the exact phrase we could verify ourselves. O'Reilly's republication of Osmani's essay instead says "Viv Trivedy coined the term harness engineering", which we know only from that article; we did not open Trivedy's own posts. The Harness² paper, meanwhile, cites Weng (2026) for "Agent = Model + Harness". The records do not agree, so we do not say who coined the phrase or the formula.
What the practice is
Hashimoto uses the phrase for a concrete habit: when the agent makes a mistake, fix the environment so that mistake does not happen again, instead of hoping the next run goes better. Osmani's essay describes the same loop as treating the scaffolding "as a real artifact" that "tightens every time the agent slips", and adds that each component encodes an assumption about what the model cannot yet do alone, so a component should be removed once the model no longer needs it.
In a repository this looks like ordinary, unglamorous edits: a rule added to CLAUDE.md after an agent repeated a mistake, a git pre-push hook that blocks the push when our check that every side effect goes through one registered path fails, a skill that captures a procedure that kept being explained by hand. We do all of these here. What none of them has is a record of which evidence justified the edit, or a way to tell whether it helped.
What comes next
Harness engineering as described above is manual: a person notices the slip and edits the file. Harness² asks whether that loop can run on its own, without a correct answer to check against. Part 2 surveys which harnesses exist and how much of each can be edited. Part 3 reads the Harness² paper and runs the demo from its public repository.
Method note
- Harness definition from the repository README, eight parts from the paper: Harness²: Recursive Agent Harnessing for an Open World, arXiv:2610.14224; 24,000-character cap from the released code (
substrate/opencode.py, commit1cfe254). - Osmani definition and Trivedy attribution: O'Reilly Radar, "agent harness engineering", 15 May 2026 (read directly).
- Weng (2026) attribution: we read the citation the Harness² paper attaches to "Agent = Model + Harness"; we did not open Weng's text.
- Hashimoto: mitchellh.com/writing/my-ai-adoption-journey, 5 February 2026; the section title and the quoted sentence were read directly. We did not read the rest of the post for this article beyond that section.
- Not verified: Trivedy's original posts, Weng's original text, and any use of the phrase before 5 February 2026.