The Harness

01

Why this, why now

Ask most people how to make an AI system better and they will say: use a better model. In 2026 that is often the least effective lever available. The model is the smallest part of a working agent, and the scaffolding around it, the tools it can call and the memory it keeps and the context it is fed and the checks it must pass, decides whether the thing works.

A definition first, because "harness" is jargon hiding a simple idea. In the last dossier we saw that an agent is a model running inside a loop. The harness is everything in that loop that is not the model: the tools it can use, the memory it keeps, the machinery that assembles its context, the checks on its work, the retries when a step fails. If the model is the driver, the harness is the car and the road and the map and the seatbelt. On its own the model can only produce text. The harness is what lets it act, remember, check itself and recover.

This is part two of a five-part manual. Part one was about the loop: gather, act, verify, repeat. This part is about the machine that runs the loop. The term has become the word for everything that turns a raw model into an agent, and 2025 and 2026 produced the evidence that the harness, more than the model, is where most reliability now comes from. For a business deciding how to invest in AI, that changes the question from which model to which harness.

02

1. Why now: the model is the smallest part

The reflex, when an AI system underperforms, is to reach for a bigger model. In 2026 that is frequently the weakest move available. The capability is usually already sitting in the model, and what is missing is the machine around it that turns capability into reliable work.

The reason to say this now is that the evidence got hard to ignore. Through 2025 and 2026, team after team reported the same result: hold the model fixed, improve the harness, and performance jumps, sometimes from failing to flawless. This dossier walks through those results, defines what a harness actually is, and draws out the strategic point, which is that the model is a commodity you buy while the harness is the advantage you build. If you take one idea from it, take this one: when your AI does not work, look at the harness before you look at the model.

03

2. The proof: same model, better harness

Start with the numbers, because they are startling.

Vercel, the web-infrastructure company, had an agent that answers questions by writing database queries, and it was stuck around eighty percent success. Their fix was counterintuitive: they cut roughly eighty percent of its tools. They tore out the long list of specialised functions and let it work with plain commands the model already understood, the same ones a human engineer uses to look around a computer, inside a safe sandbox. Success went to one hundred percent, and the worst-case run went from a hundred steps ending in failure to nineteen steps ending in success, three and a half times faster.

There is a nuance here I want to state plainly rather than bury, because it changes what the case proves. Vercel made this change as they moved to a stronger model. The better model made the crowded many-tool harness a liability, and simplifying the harness was what unlocked the gain. So Vercel is not a pure same-model story. It is something subtler and just as useful: a better model wanted a simpler harness.

LangChain is the clean case. They took a coding agent from outside the top thirty to the top five on a public benchmark called Terminal-Bench, a jump from 52.8 to 66.5 percent, without touching the underlying model at all. They changed the harness, adding self-verification loops so the agent checked its own work, giving it better information about the environment it was working in, and adding hooks to catch it when it got stuck repeating itself. Same weights, same training, twenty-five places up the leaderboard.

Independent studies of other coding benchmarks find the same pattern, where swapping the scaffold around a fixed model moves its score by a wide margin, though the exact size of that effect varies enough between setups that I would not quote a single figure for it. Put the two cases together and the lesson for anyone shopping for the best model is uncomfortable: on real tasks the scaffolding often moves the number as much as the model does.

04

3. What is actually in a harness

So what is a harness, concretely? It is everything the model does not do by itself, and it comes down to four things.

Tools are the actions the model can take: search a knowledge base, look up an account, issue a refund, open a ticket, hand off to a human. Memory is what persists across steps and sessions, so the agent is not amnesiac every turn. Context is the machinery deciding what goes into the finite window at each step, which is the subject of part three. And verification is the tests and judges and gates that check the work, plus the retries that close the loop. Here is what those four look like inside one real agent:

Inside one agent's harness · a support agentTOOLS search_kb() · lookup_account() · issue_refund() create_ticket() · escalate_to_human() MEMORY customer profile + past tickets (long-term) working notes for this conversation (short-term) CONTEXT a curator pulls the right KB article + the account, and drops stale tool output each step VERIFY check every promise against policy before sending; retry or escalate to a human on fail

