Harness Engineering: The Term That Took Six Months to Become a Discipline

This is the centerpiece of the series, because it is the centerpiece of how I think about where the field is going.

The day before my London talk, I was preparing slides on a question that kept catching me: why did the term "harness engineering" stick so fast? Mitchell Hashimoto posted the framing on February 5, 2026 — a blog post on his personal site, not a major venue, not a corporate launch. Within weeks, OpenAI was using the vocabulary. Anthropic was using it. LangChain was using it. By March, Birgitta Böckeler had published a guides-and-sensors taxonomy on martinfowler.com that became the field's reference text. By April, Faros AI, Software Improvement Group, Milvus, Epsilla, and a dozen other engineering blogs had taken positions on it.

That kind of vocabulary spread doesn't happen because a term is clever. It happens because the term named something everyone was already building without a word for it.

That something is what I want to spend this post on, because it is the operating model that defines what enterprise AI actually looks like in the next two years.

The formula

Here is the framing, in Mitchell's words: Agent = Model + Harness.

The model is the part you mostly can't change. You pick Claude or GPT or Gemini or an open model. You write to its capabilities. You wait for the next version.

The harness is everything else. The tools the agent can call. The instructions in its system prompt. The verification loops that check its work. The memory that survives across runs. The observability that tells you what it actually did. The guardrails that stop it doing things you didn't authorize.

The model is bounded by training. The harness is bounded by your engineering.

Why the framing took

For two years, the discourse around AI agents oscillated between two extremes. On one end, people who said "agents are amazing — look what they can do." On the other end, people who said "agents are unreliable — they hallucinate, they fail, they're not production-ready."

Both were right. Both were missing the same thing: the gap between those two truths is engineering work. A bare model is not production-ready. A model with the right harness, on a constrained workflow, is.

Mitchell named the gap. Once it had a name, you could talk about it as a discipline rather than a complaint. "We need better prompts" became "we need better harness engineering." That's a conversation that can fund a team, get a roadmap, ship a system.

The Birgitta Böckeler taxonomy then gave the field its vocabulary for the components of a harness. Guides are the things that constrain the agent's action space before it acts — instructions, tool descriptions, schemas, examples. Sensors are the things that catch the agent's mistakes after it acts — tests, evals, validators, human reviewers. Most production harnesses need both.

The five layers, in practice

Faros AI's piece on harness engineering decomposes a production harness into five layers. I'd nuance two of them slightly, but the decomposition is right:

1. Tool orchestration. Which tools the agent can call, in what order, with what argument validation. This is where MCP lives. This is where most of the action sits.

2. Verification loops. Automated quality checks during execution. The agent writes code, the tests run, failed tests get fed back to the agent. The agent drafts a response, a verifier model checks it, problems get returned. Verification loops are the single biggest reliability investment you can make.

3. Context and memory. Everything we covered in Week 2 and Week 6. What the agent reads on each run. What it remembers across runs. This is where the manifest files live.

4. Guardrails. Boundary limits and safety controls. The list of things the agent cannot do without escalation. The most common production harness mistake is to make the guardrail layer too permissive and lose audit trail when something goes wrong.

5. Observability. Telemetry and audit logging. Without this, you cannot debug, you cannot improve, you cannot defend the system in a compliance review. Most teams under-invest here for the first six months and then have a bad incident that forces the investment.

Why this is engineering work

The phrase I keep coming back to with leaders is: harness engineering is engineering. It is not prompt-craft. It is not configuration. It is software, with the same disciplines a software project demands.

You need:

• A spec for the agent's job (what the agent is for, what it isn't).

• A test suite (eval set, including interactive scenarios — Week 8 covers this).

• A deployment pipeline (the harness changes deploy through code review, not chat).

• Observability infrastructure (traces, metrics, logs at every harness layer).

• Incident response (what happens when the agent fails in production).

• Continuous improvement (Hashimoto's loop: every mistake becomes a permanent harness fix).

When I tell engineering leaders this, the first response is usually "so this is just normal software engineering, applied to agents." Yes. That's exactly the point. The romance about AI agents being a different category of thing dissolves once you take harness engineering seriously. They are software systems, with non-determinism in one component, and the engineering discipline around them needs to match.

The Hashimoto loop

The single most operationally useful framing in Mitchell's piece is what I now think of as the Hashimoto loop:

Anytime you find an agent makes a mistake, you take the time to engineer a solution so that the agent never makes that mistake again.

That sentence is a complete operating philosophy.

When the agent confuses two related libraries, you add a line to the manifest. When the agent over-edits a file, you add a verification step. When the agent breaks the test suite, you tighten the spec. Each mistake is data. Each mistake is one engineering ticket. Over months, the harness becomes the codified version of every lesson the team has learned.

This is also why the harness gets better faster than the model. Models improve on multi-month cycles. The harness improves every day. By year two, the gap between an organization that practices Hashimoto loops and one that doesn't is enormous.

What separates a real harness from a fake one

I review a lot of agent systems in client engagements. The pattern that distinguishes ones doing real harness engineering from ones doing prompt-engineering with extra steps:

• Real harnesses have a deploy step. Changes go through version control and review. Fake harnesses live in a chat window.

• Real harnesses have an eval set. When you change something, you can quantify the impact. Fake harnesses change things based on vibes.

• Real harnesses have observability. You can answer "what did the agent do yesterday" with traces, not memory. Fake harnesses ask the engineer who built it.

• Real harnesses have an owner. Someone is on the hook for the agent's behavior in production. Fake harnesses are everyone's responsibility, which means no one's.

These four are the bar. None of them are exotic. All of them are absent in most agent programs I see in the first six months.

What I closed the London talk with

The argument I made in London — and which this post is the long-form version of — is that as models become commoditized, harness engineering is what becomes differentiating.

The technical layers move outward. Two years ago, the differentiator was the prompt. Then it was the context. Now it's the harness. Soon — the agentic mesh piece in Week 11 — it will be how multiple harnesses compose into an organization-scale system.

Each layer subsumes the one before. You don't throw the earlier work away. You embed it. Prompts still matter, inside the harness. Contexts still matter, inside the harness. But the unit of competitive work has moved up.

The implication for leaders is that the harness layer is where the engineering investment should go. Not picking a model. Not picking a framework. Building the discipline of operating an agent system reliably, with feedback loops that make it better every week. That is not a project. That is a department.

If you want help thinking through what your harness should look like for your specific business, that is exactly what my team at Applied Futures spends most of our time on — embedded engagements where we sit with your engineers and build the discipline alongside them.

Next week, the layer that makes the Hashimoto loop possible: how interactive agent evaluations are replacing the old static benchmarks.