The harness is an asset, the model is a consumable

What the word harness actually means

Start by clearing up a confusion that costs real money in tenders. The agent is the application: the business service that answers a request, drafts a note, processes a case. The harness is its operating system: it orders the calls to the model, manages the context passed to it, executes tools, isolates workspaces, recovers from errors, caps budgets and logs what happened.

Two organisations using exactly the same model with two different harnesses do not get the same results, nor the same costs, nor the same level of reliability. The gap is not marginal: it is of the same order as the one that separated two generations of models three years ago.

This confusion explains a good share of the disappointment that follows a successful pilot. The pilot validated a model, and scaling runs into a harness nobody ever specified. One simple test tells you which side your project is on: ask how long it would take to serve your use cases with a different model. If the answer is measured in days, you have a harness. If it is measured in quarters, you have an integration.

Three years, three shifts in where the effort goes

In 2023, engineering effort went into the prompt: phrasing the right request, in the right order, with the right examples. In 2024, it moved to context management: choosing what goes into the window, what is summarised, what is left out, and under what policy. In 2026, it goes into designing the loop.

The difference is one of kind. Prompt and context concern a single call; the loop concerns the sequence of calls, what happens between them, and how the system recovers when one of them fails. The logic of this shift is simple: as models get good, the limiting factor stops being their capability and becomes the organisation of their work.

The summer of 2026 saw five competing harness architectures published in three weeks. When five independent teams publish on the same problem at the same moment, it is not a coincidence: it is the sign that a subject has left the laboratory and entered industrial engineering. The most radical principle in that series, pushed by DeepSeek, is to make everything a plugin, including the loop itself: the core imposes no capability, it simply resolves the dependencies between the components declared to it. That is an architectural position, and it is instructive for a buyer, because it says that even the decision loop must be replaceable.

The levers of the loop

Five levers account for most of the gap. Scheduling decides the sequence: when to call the model, when to call a tool, when to stop. It is the most profitable and the most neglected. Sub-agents delegate a bounded task to a separate context, from which only the result comes back, which prevents pollution of the main context, the leading cause of degradation in long-running agentic systems. Workspace isolation gives each task its own sandbox: its files, its permissions, its lifetime. On-demand skill loading avoids describing to the model everything it might possibly do, which cuts cost and improves precision. Persistent memory, finally, keeps what has been learned between runs: it is the lever that turns a system starting from scratch every time into a system that improves.

A change of approach comes on top of that. The first generation of agentic systems exposed a list of tools to the model, leaving it to pick the right one. That method runs into combinatorial explosion as soon as the number of tools passes a few dozen: the model spends most of its effort choosing rather than reasoning. The approach now taking hold is to let it write code that calls those tools, inside a controlled execution environment. The price is a serious isolation requirement: letting a model write code without a strict sandbox is not an architecture, it is an incident in preparation.

Why the harness is an asset and the model a consumable

A model has a useful life of around eighteen months. It will be replaced, by a better one, by a cheaper one, or by both. Nobody builds an asset base on a component known in advance to be obsolete before the next planning cycle.

The harness, by contrast, accumulates. The tool descriptions written for your internal systems, the procedures that encode how your organisation handles a case, the evaluation sets built on your real data, the fixes added after each incident, the memory of cases already handled: all of that is specific work, expensive to produce, and found nowhere else.

The purchasing question that follows is simple. If your business logic is dissolved into instructions sent to a proprietary model, changing supplier means rewriting everything, and the exit cost is prohibitive. If it is carried by a harness whose code you control, changing model is a configuration exercise. The same spend, committed at the same moment, produces a dependency in one case and an asset in the other.

Three independent choices, and good news for Europe

The harness can be Chinese in origin, the model European and the deployment sovereign. These three choices are independent of one another, and that is precisely what makes interoperability strategic rather than technical. The recommendation that follows is not to pick the right runtime: it is to refuse to depend on a single one. A harness that requires its own model supplier, its own tool store and its own memory format is not an abstraction layer, it is a new dependency presented as the solution to the dependency problem.

For Europe, this is a piece of good news that is rarely heard. The layer where performance is now decided is ordinary software engineering, without a capital barrier comparable to training. It is written, tested, audited and deployed like any critical system. It is ground on which we have teams, methods and a culture of open software, and it is very concretely the layer we produce as an open common.

It is also the layer that determines the reliability of agents running without direct supervision, and therefore the layer that conditions their acceptability in public administration and in exposed companies. An auditable loop, where every decision is logged and replayable, is not merely good engineering practice: it is the condition for documenting a system in the sense of the AI Act, and for answering the simplest and most formidable question an inspector can ask, namely why this system did that.