Notice that the model appears nowhere in that list. It sits in the middle doing the reasoning, while the harness feeds it the right context, gives it a small set of sharp tools, remembers what matters, and checks what it produces. Stateless, a model just generates plausible text. Wrapped in those four, it becomes something that can act in the world, catch its own mistakes and recover when a step goes wrong. That wrapper is the harness, and building it well is most of the job.

05

4. The engine and the car

The cleanest way to hold this is an analogy. The model is an engine and the harness is the car built around it.

An engine is raw capability: it generates power, and a better one produces more. It is also frozen once built, expensive to change, and on its own it just spins. Everything that turns that power into a usable vehicle, the transmission and the steering and the brakes and the dashboard and the seatbelts, is the car around it. For agents that car is the harness, and unlike the engine it can be rebuilt in an afternoon with no retraining.

You would never rank cars by engine size alone, because a powerful engine in a car with no brakes is not a fast car, it is a crash. Capability lives in the model, reliability lives in the harness, and reliability is what actually ships to a customer. A modest engine in an excellent car beats a monster engine bolted to a go-kart, which is roughly what the Vercel and LangChain results showed.

06

5. Less is more: fewer tools

The Vercel result points at a counterintuitive rule that keeps showing up: for tools, less is more. The instinct is to give an agent every capability you can imagine, a tool for each thing it might need, and in practice that backfires. It is worth seeing exactly how.

The Vercel agent · before and afterBEFORE · 18 specialised tools get_schema() · list_tables() · describe_table() · build_query() · validate_query() · run_query() · ...and a dozen more, each a choice to get wrong → 80% success, up to 100 steps, 724s worst case, failed AFTER · the tools it already understood grep · cat · find · ls ( + a sandbox to run them ) → 100% success, 19 steps, 141s, 3.5x faster

Every tool you add is a decision you are making on the model's behalf and a slice of its limited attention you are spending. Eighteen specialised tools give the model eighteen ways to pick the wrong one, eighteen sets of rules to remember, and a lot of surface to get lost in. A handful of sharp general tools it already understands from training let it reason its way to the answer with fewer missteps.

Vercel's own experience sharpens the point. The crowded harness had been tolerable with an earlier model, and a stronger model reasons better when handed fewer, sharper tools, so the pile that once helped had turned into a hindrance. The best harness work is often subtractive: take tools away, give the model a safe place to try things, and get out of the way. That is the opposite of how most teams instinctively build, which is to keep adding capabilities and then wonder why the agent gets less reliable as it grows.

07

6. The evolution: weights to context to harness

Step back and the harness is the third act of a story the field tells about itself.

In 2022 the gains came from weights: bigger models, more data, better training. If you wanted a better agent you trained a better model, which only a handful of labs could afford. Around 2023 the realisation landed that you could change what the model sees rather than the model itself, through prompting and examples and retrieval, and a frozen model could suddenly behave very differently. From 2025 the centre of gravity moved outward again, to the harness: memory, skills, standard protocols, sandboxes, gates.

Each layer stacked on the last rather than replacing it. Weights still matter and context still matters, and the most consequential improvements in reliability now seem to come from the environment around the model. That outward march is good news for ordinary companies, because each step moved the leverage from something only a frontier lab can do, training, toward something any capable team can do.

08

7. Protocols: MCP and standard tools

One part of the harness deserves its own mention, because it is quietly becoming infrastructure. A protocol is an agreed standard for how two things talk to each other. The Model Context Protocol, MCP, introduced by Anthropic in late 2024, is a standard way for a model to discover and call external tools and data. It is the USB-C of AI: one shape of plug that fits every socket.

Here is why that matters concretely. Before a standard existed, if you had five AI systems and ten tools, someone had to wire each tool to each system by hand, fifty separate integrations, each one bespoke and fragile. With a standard protocol you expose a tool once, in the agreed shape, and every model and agent that speaks the protocol can use it. Connect your CRM to the protocol once and your sales agent and support agent and internal help desk can all reach it, with no extra wiring per agent.

