Every Harness Is a Short Position on the Model

I argued on this site that the harness is the product , that the frontier model is a wasting commodity and the thin layer of scaffolding wrapped around it is the asset you actually own. I stand by the correction. It was aimed at the people still treating the model as the product and the harness as glue code an intern writes between tickets, and those people have the ratio backwards. But that sentence smuggled in an error, and it is time to pay it back. Calling the harness the asset you own blurs a line that turns out to be the whole game. A sliver of the harness is an asset. The rest is a short position on the model, and the model only moves one way.

The binding-constraint numbers are real and I am not walking them back. Harness optimization with the weights held fixed cleared 76.4% on Terminal-Bench-2, beat every hand-built system in the comparison, and harness work routinely moves the score more than a model upgrade does. The harness is where capability gets produced right now. The mistake is reading "produces capability today" as "accumulates value tomorrow." A harness component earns its keep by encoding something the model cannot yet do, and that is exactly the property that dooms it. Anthropic put the blade in its own hand: every part of a harness is a wager about a specific model weakness, and the next release is the settlement date. That reframes the thing from infrastructure you own into a position you hold against the model, and the model is the counterparty that keeps winning.

The two harnesses, and why the distinction is the whole game

There are two harnesses wearing one name, and almost nobody separates them, which is why "is the harness valuable" keeps generating confused answers. One harness encodes facts about the model. The other encodes facts about the world.

Scaffolds that compensate for what this generation of model cannot do, the planning decomposition, the stuck-detection heuristics, the re-injection hooks, the hand-written context pruning, the reasoning aids glued onto the prompt, are all pricing a model deficit. They are on the clock. Scaffolds that encode something true about the environment the agent runs in, the tool surface to real systems, the verifier that supplies ground truth, the permission and liability boundary, the regression suite that defines what correct even means, are pricing a world constraint. They survive every model release, because no quantity of model capability changes the fact that your database needs an authenticated connection, or that a trade over a threshold needs a human in front of it.

When I called the harness the asset you own, the asset was always only this second half. The spec, the verification rubric, the tool definitions, the routing policy I named in that earlier piece are world-facts, and world-facts compound. The error was letting the word "harness" carry both halves, because the first half does the opposite of compound. It decays on a schedule the lab sets.

Here is the failure I watch teams commit. They build the rotting half, feel the capability gain it produces, book it as infrastructure, and add it to the pile. A year of that and the harness is a sediment of accumulated workarounds, half of them compensating for weaknesses three model releases gone. The codebase reads like infrastructure. It behaves like debt. The binding-constraint thesis is true in the moment and dangerous as a strategy, because it tells you to invest where the returns are highest right now without warning you that those returns are the fastest to rot. A recent controlled study even separates the capability to update a harness from the capability to benefit from the update and finds neither one tracks raw model capability. Knowing how to bolt on a scaffold is not knowing which scaffold to bolt on, or when to tear one out.

What the rotting half is actually pricing

A model-deficit scaffold becomes legible the moment you ask what failure it exists to absorb. The Ralph loop, which I walked through in The Loop Was Never the Hard Part , is the cleanest case. It is a hook that catches the model trying to end its turn and shoves the prompt back in against a completion goal, and it exists for exactly one reason: today's models stop early. The day a model holds a completion goal across a long horizon without being shoved, the Ralph loop is a wrapper that re-prompts an agent which was already going to continue. Dead weight, then drag.

The pattern repeats everywhere you look. Symbolica's Arcgentica harness for ARC-AGI-3 runs a top-level orchestrator that never touches the environment, delegating to subagents that hand back compressed summaries, the whole scheme engineered to keep context growth under the model's window limit. Real ingenuity, aimed at a real constraint. The constraint is the context window. Every expansion of that window, every gain in how models attend across long contexts, shaves value off an orchestration design whose only job was to dodge the limit. The embedding-based retrieval pipelines most agents still run tell the same story. Anthropic now describes the move in plain terms, away from pre-built retrieval where you decide in advance what the model will need and stuff it into context, toward just-in-time strategies where the agent fetches what it needs as it reasons. The retrieval scaffold was a bet that the model could not be trusted to find its own context. Better models are collecting on the bet.

