What is harness engineering, and when does it matter to a business?

Where the term came from, and how settled it is

The name spread in early 2026. In February, Mitchell Hashimoto, a co-founder of HashiCorp, described the practice of engineering a fix every time an agent makes a mistake so that the mistake never comes back, and wrote that he did not know of an industry-accepted term yet but had come to call it harness engineering.

Around the same time, an OpenAI team published a report under the same name on building a product with Codex, and Birgitta Böckeler, of Thoughtworks, organized the idea in an article on Martin Fowler's site. There, the harness is everything in an agent except the model: agent = model + harness.

It is practitioner jargon, not a standard: there is no specification or official definition, and Böckeler herself notes that the term means different things in different contexts. The idea behind it, however, is stable and can be checked in the repository.

What a harness is made of

Tools such as Claude Code and Codex ship with a built-in harness: the loop, file and terminal tools, permissions and context management. The Claude Code documentation calls this layer around the model the agentic harness. Harness engineering, as the term is used in 2026, is mostly what the team builds on top of it, in its own repository.

Guides and sensors come from Böckeler's article, which also separates deterministic controls, such as tests and linters, from inferential ones, such as AI review, which are slower, more expensive and less predictable.

Harness, context engineering and the agent loop: the difference

The three terms overlap, and each author draws the line in a different place. A practical way to tell them apart is by the question each one answers.

In Böckeler's reading, building a harness for a coding agent is a specific form of context engineering: guides and sensors only work if they reach the agent's context at the right time. Designing the loops got a name of its own in mid-2026, loop engineering, and has a guide of its own.

When harness engineering matters to a business

The harness starts to matter when the agent stops being one person's experiment and becomes part of the team's work. The usual signs:

• The same mistake returns: The agent repeats the wrong command or the old API because the fix stayed in the chat, not in the repository.
• Repetitive reviews: Whoever reviews the agent's pull requests keeps pointing out the same problems.
• The agent acts on systems: It opens tickets, changes data or deploys, and someone needs to know what it may and may not do.
• Security questions: Someone has to answer what the agent can read, run and send outside.
• Changing models or tools: The team wants to switch agents without losing the rules, which therefore have to live in versioned files.

For occasional use, such as asking for a function or an explanation of some code, the tool's built-in harness is enough. On the program we work on for The Hackett Group, the operating model uses 12 agents, 25 skills and quality-gate hooks.

Risks and limits of a harness

A harness is also software, and it ages like software. The problems show up when it grows without an owner.

• Contradicting rules: Guides and sensors added at different times start pointing in opposite directions, and the agent picks one.
• False confidence: A sensor that never fires may mean good code or a weak check; without measuring, there is no way to tell.
• Cost and time: AI-based checks are slower and more expensive than tests; they complement tests and do not replace them.
• Too much permission: Hooks and skills can grant tools without approval, and a harness with broad access turns an agent's mistake into an incident.
• Vendor lock-in: Rules kept in a single tool's format make switching hard; Markdown, scripts and AGENTS.md in the repository travel better.

Böckeler sums up the goal this way: a good harness does not aim to eliminate human input but to direct it to where it matters most.