What question is an "agent harness" the answer to?

My favorite philosopher of history, R.G. Collingwood, gave the rule I reach for whenever a new piece of jargon shows up, that is, daily.

In Collingwood’s Autobiography he argues that you can’t tell whether a statement is true or false until you know the question it was meant to answer. A proposition is not true in the abstract. It is true (or false) as an answer to a question; and, further, if you don’t know the question, you don’t really understand the answer. He pushed this further; to understand what someone meant historically, that is, their significance, you have to reconstruct the problem they were trying to solve, and in a sense re-enact the thinking that led them to their actions, form of life, and son. History is a form of empathy as is historical understanding, in other words, understanding.

I have found nothing more useful than Collingwood’s rule for cutting through technology language, and “agent harness” is a word that needs cutting.

It is everywhere now, and it is stuck on almost anything: a framework, an orchestration layer, a control loop with a vector store attached. By Collingwood’s rule the confusion is not really about the words. People are answering different questions with the same word or phrase, and so they talk past each other. The argument about whether something “is really an agent harness” cannot be settled until you ask what question the term is the answer to.

What question is an agent harness the answer to? A fair one, as it happens: how do I make this one agent do this one thing better, and more reliably? Get it running, wire it to its tools, tighten the loop until it holds.

The tooling we call an agent harness answers that question, and often answers it well enough.

A harness isn’t nearly enough

It is not the question an enterprise is asking or will be asking in the long term.

Reconstruct the enterprise question and it is larger on every axis: not how do I make this one agent do this one thing; but how do we make a family of agents do a wide range of things, reliably and acceptably, under the audit, compliance, and risk requirements that are ours and no one else’s?

The two questions share a word, reliably, which is why an agent harness looks like it ought to grow into the answer. It cannot, however, because the enterprise question carries a demand the harness question never had: acceptability, across many agents at once.

The two failures

Try to answer that question with a harness anyway, and you get one of two failures. Either you build a narrow agent, focused on one job, and watch it turn brittle the moment the job touches memory, identity, rollback, audit, or recovery, because now the agent has to carry all of that and is no longer focused. Or you build the everything agent, usually a sprawl of agents wired together, and watch the whole mess turn slow and unreliable because it’s doing too much to be very good at any one thing it does.

Either way, the enterprise’s agents team ends up building the same plumbing underneath every agent, and it becomes, by hand and forever, the part of the system that was supposed to be managing the agent on behalf of people.

Strip the enterprise question to its core and this is what remains.

Who or what manages the agents?

Once that question, the enterprise question, is on the table, the answer names itself in a loud voice. An agentic OS is the thing that manages the agents so the human team does not have to. And the word for a system that manages itself, that configures, heals, optimizes, and protects without a person in the loop for the ordinary case, is autonomic.

So: an autonomic agentic OS. The agents do the work. The operating system manages the agents.

The reason this is the right answer and not just a tidy one is what it earns. If the management loop keeps the language model off the hot path, then execution is deterministic, you can replay it and prove what happened, and the bill tracks the work done rather than a sampling loop whose length nothing controls.

You cannot budget what you cannot bound, and you cannot audit what you cannot replay. That is the difference between something that demos well and something you can run in a regulated enterprise.

It is also, not by accident, the difference between the phase we have been in, where the point was to make one agent do its job well, and the phase we are entering, where the cost, the audit, and the three-in-the-morning page are yours.

This is the bet I am making with WunderOS, and it is why I left the comfortable version of this problem behind to build the substrate underneath it. I spent years at Stardog building enterprise knowledge graphs for exactly these buyers, in exactly these regulated industries, and the thing they never had was a way to let software act on their data that was reliable, provable, and theirs.

Agents make that need acute. An autonomic agentic OS is my answer to it.

Next time I go deep on the first place we are putting this to work, the Agentic Data Enclave. The short version is that in the agentic era you bring the agents to the data, not the data to the cloud, and the data room you know from a deal has to be rebuilt for what now walks in.