Reasoning scaffolds are next in the queue. The elaborate chain-of-thought prompting, the scratchpad templates, the forced step-by-step decomposition that squeezed sharper reasoning out of a 2024 model, all of it is a bet that the model will not reason well unless you choreograph the steps for it. Models trained to reason on their own are quietly retiring that entire genre of prompt engineering. The careful scaffolds people built to coax reasoning now read like step-by-step instructions handed to a colleague who stopped needing them a release ago.

None of these were mistakes. Each was the correct engineering response to a real deficit at the moment it was built. That is the uncomfortable part. A harness is at its most valuable exactly when the model is at its weakest, and the work you do to paper over a weakness carries a shelf life set by someone else's training run.

The verifier is the exception, and I have made that case already

One durable component deserves naming, because everything else in the harness orbits it: the verifier, the signal that tells the agent whether it is right. I argued the full case in The Loop Was Never the Hard Part, that a loop is only as honest as its oracle, that the oracle is the scarce and defensible part while the loop is boilerplate, that coding agents work precisely because the test suite is a cheap external oracle the industry spent thirty years building. I will not re-run the argument here.

The point this piece needs is narrower: why the verifier sits on the durable side of the line when the planner and the loop do not. It encodes a world-fact, not a model-deficit. Ground truth does not turn redundant when the model improves, because the thing it supplies is the one thing the model cannot supply about itself, an outside check. There is a harder result underneath that makes the durability permanent. Even when you hand models high-quality external feedback over many iterations, they plateau below the ceiling the feedback should let them reach, and the feedback gets resisted. Nobody fully understands the mechanism yet, but the design implication is clean. The external signal never becomes optional, because the model never fully absorbs it even when you give it away for free.

The Verification Renaissance frame on the Map named verifiability as the differentiator of this era. The depreciation curve is why. The verifier is the single harness component that appreciates while everything bolted around it decays. This piece is about the fate of everything else.

The structural-graph camp is building on the fault line

The most serious technical answer to loop fragility right now comes from the scheduler-theoretic camp, and it is instructive, because careful people are pouring real rigor into the rotting half of the harness without naming it as such. The framing is good. A bare agent loop, the paper argues, is a scheduler with exactly one ready unit at any moment, choosing its next move from opaque model inference rather than any inspectable policy, which saddles it with implicit dependencies between steps, recovery loops that can run unbounded, and a mutable history that makes debugging miserable. Sixty percent of the seventy open-source agent systems they surveyed run this bare pattern. The proposed fix lifts control flow out of the model's context and into an explicit static graph, with immutable plans and a hard separation of planning, execution, and recovery.

As engineering, that is a real trade, honestly stated. You surrender expressiveness to buy controllability and verifiability. For a regulated workflow that has to be audited, the trade may be worth a permanent tax. Look at what the explicit graph is compensating for, though. Planning. Recovery. Dependency tracking. These are precisely the capabilities improving fastest, because they are the capabilities the labs are training hardest against. An explicit DAG that does the agent's decomposition for it is a bet that the agent cannot decompose well on its own, and that bet gets worse by the release. The more the model can plan, the more the static graph stops being a guardrail and starts being a cast on a limb that already healed.

The graph camp is not wrong. For auditability and hard guarantees, externalized control keeps earning its overhead, and that overhead is a world-fact, because you need the audit trail no matter how smart the model gets. The trap is that most of the planning and recovery scaffolding being built under the controllability banner is model-deficit work wearing a verifiability costume, and the people building it have not drawn the line between the part that survives because a regulator demands it and the part that dies because the model outgrew it. Draw that line before you commit a roadmap to it.

Co-training is the model eating the harness

