What Is Harness Engineering? Guides, Sensors, Project Context

Published August 10, 2026 · Archcore team

Harness engineering is the practice of designing everything around an AI coding agent except the model itself: the tools it can call, the guidance it receives before it acts, and the checks that verify what it produced. The term was named and systematized in early 2026, and the shorthand that made it stick is Mitchell Hashimoto’s formula, Agent = Model + Harness.

The point of the discipline is simple. You cannot retrain the model, but you can change almost everything else about the conditions it works under, and those conditions decide whether an agent is useful on real work or merely impressive in a demo.

What is in a harness?

The clearest taxonomy comes from Birgitta Böckeler, writing on martinfowler.com. It splits the harness into two kinds of control:

• Guides are feedforward controls. They steer the agent before it acts: the instructions it starts with, the constraints it is told to respect, the documents describing how this system is built.
• Sensors are feedback controls. They observe after the agent acts, so problems get caught before a human sees them.

Each kind works in two modes. Computational controls are deterministic: linters, type checkers, tests, schema validation. Inferential controls are semantic: an LLM reviewing a diff, a judge scoring an output, a check on whether a change matches the decision it claims to implement.

A useful way to read your own setup is to sort it into that grid. Most teams discover they have plenty of computational sensors (CI has run tests for years) and almost no guides beyond a single instruction file.

How does harness engineering relate to prompt engineering and context engineering?

These three are often presented as a progression, where each supersedes the last. That is not what the source material says, and the distinction matters if you are deciding where to spend effort.

Böckeler is explicit that context engineering provides the means to make guides and sensors available to the agent, and that engineering a harness for a coding agent is a specific form of context engineering. The two are nested, not sequential. Prompt engineering is the narrowest of the three: still useful, but it operates on one turn while the other two operate on the system.

What about loop engineering?

Loop engineering is the design of the agent’s cycle itself: reason, act, observe, repeat, until a goal is met or a budget runs out. It covers how many iterations to allow, when to stop, when to escalate to a human, and how cost is bounded.

It is a neighbouring discipline, not the same one. The loop is the engine; the harness is what the engine runs against. In practice you rarely build the loop yourself, because Claude Code, Codex CLI, Cursor and the others ship one. What you do build is what each turn of that loop reads before acting and writes back after.

Which half of the harness is actually yours?

Your coding agent already ships a harness. Claude Code has file and shell tools, a multi step loop, and permission prompts before risky actions. That default is what makes it an agent rather than a chatbot, and you did not have to build any of it.

What it cannot ship is anything about your project, because it has never seen your repository. That leaves a specific, bounded list on your side:

• The architecture your code actually follows, as opposed to the one the model infers from file names.
• The decisions already settled, so the agent stops reopening them.
• The rules your team enforces, scoped to the directories where they apply.
• The specs your boundaries must hold, so a change to an API is measured against a contract instead of a guess.
• The plans in flight, so a new session can continue work instead of restarting it.

Those are guides in Böckeler’s sense: feedforward controls, delivered before the agent edits. The same documents double as sensor criteria, because “does this change respect the decisions on record” is only answerable if the decisions are on record.

How do you build the project half?

Two properties decide whether the project half of a harness holds up over time.

It has to be structured. A single instruction file is a guide, technically, and it works until it becomes a wall of text with no way to say which rule governs which directory or which decision superseded which. Typed documents with relations, status, and history scale where flat files stop. This is the same argument as structured project context versus flat instruction files.

It has to live in the repository. A guide stored in a vendor’s cloud cannot be reviewed in a pull request, cannot be versioned alongside the code it constrains, and does not travel when your team switches agents. Keeping the harness in git makes it reviewable, portable, and owned by the team rather than by whichever tool happened to write it.

This is what Archcore is built for, and yes, it is our tool. Specs, architecture, decisions, rules, and plans live as typed Markdown in a .archcore/ directory, versioned with the code. Session hooks inject the applicable guides when the agent edits a file, so guidance arrives at the moment of the edit rather than at the top of a long prompt. The CLI serves them to any MCP aware agent, and the plugin adds review that checks a branch against the decisions it claims to follow, which is the inferential sensor half of the same taxonomy.

The model is not yours to change. The project half of the harness is, and it is the half that knows what your system is.