Harness Is Not a Tool — It Controls Which Paths an Agent May Take to the Outcome

Abstract

“Harness” has been stretched so wide that almost everything around an LLM now gets called one — tools, MCP, memory, context, prompts, skills, orchestration, UI. I argue that using the word that way makes us miss its engineering meaning. A harness is not a tool and it does not add capability to the model; the model already has capability, and the harness is what constrains and channels how that capability travels to the outcome. I work from the horse harness, through the split between model, tool and harness, through Mitchell Hashimoto’s and OpenAI’s work, to why a workflow and a guardrail are still not a harness. What you take away is the test that separates an instruction from a control structure the agent cannot skip.

---

🔍 Click to enlarge Click anywhere to close

Lately the words AI harness, agent harness and harness engineering have been used so often that almost everything sitting around an LLM now gets called a “harness” — tools, MCP, memory, context, prompts, skills, orchestration.

That may be convenient as an umbrella term, but it carries one danger: it makes us miss the most important engineering meaning of the word harness.

The most important thing is this:

Harness ≠ Tool
Harness ≠ adding capability to the model

A more accurate picture is:

The model already has capability → the harness constrains and channels where that capability is allowed to go, all the way to the outcome.

A harness is not there to make an agent “smarter”.

It is there so that an agent that is already capable can only move through the system in ways we accept.

1. Back to the original meaning of “harness”

The word harness existed for centuries before AI.

The simplest image is a horse harness.

A harness does not make the horse:

• run faster
• grow stronger
• see better
• get smarter

The horse already has its power.

What the harness does is control that power and transmit it in the direction we want.

The horse is perfectly capable of running left, right, forward, backward — or bolting off the road entirely.

But inside a harness, its power is fed into a system that has direction, has constraints, and has an outcome a human wants.

This is a very important metaphor for AI agents.

The model is the source of capability.

The harness is the system that controls how that capability is used.

2. Model, tool and harness are three different things

Let us pull these three apart.

Model — what it “can do”

The model itself has capabilities such as:

• reasoning
• coding
• planning
• summarization
• decision making
• understanding language

This is the model’s potential.

Tool — what opens the door to “acting”

Give the agent a browser and it can reach the web.

Give it a shell and it can execute commands.

Give it GitHub access and it can open a PR.

Give it a database connector and it can query a database.

So a tool usually expands the action surface of an agent.

Before, the agent “could think” but could not act. Now it can take far more action in the outside world.

That is capability expansion.

It is not a harness.

Harness — what defines “how it is allowed to move”

Suppose the agent can:

read code
edit code
run tests
commit
push
deploy

Handing the agent every one of those tools does not mean we have a good harness.

The agent might do:

edit
→ deploy

without testing.

Or:

edit
→ test failed
→ ignore
→ merge

Or:

guess
→ modify production

The capability is all there.

But the trajectory is uncontrolled.

A harness begins to exist when the system says:

And the important part is that the agent cannot skip a transition the system does not permit.

That is a harness.

3. A harness does not merely tell the agent what it “should do”

This is a very important distinction.

A prompt might say:

“Please run the tests before deploying.”

But the agent can still ignore it.

That is an instruction.

It is not yet a strong harness.

A real harness tries to move from:

“You should do X before Y”

to:

“Y cannot happen until X passes”

For example:

test failed
→ deploy unavailable

instead of:

test failed
→ model is reminded not to deploy

This is the difference between an instruction and a control structure.

A good harness does not just hope the agent “remembers the rule”.

It designs the environment so that the wrong path is hard to walk, or impossible to walk.

4. The agent may think freely, but it cannot act freely

This may be the single sentence that sums a harness up best:

The agent may reason over many possible paths, but the harness controls which paths can become actions.

The model may propose a hundred different solutions.

There is no need to constrain all of its reasoning.

What the harness controls is the transition from

reasoning → action → state change

For instance, the agent may think of:

A. patch code
B. delete table
C. bypass test
D. migrate schema
E. ask human