I have described one version of "agents break when the model improves" before. In The Loop Was Never the Hard Part it was the oracle getting gamed faster, because a sharper optimizer finds the proxy-satisfying shortcut sooner, so a static verifier has to get stronger just to hold its ground. That is one mechanism, and it operates on the durable half. There is a second mechanism, broader and aimed straight at the rotting half, and it is the one the harness celebration has not reckoned with. The scaffolding gets absorbed.

Frontier labs now co-train their models with their own harnesses. Claude Code and Codex are not generic loops; the models inside them are trained specifically for those harnesses, which is why benchmarks increasingly evaluate agents in their native harness rather than a neutral framework. The objection writes itself. Does that not make the harness more entrenched, more of a moat?

It makes the provider's harness more durable by dissolving it into the weights, which is not a counterexample to harness rot. It is the cleanest mechanism of it. When a lab co-trains a model against a harness, the scaffolding stops being external code and turns into learned behavior. The early-stopping fix, the context-management discipline, the tool-calling conventions migrate from the harness into the model. The provider's harness survives in the sense that its logic persists, but it survives by being absorbed, not by being maintained as a separate layer. And the harness you built on top, the third-party scaffolding wrapped around someone else's model, is now competing head-on with capabilities baked into the model you are calling. Every training run pushes the boundary up. Things you had to scaffold last quarter the model now does natively, and your code for them is no longer merely redundant, it can fight the model's trained instinct and make the agent measurably worse.

This is the part the celebration misses. The model is not a fixed substrate your harness sits politely on top of. It is a rising water line that absorbs whatever scaffolding it reaches. SlopCodeBench exists because agents visibly degrade over long-horizon iterative tasks, and that degradation is a harness-model interaction, not a clean model property. Co-training is the labs internalizing the harness on their side of the line. Your job, on your side, is to notice what got internalized and delete your now-redundant copy before it does harm.

We have watched tooling eat its own scaffolding before

The harness is not the first layer of compensating machinery to be swallowed by the thing it wrapped, and the history rhymes hard enough to be predictive. Hand-written assembly optimization was a craft and a real edge, right up until compilers learned to allocate registers better than a human could by hand, and the craft collapsed into a niche. Hand-tuned SQL was a moat for a generation of backend engineers, then query planners and ORMs absorbed the common cases, and the tuning that survived was the genuinely hard residue the planner still could not infer. Web frameworks ate the boilerplate that early developers wrote out by hand. Each cycle ran the same way. A layer of human scaffolding compensates for what the underlying system cannot yet do, the system improves, and the scaffolding either disappears into the platform or shrinks to the small set of truly hard cases the platform never learned.

The model is the new compiler. The harness is this cycle's hand-tuning, and co-training is the optimizer learning the patterns that used to need a person. That framing tells you which harness work is the assembly optimization headed for absorption and which is the hard residue that persists. Register allocation got absorbed because it was a model-deficit, a thing the compiler could in principle learn. The choice of algorithm for a novel problem did not get absorbed, because it encodes something the compiler has no access to: intent, context, the actual shape of the problem. Map that onto agents and the line falls exactly where it has fallen every time. Scaffolding that encodes a capability the model can learn gets eaten. Scaffolding that encodes a fact about your world, your systems, your liability, your definition of done, does not, because the model has no path to learning what it was never shown.

One thing is different this time, and it sharpens the stakes rather than softening them. Compilers improved on a cadence measured in years, and the assembly programmers had time to watch it coming. Frontier models ship capability jumps on a cadence measured in months, and they co-train against the harness on purpose, which makes the absorption faster and more deliberate than anything the compiler era produced. The scaffolding you write this quarter is being targeted for absorption by the next training run, deliberately, by a lab with every incentive to make your workaround unnecessary. Build with that clock in the room.

What this means for the people funding agent infrastructure

The depreciation curve is not only an engineering concern. It is a diligence question, and most of the capital flowing into agent infrastructure right now is not asking it. A company whose entire differentiation is harness sophistication is selling a perishable asset, and whether it is a good bet turns on which half of the harness the differentiation actually sits in. If the moat is a clever planning loop, a proprietary decomposition strategy, a context-management trick, then the moat is on the model's release schedule, and the next frontier model that does the same thing natively does not compete with the company, it deletes the company's reason to exist. The deck calls it a platform. The depreciation curve calls it a feature the model has not shipped yet.

