An AI harness is all the software infrastructure around a language model — connected tools, execution rules, persistent memory, quality gates, and observability — that turns an LLM into an agent capable of doing real work reliably. The discipline was named by Mitchell Hashimoto, co-founder of HashiCorp and creator of Terraform, in February 2026: harness engineering. The formula that captures the category, Agent = Model + Harness, comes from LangChain. The model is the brain; the harness is everything else — and in production, the harness is what determines performance.
An AI harness isn't harness.io (nor a car's wiring harness)
The name collides. "Harness" carries other meanings that surface in the same search — worth separating the three before moving on:
| Term | What it is |
|---|---|
| harness.io | A CI/CD and DevOps platform (software delivery). It ranks well on Google for "harness" but has nothing to do with the concept in this guide. |
| harness (literal) | The everyday English sense: a horse's harness, or the safety harness used in climbing and in a car. |
| AI harness (this guide) | The software infrastructure around an LLM that turns it into a reliable agent — the sense covered here. |
Want the engineering discipline behind this? See harness engineering.
You used to be the harness
Before agentic tools, the harness was you: copy the error from the terminal, paste it into the chat, copy the answer, paste it into the editor, run it again. That manual loop — feeding context, executing actions, verifying results — is exactly what a harness automates. When Claude Code reads your repository, edits files, runs tests and iterates on its own, what changed wasn't the model: it was the harness around it. That's why the same question, asked in a browser chat and in a harnessed agent, produces such different results.
The equation that defines the category
The formula came from LangChain: Agent = Model + Harness. Hashimoto named the discipline harness engineering (Feb 2026). Birgitta Böckeler (Thoughtworks), published on Martin Fowler's site, expanded it with the guides and sensors taxonomy — guides are the rules that direct the agent (what to do, what not to do); sensors are the mechanisms that detect when something goes off the rails (Apr 2026, martinfowler.com). Every robust harness combines both: direction without detection is faith; detection without direction is noise.
What is a harness made of?
| Component | What it does | Concrete example |
|---|---|---|
| Connected tools | The agent acts on the world (files, browser, APIs) instead of just answering | MCP (Model Context Protocol, an open standard under the Linux Foundation) |
| Persistent memory | Context survives the end of the session | Working memory + project state in versioned files |
| Guides (rules) | Direct behavior before the action | Operating rules, approval protocols, mandatory specs |
| Sensors (gates) | Detect deviation after the action | Numeric quality gates: minimum coverage, zero new warnings |
| Orchestration | Sequences work into phases and delegates to subagents | A state machine with blocking phases |
| Observability | Makes behavior auditable | Per-phase artifacts: spec, plan, quality report |
Why does the harness matter more than the model?
Three public pieces of evidence. (1) LangChain showed on Terminal Bench 2.0 that the same model scores materially differently depending on the harness — and reports going from top 30 to top 5 on the benchmark by changing only the harness, not the model (Feb 17, 2026). (2) Deloitte reports 88% of companies use AI but only 29% get real ROI — the gap isn't access to models, it's the system around them. (3) The labs themselves confirm the thesis: agents like Claude Code and Codex are post-trained WITH their harnesses in the loop — model and harness co-evolve.
Development harness vs. operational harness
Two scopes of the same pattern. A development harness disciplines agents that write code: spec before code, plan before implementation, gates before merge — the problem capivaOS solves for Claude Code (open-source, MIT, 2-command plugin). An operational harness is the system that runs an entire business on agents — knowledge, memory, automation, governance — described in detail in AI Harness in Practice, the account of how Capiva runs its own operation on this pattern every day.
How do you get started with a harness?
For software development, the entry point is free: install capivaOS in your repository (/plugin marketplace add iB2/capivaOS → /capiva:init) and your first task enters a pipeline with phases and gates. For the operational harness — the one that runs a company's processes and knowledge — the path is in the practice article and Capiva's strategic diagnosis.
Frequently asked questions
What is an AI harness?
It's the software infrastructure around a language model that turns it into an agent: connected tools (MCP), persistent memory, guides (rules), sensors (verification) and orchestration. The term was popularized by Mitchell Hashimoto (Feb 2026), who named the discipline harness engineering; the formula Agent = Model + Harness comes from LangChain. In production, the harness determines performance, not the model.
What's the difference between a harness and an agent framework?
A framework is a library for building agents (you write the loop's code); a harness is the complete execution environment around the agent — runtime, rules, gates and memory —, whether bought (Claude Code, Codex) or assembled on an existing runtime. In practice: Claude Code is a ready-made harness; capivaOS is installed on top of it; LangChain is a framework.
Is a harness the same as RAG or context engineering?
No: those are subcomponents. RAG and context engineering solve WHAT the model sees (context retrieval and curation); the harness includes that AND what the model can do (tools), what it is forced to comply with (gates) and what persists across sessions (memory). Context engineering is a discipline inside the harness, not a synonym.
Why does the harness matter more than the model?
Because the same model produces different results in different harnesses: LangChain documented on Terminal Bench 2.0 that changing only the harness took it from top 30 to top 5, without changing the model (Feb 17, 2026). Models are a commodity; the harness is where the operational advantage lives — that's why labs post-train agents with the harness in the loop.
What is harness engineering?
The discipline of designing this infrastructure, named by Mitchell Hashimoto (Feb 2026): the guides and sensors taxonomy comes from Birgitta Böckeler (Thoughtworks), on Martin Fowler's site; the formula Agent = Model + Harness, from LangChain. It involves rules that direct the agent, gates that detect deviations, memory that preserves context, and feedback loops that convert error into rule.
What are examples of AI harnesses?
Complete runtimes: Claude Code, Codex — each is a ready-made harness around a model. Development harness: capivaOS (open-source, MIT), which enforces a spec → plan → implement → verify pipeline on Claude Code with mechanical gates. Operational harness: systems like the one described in "AI Harness in Practice" — agents, knowledge and automation running a business.
How do I build a harness for my company?
Start with the pattern, not the tool: connect tools via an open standard (MCP); structure knowledge in versioned documents any agent can read; write guides (rules) and sensors (verifiable gates); add memory across sessions; convert every error into a rule. For development there's a free shortcut (capivaOS); the operational harness is designed on your own tool stack.
What is MCP (Model Context Protocol)?
MCP is the open standard, maintained under the Linux Foundation, that connects an agent to external tools — files, APIs, databases — without requiring proprietary integration for each one. It's the connected-tools piece in the table above: without MCP, the model only replies in text; with it, the harness gives the agent a way to act in the real world.
What's the difference between guides and sensors in a harness?
Guides are rules that direct the agent before it acts — what to do, what to avoid, approval protocols. Sensors are gates that detect after the fact whether something went off track — minimum coverage, zero new warnings. Böckeler (Thoughtworks) named the pair: direction without detection is faith; detection without direction is just late noise.
What is a quality gate inside a harness?
It's a mechanical sensor, not an opinion: a numeric criterion that blocks the agent's progress if it isn't met — minimum test coverage, zero new warnings, a mandatory verification phase before merge. The gate exists so a deviation gets caught by the system, not discovered late by a human reviewing the final result.
Does a harness depend on one specific model to work?
No: the harness is the layer that sits around the model, so it works with any LLM compatible with the expected interface. That's why the equation Agent = Model + Harness keeps the two separate — swapping the model inside a well-designed harness doesn't require rewriting the guides, sensors, or orchestration underneath it.
Is capivaOS the same thing as a harness?
Not exactly: capivaOS is one specific development harness, open-source under the MIT license, installed as a two-command plugin on top of Claude Code. It enforces the spec, plan, implement, verify pipeline with mechanical gates. Harness is the category; capivaOS is one concrete implementation of it, focused on writing code for a repository.
What role does persistent memory play in a harness?
Memory is what lets context survive past the end of a session: without it, every conversation restarts from zero and the agent repeats questions already answered. In a harness, persistent memory usually lives in versioned files — working memory, project state — so the next agent, or the next session, inherits what was already decided.
Who coined the term harness engineering?
Mitchell Hashimoto, co-founder of HashiCorp and creator of Terraform, named the discipline harness engineering in February 2026. The internal taxonomy, guides and sensors, came later, from Birgitta Böckeler (Thoughtworks), published on Martin Fowler's site; the formula Agent = Model + Harness that sums up the category is credited to LangChain.
Does harness engineering replace prompt engineering?
It doesn't replace it, it encloses it: prompt engineering tunes the text that instructs the model in a single call. Harness engineering designs the whole system around it — tools, memory, guides, sensors, orchestration — that repeats on every call. A great prompt inside a weak harness still fails; the harness is the layer that holds up the final result.
How does orchestration differ from a single agent running alone?
A lone agent runs one loop: receive instruction, act, reply. Orchestration sequences work into blocking phases and delegates parts to specialized subagents, each with its own scope and exit gate. It's the difference between one person doing everything and a coordinated team — the harness is what enforces all that coordination.
You rent the model. You build the harness — and it stays.
Does your site show up in AI answers? Run the free diagnostic →