The Model Is Not the Product. The Harness Is.
What I learned from taking six agent harnesses apart, and why I came back to Claude Code
I used harnesses for a year before I knew the word
I started with VS Code extensions. Then came the VS Code-based editors: Windsurf, Cursor and later Antigravity. Each felt like autocomplete that had grown ambitious: it could edit a file, then another, then run something to check its work. Then came Claude Code and Codex, and the shift was obvious even if I couldn’t name it. I was no longer typing with a model. I was handing it a task and coming back later.
At the time I would have said I was “using an AI coding tool”. That description is true and almost useless. The model was Claude, GPT or Gemini in every case. What changed between them was everything around the model, and that is the part I had never looked at.
The word for that part is the harness. This article is about how I found it, what I learned from taking several of them apart, and why I ended up back where I started, but with my own hands on the controls.
What a harness actually is
A harness is everything that turns a model into an agent. The model produces text. The harness decides what text to feed it, what it is allowed to do with its answers, and when to stop. Strip the harness away and you have a chat box.
Every harness I have looked at is built from the same six parts, whatever name it gives them:
- System prompt. Who the agent is, how it should work, what it must never do. Claude Code’s is long and opinionated. Some open-source harnesses ship a two-paragraph default and expect you to write the rest.
- Tools. Shell, file read and write, search, web fetch, and whatever you plug in through MCP. The tool set is the agent’s hands. No tool, no action.
- Context management. Which files, logs and earlier messages go into the window, what gets summarised or dropped when it fills. This is where most of the quality difference between harnesses lives.
- Memory. What survives between sessions. A CLAUDE.md file, a notes directory, a vector store, or nothing at all.
- Permissions. What the agent may do without asking. Read anything, write only in the repo, run tests but never
git push. Harnesses differ sharply here, and it shapes how much you trust them. - The loop. Plan, act, observe, repeat until the task is done or the agent gives up. How a harness decides “done” and how it recovers from a failed step is the hardest part to get right.
The model is in the middle of all this, but it is a replaceable part. Most harnesses let you swap it with a flag.
The moment it clicked: building my own hierarchy
The concept only became real when I built an orchestrator with sub-agents underneath it. One agent took the task, broke it into pieces, and handed each piece to a specialist: one for reading the codebase, one for writing the change, one for running and reading tests. The orchestrator never touched a file itself. It only planned, delegated and checked.
Two things became obvious very fast.
First, I was writing a harness. Every design decision I made was a harness decision: what each sub-agent could see, which tools it got, how much of its output flowed back up, when the orchestrator should stop trusting a result and re-run it. None of it was about the model.
Second, the model was the easy part. I could point the same sub-agent at a different model and it mostly still worked. But change the context rules or the permission boundary and the whole system behaved differently. The hierarchy was the product. The models were interchangeable workers inside it.
Get MGuptaHub’s stories in your inbox
Join Medium for free to get updates from this writer.
That is when I started reading other people’s harnesses with real attention.
The tour
Over the following months I worked through OpenCode, OpenClaw, Hermes Agent and DeepSeek Harness (DSH). I was not looking for the best one. I was looking for how each answered the same handful of questions, because the answers are where the design lives.
- What does the agent see? Some harnesses load the whole repo map up front. Others load nothing and make the agent go looking. The first is faster on small projects and falls over on big ones. The second is slower to start and scales better.
- What can it touch? The permission model ranges from “ask before every write” to “do whatever you like inside this directory”. Neither is wrong. They are built for different levels of trust and different kinds of work.
- When does it stop and ask? This is the one people underrate. A harness that interrupts too often is exhausting. One that never interrupts will confidently do the wrong thing for twenty minutes. The good ones have a clear rule for what counts as a decision worth a human.
- How does it remember? A single markdown file the agent reads on start. A directory of notes it maintains itself. Nothing. Each choice changes how the agent behaves on day ten versus day one.
- How does it hand work to other agents? Some have no concept of sub-agents. Some have a rigid orchestrator pattern. Some let you define the hierarchy yourself. Having built my own, this was the axis I cared about most.
The open-source harnesses were the most instructive, not because they were better, but because I could read them. Seeing a harness’s prompt, loop and permission code laid out in a repo made the invisible parts of Claude Code and Codex visible by comparison.
Same model, different agent
The single most useful thing I learned: the harness shapes behaviour more than the model does, once the model is good enough.
I ran the same model through three different harnesses on the same task. One finished cleanly. One got stuck re-reading the same file because its context rules kept evicting what it had just learned. One did the work but asked me eleven questions along the way, most of which it could have answered itself. Same weights. Three different agents.
This changes how you should read benchmarks and model announcements. A new model is a new engine, and engines matter. But you drive the car, not the engine. If the agent you use feels clumsy, the fix is probably in the harness, and the harness is the part you can actually change.
It also explains why developers get so attached to one tool. They are not loyal to a model. They are loyal to a set of decisions about context, permissions and interruptions that happens to fit how they work.
What it looks like on a Tuesday
None of this is abstract once you have a failing build.
You tell the agent the CI is red. It opens the logs, finds the stack trace, traces it to a change from yesterday, reads the surrounding code, proposes a fix, applies it, and runs the test suite. If the suite still fails, it reads the new failure and tries again. You get a summary and a diff.
You still review it. Sometimes the fix is wrong, or right for the wrong reason. But the forty minutes of grepping, reading and re-running that used to sit between “build is red” and “I know what happened” now happens while you are in a meeting.
Multiply that across a team of eight and the effect is not that each person is a bit faster. It is that the slow, boring, interrupt-driven work stops landing on anyone’s desk in the first place. The team’s attention goes to the decisions that need it.
Every part of that story is a harness feature. Reading logs is a tool. Tracing to yesterday’s change is context management. Running tests without asking is a permission. Trying again after a failure is the loop. The model wrote the fix, but the harness got it to the point where a fix was the next step.
Where I landed
After all of that, I use Claude Code with my own custom agent setup. I want to be honest about why, because “I tried everything and went back to the mainstream tool” can sound like the exploring was wasted. It was not.
I came back because Claude Code gets the hard harness decisions right by default: context handling that does not fall apart on a large repo, a permission model that is strict enough to trust and loose enough to be useful, and a sensible rule for when to stop and ask. Those are the parts I least want to maintain myself.
I stayed because it lets me change the parts I do care about. My setup is a set of custom agents with their own prompts, tool lists and scopes, plus an orchestrator that knows which to call for what. It is the hierarchy I built by hand in the early days, rebuilt inside a harness that handles the plumbing.
The tour was what made that possible. I could not have designed those agents well without having seen five other harnesses make the same decisions differently. Reading other people’s harnesses is how you learn to shape your own.
Start looking at your own harness
If you use Claude Code, Codex, OpenCode or anything like them, you already have a harness. You have just been treating it as the product rather than as a set of decisions you can inspect.
Three things worth doing this week:
- Read the system prompt. Most harnesses expose it or let you add to it. Knowing what your agent has been told explains half of its behaviour.
- Write down the permission boundary. What can it do without asking? If you cannot answer in one sentence, you do not know what you are trusting.
- Change one thing. Add a memory file. Tighten a tool list. Define one sub-agent with a narrow job. Watch how the agent’s behaviour shifts without the model changing at all.
The model is not the product. The harness is. And the harness is yours to shape.
