What It Is

Terminology · Source Verification · LLM Engineering · Language Models · AI · ExplainerTratopedia · 15 Aug 2026

The coinage, and the redefinition that swallowed it Thirty-three days apart. Everything after the second one restates it.

• 33days from the phrase being coined for a habit to it meaning everything around the model
• 2separate contributions — one the name, one the definition — mistaken for one dispute over credit
• 1comparison found that holds the model fixed and changes only the harness
• 0sources that reconcile the one disagreement left: whether this contains context engineering or sits inside it

• Mitchell Hashimoto · 5 Feb 2026

  “I've grown to calling this harness engineering”

  The coinage, and how small it was.

  • The whole of it: anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.
  • It comes in two forms, and that is the entire scope: an AGENTS.md where each line in that file is based on a bad agent behavior, and “actual, programmed tools” — scripts for screenshots and filtered tests. No sandbox, no orchestration, no runtime substrate.
  • He is reluctant about it: I don't need to invent any new terms here; if another one exists, I'll jump on the bandwagon. Nobody told him one would arrive in five weeks and take the word with it.

• Vivek Trivedy · LangChain · 10 Mar 2026

  Agent = Model + Harness

  Thirty-three days later, and far larger.

  • His gloss: if you're not the model, you're the harness. Every piece of code, configuration and execution logic that is not the model itself — filesystem, sandbox, browser, orchestration, hooks.
  • He is careful that this is a choice, not a fact: there are many messy ways to split the boundaries… but in my opinion this is the cleanest.
  • Every definition after this one restates it, and none restates Hashimoto's. The drift is all in those 33 days.

• Wikipedia · last edited 13 Aug 2026

  “The software infrastructure surrounding a model”

  An encyclopaedia entry, five months after the name.

  • In full: what “manages tool use, memory, state persistence, execution environments and feedback loops, as opposed to the model's own reasoning.”
  • Context engineering, more than a year older, still has no article of its own — it is a paragraph inside another entry.
  • It also mis-dates one of its own sources by a year. See section three.

• Zhong & Zhu · arXiv · 13 May 2026

  “A runtime substrate”

  The same thing, written as a research programme.

  • Their opening move: the dominant explanation locates this gap in model capability. We propose a different locus.
  • Eleven component responsibilities and a four-level ladder, H0 to H3. Three of the eleven — failure attribution, entropy auditing, intervention recording — exist to judge a run afterwards rather than to make it work.
  • Only the abstract was read here, so nothing on this page reports a result from the paper.

How firm is each of these? What was read, what is still missing, and what this page got wrong the first time.

Timeline

The practice, then the word, then the encyclopaedia Nine months from a full published method to a Wikipedia entry.

