build the harness now

The next AI capability jump belongs to whoever owns the layer underneath it. In twelve months, your model will be much smarter. The system you use it through will not be, unless you build it yourself.

The labs racing to ship the next jump in raw model capability are also racing to ship the apps you use that capability through. Those apps are convenient. They are also designed to keep you inside them. Your conversations live in their database. Your context lives in their memory feature. Your workflow lives in their UI.

Plenty of people are building harnesses around frontier models right now. Agent frameworks, AI-native IDEs, the new wave of MCP servers, a fresh batch of tools every week. The problem is what kind of harnesses they are building. Almost all of them produce fused systems: model and interface and memory and orchestration bundled into a single product, owned by someone else, brittle to the next architectural shift.

If you want to capture the next capability jump when it arrives, you need a system whose pieces can move independently of each other.

A great model in a bad harness is worth less than a good model in a great harness.

The frontier labs are spending tens of billions of dollars on the model layer. The harness layer compounds faster, costs nearly nothing to iterate on, and determines what fraction of the model's capability you can convert into output. Better orientation around a weaker model beats worse orientation around a stronger one almost every time. And when the next jump arrives, the upside flows to whoever already had the orientation built.

Four functions, four layers, first principles

Any AI system, no matter how it is implemented today or how it gets implemented in five years, has to do four things. It has to take in a goal from somewhere. It has to plan and execute the steps to reach that goal. It has to think, by which I mean make stochastic judgments under uncertainty. And it has to remember information that comes from outside its own weights.

User-Harness-Engine-Data Framework

These are four categorically different kinds of computation. Goal formation is intentional. Orchestration is deterministic. Thinking is stochastic. Memory is storage. You can squint at any AI product on the market and see all four of these functions running, even if the product hides the seams between them.

I have been calling them User, Harness, Engine, Data.

The User (doesn't have to be human) has a goal. The Harness passes that goal to the Engine. The Engine forms a plan: what data it needs, which tools must be called, in what order. It tells the Harness what it needs. The Harness fetches the data from the Data layer, executes the tool calls, and passes the results back to the Engine. The Engine refines, asks for more if needed, and the loop runs as many times as the problem requires. When the Engine has enough, it hands a final answer to the Harness, which relays it to the User.

Notice what this means. The Engine never touches data or tools directly. It only thinks. The Harness never thinks. It only orchestrates and executes. The User never executes. The Data only persists. Each layer does one thing, and every loop writes to the Data layer, which is what makes the system get sharper over time.

The four layers should be modular. None of them should be fused with another.

This is not about how many vendors you use. You can buy three layers from the same lab, if they stay cleanly decoupled, swappable on demand. The enemy is fusion.

The diagnostic is one question: if a better version of any single layer ships tomorrow, can you use it without rebuilding the rest of your stack?

Fail the test, and you're betting on the capability jumps from whoever built your current stack. Pass it, and the next jump belongs to you the moment it ships.

Why this survives the next jump

The objection I keep hearing, and it is the right one, is that any framework like this gets obsoleted by the next architectural shift. Won't reasoning models absorb the harness? Won't long context windows absorb the Data layer? Won't agents collapse User and Harness into a single calling system?

The answer is that the four layers are defined by function, not by the techniques each layer uses internally.

An Engine can use deterministic, harness-like sub-routines inside its own weights. Reasoning models run internal scratchpads. Mixture-of-experts architectures route between sub-models. Draft-and-verify loops shuffle outputs through internal checks. None of that changes what the Engine is. Its core function is still stochastic judgment, and that is the role it plays in the larger system.

The same applies in the other direction. A Harness can use a small stochastic classifier to decide which tool to call. The classifier is probabilistic in technique. The Harness is still a Harness, because its role in the system is deterministic orchestration, and the classifier is just a sub-component of how it does that job.

Function defines the layer. That is what makes the framework robust to the next architectural shift, no matter where the shift happens.

I'm still insecure about the data layer.

If continuous learning gets cheap enough that external memory becomes obsolete, the Data layer collapses into the Engine. I think this is unlikely to break the framework completely, because new information keeps arriving from the world and something has to store and ingest it. But I want to name the risk rather than wave it away.

What it comes down to

If we end up living in a world with something that looks like superintelligence, it will not be a single block of compute. It will be a system of powerful moving parts. The question is whether you are running that system or depending on someone else to run all of it.

There is a window right now, before the next jump, where the cost of building your own harness is low and the payoff is uncertain. That is precisely when you build it. By the time the payoff is obvious, the window has closed and someone else has filled it.

If the diagram in this article isn't valid in 2028, I will have been very wrong. The implementations will move. The functions will not.

Own the harness. Rent the engine. Keep the parts loose. The next jump is coming, and the only thing that determines whether it works for you is what you have already built underneath it.

Originally published on X