But the harness may open only these real paths:

A → test → review → merge
D → dry-run → validation → approval → migrate
E → human escalation

B and C have no executable transition.

That is control.

5. Mitchell Hashimoto and “harness engineering”

On 5 February 2026, Mitchell Hashimoto published My AI Adoption Journey, which contains an important section called “Step 5: Engineer the Harness.”

Hashimoto does not claim to have coined the word harness, and does not claim to have invented the idea of an agent harness.

What he says carefully is that he does not yet know whether the field has a standard term, but he has started calling this way of thinking “harness engineering.”

The substance of his idea matters a great deal:

When the agent gets something wrong, do not stop at

“Next time, remember not to do that.”

Ask instead:

How can we change the system so that this same mistake cannot happen again?

If the agent keeps using the wrong command
→ encode that knowledge into the environment.

If the agent cannot tell that a result is wrong
→ build feedback that tells it quickly.

Those first two are his, and the forms he offers for them are concrete: better implicit prompting — an AGENTS.md that sits implicitly in the agent’s context — and tools that are actually programmed for the job, such as screenshot scripts and filtered test commands. His point about verification is a point about feedback: give an agent a way to verify its own work and it will more often than not fix its own mistakes and prevent regressions. He does not ask for a blocking gate.

The step this article adds is the one after his:

If the agent can skip validation
→ turn that verification from advice into a gate.

Hashimoto describes harness engineering as taking each individual mistake the agent makes and building a system that prevents that class of mistake in the future.

This is not just prompt engineering.

In this article’s terms, that is environment engineering + feedback engineering + control engineering — the third of those three being this article’s own addition, not his.

6. A tool can be “part of” a harness, but a tool is not a harness

This is where most of the confusion lives.

Suppose we add a screenshot tool to the agent.

If the reason is:

“Now the agent can see the UI.”

then we have added capability.

But if we use that screenshot tool inside a loop:

implement UI
 ↓
capture screenshot
 ↓
visual evaluator
 ↓
does it satisfy acceptance criteria?
 ├─ No → revise
 └─ Yes → continue

then the screenshot and the evaluator are now doing work inside the harness.

So the more precise way to put it is:

A tool can participate in a harness.
But a tool is not a harness merely because the agent can use it.

The difference lies in the role it plays in the control loop.

Not in the name of the technology.

7. OpenAI also points at control, not just “having tools”

On 11 February 2026, OpenAI published Harness engineering: leveraging Codex in an agent-first world.

The interesting finding is that early progress was slower than the team expected — and the problem was not that Codex was incapable, but that the environment was still underspecified.

The engineer’s job therefore shifts from writing the implementation to building environments, feedback loops, constraints and the structure that lets an agent work reliably.

One of the most important examples is the architecture of the codebase itself.

OpenAI has not abandoned documentation — quite the opposite. They treat a short AGENTS.md of roughly a hundred lines — injected into the agent’s context — as the codebase’s table of contents rather than its encyclopedia, with the deeper sources of truth in design documentation that is catalogued and indexed, and kept in order by an agent whose job is doc gardening.

What the linters replace is documentation as the enforcement mechanism for layer boundaries. Instead of leaving the layering rule to prose the agent is merely asked to follow — a line I am inventing here for illustration, which would read something like:

Please do not import across layers.

they enforce it mechanically, with custom linters and structural tests that allow only the permitted dependency directions.

Put another way, it is not:

Agent, please follow this architecture.

but:

These edges are permitted.
Everything else is mechanically rejected.

OpenAI states plainly that the architecture is built with fixed layers and a limited set of permissible edges, and that these constraints are enforced by systems.

That is harness thinking in its truest form.

8. A workflow is still not a harness

Another word that gets mixed in is workflow.

A workflow says:

A → B → C → D

But a harness asks the follow-up question:

What happens if the agent tries to go from A → D?

If the answer is

“We hope it won’t.”

then we have a workflow.

