The model is a component. The harness is the product.

I want to write about a decision we made three and a half years ago that keeps proving itself more right, not less: making Cortex model-agnostic at its core. Not just abstractly — actually building the harness so that swapping models is a routing decision, not a rebuild.

Every quarter I have someone ask me some version of “which model does Cortex use?” It is the wrong question, and I want to explain why.

The observation that changed how we think

When we run code review through Cortex, we can watch the same task complete against different models. Not because we are running academic experiments — we actually run production code review across our customer base and internal codebases, at real scale, on real repos. So we see the actual behavior.

Here is what we see. Code review with the current top frontier model comes out to roughly $70 per review in our harness. That is not cheap, and the results are excellent — that model is genuinely good at this task. When we run the same review against a different frontier model, in the harness we originally built for it, the cost is $5–6 and the quality is meaningfully lower. Same task, same code, same reviewers reading the output.

Then we did something interesting. We tuned our harness for the second model — used a code-review workflow closer to what the leading model’s harness uses — and re-ran the review. The cost dropped to about $3. The quality improved substantially. Not to full parity, but much closer than the raw price gap suggested.

The gap between “$5–6 with default workflow” and “$3 with tuned workflow” is the harness doing work. Same underlying model. Same code being reviewed. Just a better-designed system around the reasoning.

That single number changed how I think about the field.

What is actually happening

The way these models get post-trained is not a mystery, at least at a high level. Model developers build reinforcement-learning environments that teach the model to solve specific tasks — code review is one, refactoring is another, test writing is another, and so on. The model develops a gravity toward certain workflows: sequences of reasoning steps and tool calls that solve the task well. When you run that model inside a harness that lets it find those workflows, it performs beautifully. When you run it inside a harness that fights those workflows — different tool descriptions, different system-prompt conventions, missing primitives — the model performs badly. Not because it is a worse model. Because the harness is preventing it from doing what it was trained to do.

The insight that follows is important: finding those good workflows is the harness’s job. And a harness that can find them across models — that can learn what the leading models were shaped toward and give each one the workflow it thrives in — genuinely improves every model it runs. This is not marketing language. It is what we watch happen when we tune a harness against evaluations.

There is another side of this that is worth stating plainly. Model labs building their own harnesses have an inherent disadvantage: they are optimizing for their own model. They cannot pull other models in to test whether the workflow they have converged on is actually optimal or just locally optimal for their weights. A general harness team can. We can hill-climb across all the frontier and open models simultaneously, and we can watch which workflows survive across the whole field. The workflows that survive are the ones the whole industry converges toward.

Why we made this decision three and a half years ago

The economic argument is straightforward and immediate. In the enterprise, subsidies are not sustainable. Frontier models are genuinely expensive to run, and the pricing you see today reflects a market where the labs are competing aggressively for developer mindshare. Enterprises pay something closer to real cost, and the numbers can be brutal — some deployments run tens or hundreds of millions of dollars in annual model spend.

If you can get similar performance from a cheaper model — because your harness gives it the workflow it needs — the math is not close. It is not “5% better.” It is “the same quality at a third of the cost.” And when you multiply that across an enterprise deployment, the case for a model-agnostic harness becomes obvious.

The strategic argument is subtler and, to me, more interesting. Model capability is not a stable moat. It moves quarter to quarter. Whichever model is best today is not necessarily best next quarter, and building an entire delivery system on top of one model means rebuilding whenever the frontier moves. A harness that treats the model as a component — swappable, tunable, benchmarkable — captures the value of every model improvement without paying the switching cost.

A spicier take: where this is heading

There is an idea in machine-learning research called the Platonic representation hypothesis. It is worth reading in full, but the compressed version is this: when you train models with different architectures on similar data, they converge toward similar internal representations. Different roads, same destination. The compute you spend and the architecture you choose determine how efficiently you reach the destination, but the destination is roughly the same. Intelligence has a shape, and models discover that shape rather than invent it.

If this is right — and there is meaningful evidence that it is — then the differences between frontier models are compression artifacts. Different models find slightly different local optima on the same underlying landscape. Over time, they converge. And once they converge, distillation becomes essentially unpreventable — the shape of intelligence, once discovered, is copyable.

I think the frontier labs know this. And I think it explains some of the behavior we are seeing around regulatory positioning, model access restrictions, and the aggressive push toward proprietary application layers. If the model itself is not a durable moat — if capability inevitably diffuses — then the labs need to find something else that is. Applications are one answer. Regulatory capture is another. Neither of those is a comment on the technology; both are rational business responses to an underlying reality about the nature of intelligence.

I am not certain the Platonic hypothesis is right in full. It is a strong claim and there is legitimate debate. But even a weaker version of it — models converge more than they diverge, over long enough timescales — is enough to make the model-agnostic bet the correct one. If the destination is roughly shared, you want to be the layer that runs on all the vehicles, not the one that owns the vehicle everyone will eventually copy.

Where humans stay

I want to be clear about one thing before I finish, because I think it is the piece that gets lost in every conversation about AI delivery.

Model-agnostic does not mean human-optional. It means the reverse. The more the model becomes a swappable component, the more the durable value sits in the layers humans build and maintain: the workflows encoded into the harness, the standards codified into skills, the verifiers that decide when work is done, the judgment gates where humans review evidence and approve.

We have an engineer named Alvin who spends almost all of his time building lint and type-check rules — increasingly elaborate ones — to prevent our agents from making increasingly complex mistakes. That role did not exist five years ago. It will not go away in the next five. If anything, we need more Alvins, and more roles like his: people who lint the architecture of the product, encode the opinions of the company, and build the deterministic feedback that lets agents succeed.

That is what makes me bullish on humans in the loop for a very long time. Not because agents are weak. Because the more capable they become, the more the value moves to the layer that governs them — and that layer is a human layer.

The bet

Cortex is a bet on this shape of the future. That the model is a component, not the product. That the harness is where the durable engineering lives. That model-agnostic isn’t a hedge — it is the correct architectural choice for enterprises that intend to be running AI-assisted delivery for the next decade, not the next twelve months.

We could be wrong. If the frontier labs pull off a hard takeoff — if one model jumps so far ahead that nothing else matters — the game changes and we play a different one. I do not think that is what happens. I think intelligence continues to converge, cost pressure continues to matter, and the winners are the teams that own the harness, the workflows, and the human judgment layer around whatever model happens to be the best this quarter.

The model is a component. The harness is the product.

“The more the model becomes a swappable component, the more the durable value sits in the layers humans build and maintain: the workflows, the standards, the verifiers, and the judgment gates. That is where the engineering lives now.”