What's Harness Engineering?

If AI models are a commodity, the harness is the thing you want to own.

Jul 21, 2026

The TL;DR

An AI model on its own can only talk.

A harness is the software wrapped around it that lets it actually do things: touch your files, run your tools, and remember what happened.

An AI model by itself only answers a prompt. A harness is what lets it act: use tools, remember, and take steps until a job is done.
Picture harnessing a horse: the horse is the raw power, the harness is what lets you put it to work without it bolting.
The AI coding agents you’ve heard of (Claude Code, Codex, Cursor) are all harnesses.
The frontier model is becoming a commodity (everyone rents the same few). Your harness configuration is what you want to own.

The next decade of software won’t be “an app with AI added on.”

It’ll be harnesses, and the build-vs-buy call is yours to make. So read this!

For the past 6 months I’ve done a bet with myself: do everything through agentic tools, change a line of code or text only when I absolutely have to.

At the beginning this made me incredibly slow, but as I progressed and turned into a power user, I started to see the value in harnessing AI models myself. Currently I am interacting with my computer 90% via Claude Code and I can see how harnesses have the potential to revolutionize how we think about software and computers in general.

Now let’s see why a raw model can’t do the job on its own, what a harness actually is, the everyday parts every harness is built from, and what all of it means for your company.

Why a Raw Model Isn’t Enough

On its own, an AI model does exactly one thing: you give it one input, it hands you one output, and then it stops. No memory of the last step, no ability to take the next.

That’s not the magic you feel in Claude Code or Codex. Those tools take dozens of steps on their own: reading your files, running things, catching their own mistakes, pulling what they need from memory or the internet, looping until the job is actually done. A raw model can’t do any of that by itself.

That repeat-until-done cycle (read what’s there → decide the next step → do it → check the result → go again) has a name. It’s the agent loop, and it’s the engine that turns a one-shot answer into finished work.

And the best ones don’t just act. They check their own work. Boris Cherny, who created Claude Code, says the most important thing for getting great results is giving the AI a way to verify its own work: a feedback loop that, in his words, can 2–3× the quality of the final result. That self-correction is a harness feature, not a model one.

This takes us from “answers a question” to “does the job”:

*A raw model answers once and stops. A harness wraps it in a loop that keeps going until the job is actually finished.*

If the model is the easy part and what’s built around it is the hard part, the obvious question is: what is a harness?

So What’s a Harness?

Picture a wild horse. It’s raw power it’s nearly useless until you harness it: reins to steer it, blinders to keep it focused on the road, a saddle so it can carry weight.

A model is the horse. The harness is the software wrapped around it. It adds the hands (tools), the memory, the reins (guardrails), and the loop that lets it take many steps. That combination (not the horse alone) is what does real work.

An agent = a model + a harness. The agent is the working thing you actually use: a model with a harness wrapped around it. The model is the raw intelligence.

The harness is what puts it to work. LangChain (a popular toolkit for building these systems) frames it bluntly: the harness is everything that isn’t the model itself, and that “everything else” is where almost all of the engineering, and the magic, actually lives.

*A model on its own is a horse, raw power, but useless. Add the harness (tools, memory, guardrails, and the loop) and you get an agent that does real work.*

There’s a name for the work of building one, too. Mitchell Hashimoto (a veteran engineer, co-founder of HashiCorp) calls it harness engineering: “anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”

So a harness is what that work leaves behind. Lessons about how the AI fails gets built into the wrapper so it stops failing that way (and instead finds new ways to fail :).

What’s Inside a Harness

At the center of the harness, we have the loop, the engine that keeps calling the model until the job is done. Plus a kit of 7 parts that allows us to steer the model’s behavior:

Tools. Without them, the AI model can only provide “talk”. In other words, it can only output text, images or audio. With them, it can interact with the outer world, such as reading files from your computer, executing code, searching the web or editing a document.

Memory. The AI forgets everything between sessions, so the harness gives it files to write to and read back: its long-term memory and to-do list.

The files are what let it remember anything at all and pick up where the last session left off. The simplest memory implementations are based on files, but depending on the complexity of your use case, you may need a more sophisticated solution based on vector or graph databases.

Context. The context window is what the LLM sees at a time, in each iteration of its loop. The problem is that it’s limited to 128K, 256K, up to 1M tokens. As the context window grows, the model starts to get confused and produce incorrect results, a problem known as “context rot.” The role of the harness is to keep the context window sanitized by adding/removing components at each iteration. Ideally, you want to keep the context with exactly the right information that gets the job done.

A sandbox. It’s a safe room where the AI can make a mess (run things, break things) without the risk of touching anything real in your business, such as deleting files, accessing sensitive data or even running malicious code on the computers from your private network.