But not yet enough control.

If the answer is

“The transition A → D does not exist in the system.”

then we are much closer to a harness.

So:

Workflow describes the intended path.
Harness governs the allowable paths.

The two can live together, but they are not the same thing.

9. A guardrail is not the whole harness either

A guardrail is a single constraint.

For example:

no production deploy without approval

A harness is a bigger system than that:

state
→ permitted actions
→ execution
→ observation
→ evaluation
→ state transition
→ recovery
→ escalation
→ outcome

So a guardrail may be a component of a harness.

And so may:

• evaluator
• state machine
• test
• permission boundary
• approval gate
• feedback loop
• rollback
• retry rule
• invariant
• escalation condition

But any one of them on its own is not necessarily the whole harness.

10. Why people are starting to get “harness” wrong

The trouble starts when the definition is stretched until it becomes:

“Everything that is not the model is the harness.”

That definition is useful when talking about architecture in broad strokes, but if it is used in every engineering conversation, the word harness starts to lose its meaning.

If:

• tool = harness
• memory = harness
• prompt = harness
• MCP = harness
• context = harness
• skill = harness
• orchestration = harness
• UI = harness

then in the end harness means only:

“everything around the model.”

Which does not help answer the engineering questions that matter more:

What is controlling the agent?

What makes it unable to skip a step?

What decides a state transition?

What sends a failure back into a correction loop?

What turns a forbidden path into an impossible path?

What makes the outcome we want a terminal state the agent can reach reliably?

Those are the harness questions.

11. A good harness does not reduce intelligence — it removes unnecessary degrees of freedom

Some people assume that constraining an agent too much destroys its ability.

But a good harness does not need to micromanage every action.

On the contrary, the better principle is:

Constrain invariants, not implementations.

Define what must never be violated.

Then let the agent choose its own way of solving the problem inside that safe space.

For example:

You may implement this feature however you want.

But:

- tests must pass
- architecture boundaries cannot be violated
- no schema migration without validation
- security checks must pass
- acceptance criteria must be demonstrated

Inside that frame, the agent still has a great deal of autonomy.

A harness is not there to turn the agent into a deterministic script.

It is there so that:

Autonomy exists inside controlled boundaries.

12. The way I think about a harness

I look at an agent system through four layers. MODEL — what can it understand and reason about? TOOLS — what actions can it perform? HARNESS — which actions are permitted, in which state, under which conditions, with what verification, and what happens next? OUTCOME — what observable state counts as success?

And the harness itself can be thought of as a state machine: a current state opens a set of allowed actions, an action is taken, the result is observed and evaluated, a pass moves to the next state, a failure goes into repair or retry and comes back around, and the loop ends at the outcome.

That makes the definition of a harness sharp immediately.

13. The one sentence to remember

If you remember only one sentence from this whole article, remember this:

Tools determine what an agent can do.
A harness determines how the agent is allowed to get to the outcome.

Or, in my original Thai:

Tool เพิ่มสิ่งที่ Agent ทำได้
Harness ควบคุมว่า Agent จะใช้สิ่งที่ทำได้นั้น เดินไปถึง Outcome ผ่านทางไหนได้บ้าง

And the best harness does not try to tell the agent what to do every second.

It designs the agent’s world until:

The right path is the path that can be walked.
The wrong path is blocked, redirected, corrected or escalated.
And the agent cannot declare success until a verifiable outcome has actually occurred.

That is why the word harness means something.

Not because it makes AI more powerful.

But because it lets us control the power AI already has, so that it reaches the result we want, reliably.

That is Harness Engineering.

References

1. Mitchell Hashimoto, “My AI Adoption Journey” — see the section “Step 5: Engineer the Harness”. 5 February 2026. mitchellh.com/writing/my-ai-adoption-journey
2. OpenAI (Ryan Lopopolo), “Harness engineering: leveraging Codex in an agent-first world”. 11 February 2026. openai.com/index/harness-engineering