The companies worth funding sit on the durable side of the line. A business built on deep, maintained integrations with consequential systems, on a verification layer that encodes a domain's real definition of correct, on the permission and liability fabric that the Compliance as Differentiation thread on the Map describes, is building something the model cannot absorb, because the moat is a fact about the world rather than a gap in the weights. Those companies grow more valuable as agents proliferate. The scarce thing is never the loop. It is the trusted connection to the system that matters and the honest signal about whether the agent did the right thing. Every lab will hand you the loop for free. The verifier wired into your specific domain, and the liability boundary an underwriter will actually price, they will not.

So the diligence question is short, and almost nobody asks it cleanly. Show me the part of your harness that survives the next release. If the answer is the planner, the orchestration graph, or the prompt scaffolding, you are looking at a company shorting the model with someone else's capital. If the answer is the verifier, the integrations, the evals, and the liability fabric, you are looking at a company building on the one side of the line that compounds. The binding-constraint thesis says the harness drives the score today. It does not say the harness keeps the score tomorrow, and the whole game is played in the gap between those two sentences.

What to build, knowing it will rot

You build the harness anyway, because you have to, and you build it as two separate things with two separate lifespans. I said in the earlier piece to keep the harness thin and disposable. This is the operational version of disposable. The durable layer gets treated as software. The verifier, the tool surface to real systems, the permission and liability boundary, the regression and capability evals: these you build to last, version with care, and fund without apology, because they encode the world, and the world is not shipping a model upgrade. The rotting layer gets treated as scaffolding. The planning aids, the stuck-detection heuristics, the re-injection hooks, the manual pruning rules: these you build cheap, isolated, and trivial to remove, because you will be removing them, and the only question is whether you architected so deletion is a clean lift or a load-bearing extraction.

Then you instrument the depreciation, which is the discipline the field has not built yet. Agents fail not only when the model degrades but when it improves, and the second failure is invisible without the right test. A model upgrade can quietly render a scaffold redundant, or worse, render it actively harmful, and you will never catch it in a capability eval that only asks whether the agent can do the task. You need regression evals aimed at the harness itself. Run the suite with the new model and the old scaffold, then with the new model and the scaffold removed, and watch for the cases where deleting your own code makes the agent better. Those cases are your harness telling you which of its parts just died. Harness maintenance, done honestly, is as much subtraction as addition, and the teams that win the long-horizon game will be the ones with a deletion discipline, not the ones with the most scaffolding.

There is an architectural move that makes the deletion discipline cheap, and it is worth stating concretely. Keep every model-deficit scaffold behind a flag, dated, with the model version it was written against recorded right beside it. When you bump the model, the flagged scaffolds are your audit list, and the regression suite tells you which flags to switch off. A scaffold built this way costs a line to remove. A scaffold woven straight into the control flow costs a refactor, and a refactor under deadline never happens, which is exactly how a harness silently fills with dead compensation for models nobody runs anymore. The cost of the rot is not the rot. It is having built so that you cannot cut it out.

This sharpens the Model Convergence Pressure thread on the Map. When I named that pattern, I wrote that capability gains were shifting off the model and onto topology, rubrics, memory, and scaffolding. That is right, and it is incomplete. Scaffolding is where value pools, not where it accumulates. The model reclaims it on a schedule you do not set. Plan for the reclamation.

Treat the harness as what it is. Not a foundation, a position. You hold it against the model's limitations, and every release is a payment coming due on a loan you took out to cover what the model could not yet do. The teams that lose will mistake their scaffolding for a moat and let it calcify into a system nobody can safely touch. The teams that win will write every scaffold to be thrown away, and will know, on release day, exactly which half of their harness just turned into a liability.

The harness is the only layer of your stack that depreciates every time the model appreciates.