A pair of numbers worth sitting with, from a breakdown of agent architectures that went around X: the same Claude Opus reportedly scores 42% on CORE-Bench under one scaffold and 78% under another. Same model, same benchmark, different harness. The same writeup collects Vercel’s account of deleting 80% of their agent’s tools and watching it go from failing tasks to completing them. Treat the exact figures with the caution any viral thread deserves; the direction matches everything I see in production. Meanwhile every procurement conversation I hear is about which model to license, as if the model were the decision.
I’ve believed the inverted version for a while, because I live in it daily: the model is interchangeable and improving without your permission. The harness is the thing you actually build, and the only part of an AI setup that behaves like an asset.
What a harness even is
Harrison Chase draws the line well: frameworks are abstractions, harnesses are batteries included. Concretely, my harness is everything around the model that makes it shippable: the conventions the agent loads before writing, the gates that fail builds, the spec templates, the review structure, the rollback. The model decides what to do; the harness decides what it sees, what it’s allowed to touch, and what happens when it’s wrong.
Mine wasn’t built as a research project. I was the only technical person on a product, the bottleneck was me, and the harness was the way out. That origin matters for what follows, because a harness built from necessity gets ruthlessly pruned by reality, and pruning turns out to be the whole game.
The half that depreciates, the half that compounds
Here’s the uncomfortable finding for everyone with a beloved setup. Anthropic reportedly ran experiments on their own harness, stripping components one by one and measuring what still mattered (this walkthrough covers the findings), and a lot of it didn’t matter anymore. Detailed task sharding, micro-planning, context-anxiety babysitting: techniques that were load-bearing for last year’s models are dead weight for this year’s. Every harness component encodes an assumption about what the model can’t do alone, and those assumptions rot as models improve.
So is the harness a depreciating asset too? Half of it is, and knowing which half is the most useful thing I can tell you.
The depreciating half compensates for model weakness: the elaborate prompt choreography, the task-crumbling that existed because the model lost the plot on anything bigger. Hold this half loosely and delete it joyfully, since the labs will obsolete it for you.
The compounding half encodes your business, and no model release touches it. Your conventions: how this codebase does authorization, what’s legacy, what’s current. Your invariants: the table nobody touches directly because billing recalculates it overnight. Your gates: the checks that make green mean something. Your evaluation rubrics: what good looks like for your product, which no model can know because it isn’t in anyone’s training data. Your spec templates, carrying the questions your team learned to ask the hard way. Smarter models don’t make this half obsolete. They make it more valuable, because a more capable executor compounds the value of better instructions.
The practical test for any component: if the next model release could plausibly make this unnecessary, it’s scaffolding around weakness. If it encodes something true about your product that the model couldn’t know, it’s an asset. Some components pass both clauses: deterministic gates exist because models err, yet they sit firmly in the compounding half, because verification never depreciates, whoever or whatever writes the code. And for budgeting shape, mine took two to three months of front-loaded work before it paid anything back, and it’s been paying back since. Budget accordingly.
Why this matters commercially
Follow the logic to procurement and it lands somewhere most AI strategies haven’t: the model is rented, the harness is owned, and only one of those builds equity. Two products I work on run on substantially the same harness. When we moved it from nerds.family to Gyfted, onto a stack we don’t usually touch, the structure held and the new product inherited months of encoded lessons on day one. That transfer is what being an asset means.
It’s also, openly, how we think about client work: the harness we build on an engagement stays in the client’s repo when we leave. Conventions, gates, templates, the lot. We say this on our homepage and mean it mechanically, because a rollout where nobody owns the harness decays no matter how good the tools were, and a team that owns its harness keeps compounding after we’re gone.
The gardener requirement
Owning an asset that half-depreciates means somebody has to do the pruning, and this is where I’d push back on “harness” sounding like a one-time build. The thing needs a named owner who treats it as a product: every agent failure becomes a rule or a check, and every model release triggers the opposite review, asking which compensations can now die. Skip the first and the harness stops growing. Skip the second and it calcifies into the dead weight Anthropic measured, a museum of workarounds for problems the models no longer have.
The teams that get this right hold both habits at once, and the result is a strange and pleasant curve: their setup gets simpler and more powerful at the same time, simpler because weakness-scaffolding keeps dying, more powerful because the business-encoding keeps accreting. If your AI strategy currently fits in a procurement document about model licenses, the question to add is the one this whole post argues for: who owns our harness, and what did they delete last month?