Alongside prompt and context engineering, harness engineering has emerged as the most important skill for building AI products. It’s a superset of the two:
I’ve been waiting for a great guide to reveal itself, but I haven’t seen one. The best stuff out there is either too high-level or too engineering-level. So I’ve spent the past couple months learning everything about harness engineering.
After interviewing experts like Ryan Lopopolo , iterating on my own harnesses, and learning from PMs who have built great AI products, I’m ready to share the results.
Today’s Post
Here’s your complete guide to Harness Engineering, at the right level for PMs:
What the heck is a harness
The 4 types of harnesses PMs should care about
Learning harness engineering from a Personal OS
Case studies of harness engineering for product building
Who owns what, the Harness Spec, and an AI assistant to help
Why harness engineering has become more important over time
Why This Matters
Before we get there… one quick thing.
Addy Osmani said it well, in a thread 857K people saw:
“A decent model with a great harness consistently beats a great model with a bad harness.”
A bad harness can have horrific consequences.
For instance, on August 26, this dev watched Fable nuke his computer:
Was it Fable that was at fault here? Partially.
But whatever the model did, the harness is what should have stopped it.
So we’ll learn how to build a good one today.
1. What the heck is a harness
Everyone has been hyping up agents since 2024. So you get it: agents matter.
Now here’s the thing to grok: why agents matter is also why harnesses matter.
It comes definitionally:
Agent = Model + Harness.
The harness is everything that isn’t the model. On its own, a model turns text into text. The harness is what lets it act, remember, and stop.
The Anatomy of a Harness
I’ve been studying all the best harnesses out there, and I’ve realized that they all boil down to 8 key components:
Let me walk you through this diagram quickly:
Instructions are what the agent reads every single time. In Claude Code that’s your
CLAUDE.md. In Codex it’sAGENTS.md.Context is what it knows about you, your product and your users.
Skills are step-by-step playbooks it only loads when a task needs them.
Memory is what it still knows tomorrow.
Permissions decide what it can do without asking you, and what it can never do.
Tools are what it can reach: your files, your terminal, and MCP connections.
Checks, including evals, catch its mistakes before you ever see them.
The loop is how it plans, acts, looks at the result, and decides it’s done. Its effort level sets how hard it thinks first.
Claude Code, Codex and Cowork are all harnesses. But most people build harnesses on top of them as well - often dubbed “operating systems.”
We’ll talk more about that in section 2.
2. The 4 Types of Harnesses PMs Should Care About
Once you know what a harness is, you start to see them everywhere.
As a PM, you’ll run into 4 types:
Your Personal OS is the harness you build for yourself. My PM OS is one of these, and 1000+ PMs have picked up the kit.
Then comes your Team OS. This is the harness your entire product team shares. I built you one.
After that comes your Company OS. Jiaona Zhang built one on Claude Code and Slack. Mikhail Shcheglov added Hermes and OpenClaw.
The final important category is your Feature Harness, for every AI feature you ship in your product.
As PMs, we should have a point of view on how all 4 are built.
Ashby’s Law
There’s an old law from cybernetics:
Ashby’s Law of Requisite Variety.
A regulator needs at least as much variety as the system it’s trying to control.
What this basically means is that your harness has to handle as many situations as your agent can get into.
Your Personal OS serves one user: you. So it’s the easiest, and it’s where we’ll start.
A team OS serves your team, so it gets more complex.
And a company OS serves your company, so that’s even more complex.
Finally, a feature harness serves every one of your customers. That’s the final stage of complexity, where you need to handle every strange request they’ll ever type.
Let’s work our way up to it.
3. Learning Harness Engineering Through Your Personal OS
Since your personal harness is the easiest one to start with, let’s learn the basics of harness engineering with it.
Just Chat
Where do we all start with AI? Just the model of course. Let’s give Claude a simple prompt of a feature results writeup for our fictional company Tandem:
It calls it a “solid launch.” That’s actually wrong, but it can’t know that, because it only knows what you typed.
Connect Product Analytics
The next step in our harness building journey is to connect our data. Let’s use MCP to connect to our product analytics tool and prompt simply:
Now we’re cooking. Segment by segment, it finds the real story on its own. We learn that there is critical nuance beyond the headline:
SMB is working.
But enterprise opt-outs are at 6.8%! That’s a bad sign, probably a reason to pause the enterprise expansion. But the simple chat missed it.
That’s why it’s so important to add tools to your harness.
But there are still more problems! The harness right now still doesn’t know your strategy, your customers, or what it’s allowed to do on its own.
That’s what the rest of the ladder adds.
The rest of this article is for paid subscribers only. They get access to:
The Harness Spec 1-pager
The full toolkit in Notion
The rest of the ladder, from context to loops
5 case studies, OpenAI to Ramp
The /harness-assistant skill