Protocols matter to a business for a boring but important reason: they make the harness portable and durable. A tool or data source exposed through a standard protocol is not locked to one vendor's model. As the earlier dossier on the AI race argued, the model layer is commoditising and shifting fast, and standard protocols are how you keep your investment in tools and data from being stranded when you change the model underneath. A harness, done right, outlives the model it was built around.

09

8. Why the harness is the real moat

There is a strategic point hiding in all of this. The base infrastructure of agents, the ability to run a model on a loop with tools and memory, is being commoditised fast, and what was a custom framework in 2024 is a native feature in 2026. That is the normal path of infrastructure: it gets cheap and standard. What does not commoditise is what you build on top of it.

For a company the model is a bought input, increasingly a cheap one, and the generic harness is becoming one too. The durable advantage is the specific harness around your work: the tools that encode how your business actually operates, the refund tool that knows your policy and the pricing tool that reads your systems, the memory of your context, the checks that match your standards, the scoped autonomy your risk tolerance allows.

A competitor can buy the same model tomorrow. What it cannot buy is the harness you built around your operations, because that harness is a description of how your business works and no vendor ships that.

10

9. Buy or build the harness

This raises a practical question every team now faces: buy the harness or build it? The honest answer is both, at different layers, and the line becomes clear once you draw it.

The generic scaffolding, running a loop and managing context and calling tools, is being commoditised into products and is usually worth buying. The specific harness, the tools and memory and checks that encode your business, is worth building, because it is the part no vendor can sell you and the part that creates the advantage.

The trap is doing it backwards: burning scarce engineering effort rebuilding generic plumbing a platform gives away, while leaving the business-specific layer thin. We have watched more than one team make exactly that trade. The ones getting value buy the commodity and spend their effort on the harness only they could build.

11

10. The honest counter-case

Three qualifications keep this in proportion. First, the model still sets the ceiling. A better harness lifts a capable model dramatically and it cannot make a weak model do what it fundamentally cannot, so the harness is a multiplier rather than a substitute, and on the hardest tasks a stronger model still wins. The right reading is not that the model does not matter. It is that for most real deployments the model is no longer the bottleneck.

Second, harness engineering is real engineering. Memory and retries and context management and verification are genuinely hard to build well, and a bad harness can make a good model worse exactly as a good one makes it better. The Vercel result cuts both ways, since their first harness, with its eighteen tools, was actively holding a capable model back.

Third, complexity has a cost. The most reliable harnesses tend to be simple and it is easy to over-build, adding tools and agents and layers that hurt more than they help, which is the whole lesson of less is more. A harness is something you refine by removing rather than only by adding.

12

11. What a business does with this

For a leader the harness reframes the AI budget. The reflex is to spend it on access to the best model, and the evidence says the model is a commodity input while the leverage sits in the scaffolding around it. So the questions to ask of any AI initiative are: what is the harness here? What tools does the agent have, and are there too many? What does it remember? How is its work checked, and what happens when it fails? Those four predict whether it works far better than which model is underneath, and a non-technical leader can ask and understand every one of them.

This is See, Understand, Adopt applied to how you build. See that capability is bought and reliability is built. Understand the four parts of a harness, tools and memory and context and verification, and which of them your process is missing, which in our experience is usually memory or verification. Then adopt by buying the generic scaffolding and investing your scarce effort in the harness that encodes your business: sharp tools that act on your systems, real memory of your context, and checks that match your standards. The model you use will change every few months. The harness you build around your work is the thing that lasts.

The move: stop shopping for the best model and start building the best harness. Buy the generic scaffolding; spend your scarce effort on the tools, memory and checks that encode how your business works; and keep the tool list short, because for harnesses, less is usually more.

13

12. Verification and sources

This dossier draws on live web research and a personal archive of more than 15,000 sources. Load-bearing numbers were cross-checked where possible. The harness anatomy and buy-or-build examples are illustrative, built to explain the mechanics. The notes below flag confidence and the main caveats, in the spirit of showing our work.

The framed figure in this dossier is a figure from a published paper, credited in its caption. Charts labelled "BFF" are our own, drawn from the sources named beneath them. The harness anatomy and buy/build examples are illustrative, written to teach the idea.

Back From the Future · BFF Insights · Working with AI · Part 2 of 5 · July 2026