1. Oct 2022The loop, as a paper. Yao and colleagues publish ReAct, which has a model alternate between reasoning and acting. Every harness since runs that cycle: the model reasons, the harness acts and captures what happened, the model reads the result.
2. Feb 2023Tools, as a paper. Toolformer shows a model can teach itself to call external tools. Wikipedia names it, with ReAct, as the mechanism that predates the term.
3. Dec 2024The idea, without the word. Anthropic argues the agent–computer interface deserves as much investment as the human–computer interface, and that a tool definition should be shaped so the model cannot easily use it wrongly.
4. 26 Nov 2025The whole practice, published. Anthropic's Justin Young writes up long-running agent harnesses: an initializer agent that lays down init.sh, a progress file and a first commit; a coding agent that does one feature per session and leaves the repository clean. The feature list is JSON rather than Markdown because the model is less likely to overwrite it. The word “harness” appears throughout as an ordinary noun. Nobody has named the discipline yet.
5. 23 Jan 2026The noun is already ordinary at a second lab — and it needs no defence. OpenAI's Michael Bolin, writing up how the Codex agent loop works, offers the word in passing: we hope this post gives you a good view into the role our agent (or “harness”) plays in making use of an LLM. A parenthesis, as the plainer of two names for the same thing — two weeks before anyone named the discipline.
6. 4 Feb 2026And by now, no gloss at all. OpenAI's Celia Chen writes that the web app, the CLI, the IDE extension and the macOS app are “all powered by the same Codex harness—the agent loop and logic that underlies all Codex experiences.” The parenthesis is gone. It is simply the word for that thing.
7. 5 Feb 2026The phrase is coined, one day later, by someone who did not want to coin it. Mitchell Hashimoto, writing up his own adoption of AI tooling, reaches step five — Engineer the Harness — and needs a word: I don't know if there is a broad industry-accepted term for this yet, but I've grown to calling this “harness engineering.” He adds: I don't need to invent any new terms here; if another one exists, I'll jump on the bandwagon. What he means by it is an AGENTS.md and a few scripts — every line in the file earned by a bad agent behaviour he has actually seen.
8. 10 Mar 2026The word is taken, and made enormous. Vivek Trivedy of LangChain publishes The Anatomy of an Agent Harness, defines Agent = Model + Harness, and derives each component backwards from a behaviour: filesystems for durable state, bash for autonomy without pre-built tools, sandboxes for somewhere safe to act. Thirty-three days after the coinage, the same phrase now covers everything that is not the model. This is the post every later source cites, and the definition none of them changes.
9. 2 Apr 2026The user's side gets a shape. Birgitta Böckeler of Thoughtworks splits the harness into guides that steer before the agent acts and sensors that observe after, each either computational or inferential. In a sidebar she writes the sentence that puts her at odds with everyone else: a user harness is a specific form of context engineering.
10. 13 May 2026It becomes a research programme. Hailin Zhong and Shengxin Zhu post a sixteen-page formalisation to arXiv: eleven component responsibilities, a four-level ladder from H0 to H3, and a proposal to judge an agent run by the evidence it leaves rather than by whether a patch appeared.
11. 15 May 2026The practice gets its one-line rule. Addy Osmani, on O'Reilly Radar: anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again. He credits Trivedy with the coinage.
12. 17 Jun 2026A vendor draws the boundary. Databricks publishes an explainer with eight building blocks, seven failure modes, and a table placing the three disciplines in a hierarchy: prompt and context engineering both live inside harness engineering.
13. 13 Aug 2026The encyclopaedia catches up — five months after the naming. Wikipedia's Agent harness article is last edited, with a section conceding that nobody is sure who named it, and a citation that dates Anthropic's November 2025 post to 2026.

The Argument

Who named it, and one disagreement still open The credit question has an answer. The boundary question does not.

What Others Add

What you actually build Böckeler gives the shape; Anthropic gives the worked example.

1. 1Put guides in front of the agentFeedforward controls: instruction files, skills, code mods, a bootstrap script. They anticipate the behaviour you do not want and steer before the agent acts. A harness with only these never finds out whether its rules worked.
2. 2Put sensors behind itFeedback controls: tests, linters, type checkers, a reviewing agent. Böckeler's sharpest point is that a sensor should write for its reader — a linter message that tells the model how to fix the thing is a positive kind of prompt injection. A harness with only these repeats its mistakes.
3. 3Know which of the two kinds you are usingComputational controls are deterministic and fast — tests, linters, structural analysis, milliseconds to seconds, reliable. Inferential ones are semantic — AI review, “LLM as judge” — slower, dearer and non-deterministic. Cheap computational sensors can run on every change; inferential ones have to earn their place.
4. 4Write the state down where the model will not eat itAnthropic's worked example is the most concrete advice found anywhere: a feature list of 200-plus end-to-end descriptions, all starting as failing, that agents may edit only by flipping a passes field. It is JSON rather than Markdown because the model is measurably less likely to overwrite JSON. Plus a progress file and a git commit at the end of every session.
5. 5Ratchet every mistake into a ruleHashimoto's rule — the sentence the term was coined for, and the closest thing this field has to a method: treat mistakes as permanent signals, not bad runs to retry. Each earns a line in the instruction file, a check in the pre-commit hook, a flag in the reviewing agent. You only add a constraint once you have seen a real failure — which keeps the harness from growing rules nobody needed.

Does any of it work? The evidence, graded Two of these hold the model still. One does not.

Conclusion

What to take from this Five things, in the order they matter.