The goal is to give the agent exactly as much access as it needs to get the job done. Otherwise, during its agentic loop, it can always decide to go rogue just to achieve its goals. It’s very common to start looking around for API keys to access data from your database or other services.

Guardrails. A big part of guardrails is the permission layer, which sets the rules for what the AI may do on its own: what runs freely, what needs your okay first, and what’s automatically denied. These need to be carefully balanced to avoid asking the human to accept each command (which adds a ton of friction, forcing the user to babysit the agent) while still asking for user input at essential points, such as deleting a file or changing one that’s not versioned.

Orchestration. For complex jobs, 1 AI acts as a project lead, delegates to a team of specialist AIs, each handling a piece and then pulls the results together. A caution from experience: don’t reach for the multi-agent systems too early. I once split a job across 5 or 6 specialist AIs, and a single, well-set-up one beat the whole team.

Interfaces. The same harness is reachable from your phone, laptop, browser, Slack, or WhatsApp.

The AI Tools You Already Know Are All Harnesses

Every popular AI tool you are using is a harness. Claude Code, Cursor, Codex: the same kind of model inside, a different harness wrapped around it.

Here’s what usually happens: when a product feels better than a plain chatbot (it remembers your project, fixes its own mistakes, actually finishes the task), that feeling is the harness doing its job. Two products can call the exact same model and feel worlds apart, purely because their harnesses are worlds apart.

And this isn’t just a vibe. In one public test done by LangChain, they changed only the harness around a coding agent (same model throughout) and it climbed from roughly 30th place into the top 5 on the Terminal Benchmark used to evaluate agents.

Before we get to what this means for your company, let’s clear up 3 words that get thrown around as if they’re the same thing.

🚨 Confusion Alert

1. Prompt engineering = writing good instructions. Telling the AI clearly what you want.

2. Context engineering = managing what the AI sees (the context window). You want to keep it focused (only what’s relevant), because piling on clutter actively confuses the model (the context rot issue).

3. Harness engineering = building the whole system around the model: the tools, the memory, the guardrails, the loop.

*Prompt, context, and harness engineering are nested layers — each contains the one inside it, and harness engineering is the whole system around the model.*

So harness engineering is the last step: the whole AI application around the model. Which raises the real question: should your team buy or build its own harness?

What This Means for Teams

Claude Code is a harness someone else built for general coding. It’s superb at that. But it will never know your finance rules, your data, your guardrails or your customers. The moment your AI needs to do your job, a generic harness hits a wall.

Still, a harness you build becomes its own product, with its own bugs, issues and maintenance overhead. Owning the layer can give you an advantage, but it’s an ongoing investment, not a one-and-done build. The real question isn’t whether you can (Claude Code can build you a harness), it’s whether you should.

That’s why most people I know, including myself, are customizing harnesses (via skills and MCP servers) intended for coding, such as Claude Code, for their own use cases, or coupling them with Notion or Obsidian to transform them into their personal assistants.

But using coding harnesses for everything has one major drawback: they are optimized for coding, and the people building them will keep optimizing them for coding. This might lead them to behave more poorly with each version update.

Another huge drawback is that it’s almost impossible to build your own product on top of them. They are amazing as internal tools, but once you want to stitch a UI on top of them or distribute them to your users, you hit another wall.

That’s why we started seeing harnesses specialized for different domains, such as:

Creative: Descript (video), Canva Magic Studio & Adobe Firefly (visuals), Figma AI (design)
Legal: Harvey (drafting contracts), CoCounsel (reviewing contracts)
Medical & Healthcare: Abridge & Nabla (generating clinical notes from doctor-patient conversations)
Financial: I personally worked at ZTRON as a harness for financial advisors
Productivity: Notion AI

But there is a middle ground between building and buying. As harnesses are being standardized, major frameworks such as Pydantic AI’s Harness, Pi or LangChain’s Deep Agents have recently entered the game.

They’re good open source starting points that provide the agentic loop, the 7 key parts and the option to easily add your own UI/UX and distribution.

You don’t need to build a harness tomorrow, but it’s important to know that you can build a custom harness when you’re ready, and it’s a piece of your stack that’s worth owning.

Harness in Conversation

“We’re still building out the harness around the model.”

We have the AI. Now we’re building the software that lets it actually do the job.

“That’s a model problem, not a harness problem.”

The AI itself is getting it wrong, versus we just haven’t given it the right tools or memory yet. (Usually it’s the second one.)

“We don’t want to be locked into someone else’s harness.”

We want to own the layer that makes our AI ours, instead of renting it from a vendor.

“We should switch to an open-source harness.”

Move off a closed tool like Claude Code to an open-source alternative you can see inside and bend to your needs, such as OpenCode or Pi.

Discussion about this post

Ready for more?