Your AI agent was never the hard part. The harness is.

I spend a good part of my week working alongside AI agents rather than watching them from a safe distance. I maintain the CLAUDE.md files that tell my Design Ops system how we do things here, I write the specs it builds from, and I clean up after it when it wanders off. I’ve built design systems and the agent infrastructure behind them for long enough that I felt this next thing in practice well before I had a word for it.

The model was never the hard part.

The thing that decides whether an agent produces something genuinely useful or something confidently wrong is almost never the model itself. It’s everything wrapped around the model: the context you give it, the constraints you set, the feedback loops that catch it before it ships nonsense. There’s a name for that now, and it turned into a discipline over the course of a few months in early 2026. Harness engineering. I think it’s the most quietly important idea in AI this year, and it is, underneath the jargon, a design problem.

What is a harness, exactly?

A harness is everything that isn’t the model. The cleanest definition I have seen comes from ThoughtWorks: an agent is a model plus a harness. The model supplies raw capability. The harness supplies the constraints, the documentation, the tools, and the feedback that turn that capability into reliable output.

The name is borrowed from horse tack, and it is a better metaphor than most in this space. A harness is the reins, the saddle, and the bit that channel a powerful and slightly unpredictable animal in a useful direction. You do not make the horse smarter. You design the equipment that makes its strength usable. That is the whole job.

Philipp Schmid at Hugging Face framed it in more technical terms that stuck with me. The model is the CPU, raw processing power. The context window is RAM, limited and volatile working memory. The harness is the operating system, deciding what the CPU sees and when. The agent is just the application running on top. Most people, he points out, are trying to run applications with no operating system underneath, and then wondering why everything crashes in production.

Why the environment matters more than the model

Here is the finding that reframed it for me. LangChain ran the same model on the same benchmark twice and moved the score from 52.8 percent to 66.5 percent, purely by changing the harness. Same model. Different environment. Vercel went the other way and removed around eighty percent of their agent’s tools, and it performed better, not worse. Both examples come from Rahul’s widely shared harness engineering roundup on X, the synthesis that first sent me down this rabbit hole and a worthwhile read in full.

The uncomfortable lesson is that the agent was never where the difficulty lived. If 2025 was the year AI agents proved they could write code, 2026 is the year we worked out that the environment matters more than the model. That should feel familiar to anyone who has ever designed a system for humans. People do not fail because they are not clever enough. They fail because the environment around them is confusing, under-documented, and gives them no way to tell whether they are on track. Agents are exactly the same, which is oddly reassuring.

What a harness is actually made of

In practice a harness is a small number of unglamorous artifacts, and I recognised most of them from my own setup before I knew they had names.

The most universal is the CLAUDE.md or AGENT.md file: markdown documents distributed through the codebase that the agent reads at the start of every session, like onboarding docs for a new hire. Project context, conventions, architecture decisions, what is currently in progress. OpenAI calls them AGENT.md, Anthropic calls them CLAUDE.md, Cursor uses its own version. Different names, identical principle. Without them the agent starts every session blind. With them it starts informed.

Then there are progress files that track what is already done, so an agent picking up a blank context window tomorrow knows what happened today. Session routines that begin the same way every single time, so the first twenty minutes are not wasted rediscovering the project. And a separation between planning and execution, because an agent that plans and builds in a single pass produces unreliable work. The planning step does not have to be done by a human, but it has to be a distinct step whose output gets reviewed before any building starts.

If that last point sounds like a design review, that is because it is one. We just used to assume both participants were people.

The principles everyone arrived at independently

What convinced me this is real, rather than another framework of the month, is that three teams who never coordinated reached the same conclusions. OpenAI designed the environment so thoroughly that agents produced reviewable output in the first place. Anthropic split the work across a planner, a generator, and a sceptical evaluator, because an agent asked to grade its own homework gives itself straight As. ThoughtWorks watched fifty-odd teams fail at the same things and formalised what good looked like.

Strip away the vocabulary and the same handful of truths keep surfacing. Context beats instructions: show the agent the real state of the world rather than describing it in the abstract. Separate planning from execution. Feedback loops are not optional, because a harness without feedback is just a prompt with extra steps. Do one thing at a time. And the codebase itself is the documentation, which means the messier your repo, the worse your agent performs. Teams that invest in legible structure get better agent output almost for free.

That last one is the sentence I would underline. The quality of what an AI gives back is set upstream, in the clarity of what it is working inside, not downstream in the model you picked.

The paradox: build it to delete it

The part I find genuinely humbling is what happens next. A harness component that was essential in March can become dead weight by April, because the model underneath improved and no longer needs it. When Anthropic moved between model versions, an entire planning step that had been load-bearing quietly became overhead. This is harness decay, and it is not a bug. Every component in a harness encodes an assumption about what the model cannot yet do, and as models get better, those assumptions expire.

Which leads to Philipp Schmid’s best piece of advice: build to delete. Design every part of your harness so it can be removed, then periodically switch each piece off and check whether output quality actually drops. If it does not, delete it. Carrying a dead harness component costs you on every single run and buys you nothing.

I love this because it is the opposite of how we are trained to treat the systems we build. We are taught to protect our structures. Harness engineering asks you to build them well and then hold them loosely, ready to throw them away the moment the ground shifts. The engineers winning right now are not the ones writing the best code. They are the ones designing the best constraints, and being willing to abandon them on schedule.

None of this is really about AI infrastructure. It is about the same thing design has always been about: shaping the environment so that a capable but fallible actor can do good work reliably. I wrote recently about the four phases of AI maturity, and argued that the internal harness a company builds is the product before it is the product. This is what that harness is actually made of, and why the teams who take it seriously are pulling away from the ones still shopping for a better model.

If you want the strategic view of where this fits, the maturity piece is the companion to this one. If you want to talk about building this kind of system inside a design or product team, that is most of what I do, and you can find me on the about page.

---

Frequently asked questions