The Harness: Why the Model Is the Smallest Part of Your AI Agent
Here’s a result that should stop you in your tracks. A team at Vercel took their AI agent, deleted 80% of its tools, changed nothing about the underlying model, and watched its success rate climb from 80% to 100%. Around the same time, LangChain moved their coding agent from the bottom of a well-known benchmark to the top five, again without swapping the model. They changed something else entirely.
That “something else” is the quiet star of AI in 2026, and it has a slightly odd name: the harness.
We spend so much energy arguing about which model to use, as if the model were the whole story. It isn’t. A raw language model, on its own, can only do one thing: read some text and predict more text. It can’t click a button, run a test, remember what it did five minutes ago, or stop when it’s finished. Everything that turns that text-predictor into a thing that gets work done, the loop, the tools, the memory, the guardrails, all of that is the harness. And it turns out the harness often matters more than the model. Let me show you why, in a way that’ll make sense even if today is your first day thinking about agents.
The one equation: Agent = Model + Harness
Start here, because everything flows from it. An agent is not just a model. It’s a model plus the infrastructure wrapped around it.
And here’s the part that surprises people: by volume of engineering, the model is the small piece. Almost everything you build when you build an agent is harness.
What a harness is actually made of
So what’s inside this thing? Researchers have even worked out the minimum set of parts, the necessary-and-sufficient conditions for something to count as a harness (there’s a 2026 paper on exactly this, arXiv 2606.10106). Boiled down, a harness needs these five:
In practice, a serious harness grows a few more organs on top of those five: system prompts (the standing rules), sandboxing (a safe place to run code), persistent storage (so it can pick up where it left off), memory management (compacting context so long tasks don’t degrade, exactly the context-engineering problem), verification loops (checking its own work), guardrails (permission limits and human approval for risky actions), and observability (logs so you can see what it did and why). That’s the full anatomy: a small model in the middle, a lot of carefully built machinery around it.
Why this suddenly matters: the models are converging
For a while, the way to get a better agent was obvious: wait for a smarter model. And that worked, because models were leaping ahead every few months. But something shifted. The top models are now close to each other in raw ability. When everyone has access to roughly equally-brilliant brains, the brain stops being the differentiator.
So what decides the winner? The machinery around the brain. As models converge, the harness increasingly determines performance. This is the whole reason “harness engineering” became the phrase on everyone’s lips in 2026. And the proof isn’t theory, it’s measured, repeatable, and honestly a little shocking:
Sit with the Vercel result especially, because it flips an instinct. More tools feels like more capability. But every extra tool is another choice the model can get wrong, more noise, more ways to reach for the wrong thing. Cutting the toolset down to the sharp essentials made the agent more reliable. In harness engineering, subtraction is often the upgrade. (If that echoes the Pi post’s “do less” philosophy, it should, same lesson, different level.)
Two things called “harness” (don’t mix them up)
Quick but important clarification, because you’ll hear the word in two different rooms and they mean different things:
Where harness sits above prompt and context
If you’ve followed my earlier posts, here’s how the whole toolkit stacks up, from smallest lever to biggest:
How to use this to your advantage
This isn’t just theory to nod at. It’s genuinely actionable, whether you’re building agents or just choosing tools. The practical takeaways:
| If you want to... | Work on the harness, not the model |
|---|---|
| Make an agent more reliable | Trim the toolset to the essentials (fewer, sharper tools beat many). Add verification loops so it checks its own work. |
| Stop it running away or costing too much | Add guardrails: hard step limits, cost budgets, human approval for risky actions. This is harness work, not prompt work. |
| Keep it sane on long tasks | Invest in memory management: compaction and retrieval, so context doesn't degrade. (The context-engineering lever.) |
| Debug why it fails | Add observability: log every action and decision. You can't improve a harness you can't see. |
| Get more without a bigger model | Improve the harness first. The Vercel and LangChain results show the ceiling is usually the harness, not the model. |
| Avoid "agent sprawl" | Build shared harness infrastructure with common governance and evals, rather than every team hand-rolling their own. |
The takeaway
We’ve been staring at the wrong part. The model is the brain, yes, and brains matter, but a brain with no body, no memory, and no rules doesn’t get anything done. The harness is the body: the loop that lets it act, the tools that let it reach the world, the memory that lets it stay coherent, the guardrails that keep it safe, the evals that keep it honest. And as models grow more alike, that surrounding machinery is what separates an agent that dazzles in a demo from one you’d actually trust with real work.
So the next time someone asks “which model does your agent use?”, the more interesting question is the one underneath it: what’s the harness? Because a team that deleted 80% of their tools and doubled from good to perfect already told you where the real leverage lives. It was never only the brain. It was the harness all along.