An AI application needs a harness. An enterprise fleet of agents needs an operating system. I want to say exactly what the difference between agent harness and agent OS is, because it is not chiefly the difference between small and big. The difference is what happens to the authority of a harness and to what it owns when there is more than one agent.
What a harness owns
Charles Holloway gave a talk at Colorado Startup Week this week called Build Your Own Harness. It contains the clearest definition of a harness I’ve seen. I take it here as given.
An agent is a model plus a harness; maybe better: a model (the horse) wrapped by a harness (bridle, reins, saddle, martingale, and so).
- A model is fixed weights, a visible context, tokens in, tokens out, one prediction at a time.
- The model is not files, tools, memory, other sessions, or anything that survives a call to the model.
The harness is everything you add to make the model useful, the layer between it and the world. A harness is both a model-controller and a world-adapter. Every capability you think of as the agent’s is something you built, bought, or inherited.
Holloway then inventories the harness as seven authorities around a shared model:
- context and state,
- tools,
- execution,
- orchestration,
- verification,
- observability, and
- governance with recovery.
His organizing rule is that each authority owns a fact the model cannot safely assert.
That’s what it means to say the harness is both model-controller and world-adapter. The model says X and something that isn’t the model has to see if X is the case:
- The model says “it’s done”; something outside the model must check that it is.
- The model reports its history; something outside the model must have recorded it.
If the model’s claim is the only evidence, then there is no evidence. Effectively there’s no harness at all.
An agent’s claim that “the cat is on the mat” is true if and only if something that isn’t A verifies that the cat is on the mat.
That is the right definition and the right test. Notice what it is a definition of. Every one of the seven authorities is stated relative to an agent run, i.e., a discrete session of agent activity and, ideally, useful work.
- What this run can see.
- What this run may call.
- Where this run’s work happens.
- Who may stop this run, and so on.
The harness is a control plane for one agent doing one job, and Holloway says as much: workers execute, the harness decides.
Now put two hundred of them on the same enterprise data.
The parts of an operating system are answers to contention
An operating system is like a government for computers and programs: in each case, a contention-management function is required because M actors make N claims on resources where there are fewer resources than there are claims on them, i.e., where there is scarcity. In short, no part of an operating system was invented because only one program needed it.
A program that has the whole machine to itself needs no scheduler, since it runs whenever it wants; no memory protection, since there is nothing to protect it from; no filesystem, since it can put bytes wherever it likes and remember where; no accounting, since the bill is its owner’s; and no distinction between supervisor mode and user mode, since there is only one authority in the box and it’s the program.
Where there is no contention for resources, no authority should be.
For the first decade or so of computing that was the whole arrangement. Each program carried its own loop, its own input and output routines, its own conventions for what was where. Each program had something akin to a harness, and the harness was the program’s.
The operating system appeared when two programs wanted the same machine at the same time because two users wanted to run programs at the same time. Operating systems arise exactly when resources become shared and are less numerous than resource-claims, that is, in the presence of scarcity.
Every part of an operating system answers a contention that doesn’t exist for a single program.
- The scheduler answers contention for the processor.
- Memory protection answers contention for addresses.
- The filesystem answers contention for names.
- Accounting answers contention for the bill.
- Supervisor mode answers contention for authority, which is the one the others depend on, because a scheduler that any program can rewrite is not a scheduler.
An operating system is not a big harness. An operating system is a different kind of thing, which exists outside every program in order to manage their contention over limited resources.
The seven authorities for a fleet of agents
So this all becomes clearer if we take Holloway’s seven one at a time and ask what each becomes when there are two hundred agents (to say nothing of two or twenty thousand) instead of one.
Context and state, for one agent, is a window and a memory. The memory is the agent’s own, which it reads and writes, compacts, and which nothing else touches.
For two hundred agents working the same enterprise data? Memory is shared by construction, since two agents underwriting the same loan are looking at the same applicant, and the question is no longer what this run can see but which runs may see it. That is a permissions question and, as I argued in July, agentic memory, as harnesses build it, has no permissions to check. The operating system’s name for a shared store with isolation between its users is memory management. The part of it that says whose bytes these are is protection.
Tools, for one agent, are a list with schemas. For two hundred agents they are two hundred lists, and the enterprise question is whether the combination of those lists is the set of things agents may do to enterprise resources. Nobody wrote that combination down. It exists only as the sum of two hundred index cards that drifts every time a card changes. The operating system’s name for the closed set of things a program may ask the machine to do is the system call table, and the name for who may ask for which is a capability.
Execution, for one agent, is a worktree or a sandbox. Holloway is careful here and correct: isolation does not make an agent safe, it makes the damage bounded and knowable. Only the second of those is something you can design. For two hundred agents the bound on damage is the sum of two hundred bounds, and the question of what the worst run can reach becomes the question of what the worst run can reach in every other run. The operating system’s name is the process, an address space with a boundary the program cannot cross just because it wants to.
Orchestration, for one agent, is a sequence: plan, then implement, then verify, then stop. For two hundred agents it is who runs now, who waits, at what priority, under what budget, and who gets stopped when the budget is gone or a higher-priority run arrives. That isn’t sequencing, it’s scheduling. A scheduler is the thing an operating system is most often mistaken for being reducible to.
Observability, for one agent, is a journal per run, append-only, so that a crash is reconstructable rather than a guess. Holloway’s own system has exactly this. For two hundred agents there are two hundred journals. An auditor doesn’t ask two hundred questions. The auditor asks only one: what did your software see and do with this mortgage applicant’s data between the sixth day and the fourteenth. Answering that from two hundred per-run journals is a join nobody has written, over formats nobody agreed. The operating system’s answer is a single record with one clock, which is why the filesystem and the log are kernel services and not conventions each program is trusted to follow.
Verification and governance go together, because fleet-wide they become the same thing. Which no harness even so much as contemplates. Holloway’s rule for the self-improving case is that the policy that bounds a run must sit outside what the run can rewrite. His reason is that an optimizer that can widen its own permissions will widen them. Now read and apply the rule fleet-wide. The policy that bounds every run must sit outside every run. Whatever sits outside every run is, by definition, shared by all of them. Whatever is shared by all of them and cannot be rewritten by any of them is the definition of supervisor mode. The gate that decides whether a result ships, and the authority that decides whether a run may start or must stop, are not two hundred gates and two hundred authorities. They are one or they are policy drifting silently in two hundred places, which Holloway’s own matrix lists as the failure when governance has no owner.
Two facts a fleet of agents adds that a harness has no place for
There are two facts an operating system must own for which a harness has no row in its schema.
The first is accounting. Whose budget did this run spend. For a single agent the answer is trivially yours, so no harness ever grew a slot for it. At two hundred agents across four business units the bill is a fact the model cannot assert, the agent cannot assert, and the per-run journal records only in the currency of that run. The enterprise wants it in the currency of the enterprise.
The second is identity. Which agent is this, acting for whom, with whose authority to access resources? For a lone agent the answer is you, running under your login, and the harness inherits your identity without noticing it has done so. At two hundred the agent’s identity is a distinct thing from any person’s, it outlives any session, and the auditor’s question is unanswerable without it.
Both are facts that exist only between agents. Neither is a harness concern, because there is no between in a harness.
Why a harness cannot grow into an operating system
It’s tempting to think that a harness with enough authorities added becomes an operating system for agents, the way a large enough program becomes a platform, if you’re lucky. But it doesn’t, for a structural reason that doesn’t yield to more effort.
A harness lives inside the agent run since, otherwise, it couldn’t do its job of mediating the world to the model and controlling the model’s effects on the world in some limited way. It’s exactly the harness’s insideness that makes it a harness: the layer between model and the world, configured by this agent’s index card. Holloway’s control plane—which admits work, chooses a worker and a budget, enforces policy, and records what happened—exists for a project and its runs. Multiply it by two hundred and you have two hundred control planes. But if you have two hundred control planes, then of course you have zero effective control plane. The fact that matters, whether or not the fleet as a whole is inside policy, is not a fact any of them can assert. Something outside all of them must own all the facts that matter to effective control.
That something is not a bigger harness. It is the thing the harnesses run on.
Consider an analogy: Unix isn’t libc and libc isn’t Unix, despite the fact neither is, in some very real sense, imaginable without the other historically. The C runtime grew every convenience a program could want and never became the kernel itself, because the kernel’s job is to be the thing the program cannot rewrite, and a library is by definition something the program links in. The authority test settles it. If the fact is “this fleet is within policy,” the owner of that fact cannot be any member of the fleet, nor a proper part of any member of the fleet.
The bet
So: an operating system for agents. The agents do the work. The operating system manages the agents, and it manages them by being the thing outside every one of them that schedules, isolates, records, accounts, and says no or yes, keep going or stop, now or later.
That is what WunderOS is, an operating system for agents. Holloway’s talk is the best account I know of the layer an application needs, and it is the layer an operating system must assume and then stand outside of. The enterprise question, how do we make a family of agents do a wide range of things reliably and acceptably under audit and risk requirements that are uniquely ours, is a question about the between, and the between is where an operating system lives.