What is an operating system for agents?

Agent frameworks are everywhere now. OpenAI ships one; Anthropic, too. Google ships a couple, and Microsoft more than that. Independent open-source frameworks multiply monthly. A developer building agents has never had more harnesses to choose from. Every so often a particular kind of app becomes the thing everyone builds. Back in the day it was IRC clients. A dozen or so years ago it was static-site generators. Lately it is Markdown viewers and agent harnesses. Thus it ever was and will be.

A harness is the control program for an agent. Picture a doorkeeper posted at the single gate between a fast, fluent mind and the world it wants to act on: every move the model makes has to present itself at that gate, and the doorkeeper decides which ones pass, in what form, and on whose authority. Claude Code, for instance, is an agent for software engineering, and its harness is that doorkeeper, separable from the model behind it, from Fable 5 or Haiku 4.5. I sometimes post the same doorkeeper in front of models Anthropic did not build at all.

An operating system for agents is the platform beneath them. It lets many agents, even whole fleets, each with its own harness, run safely, remember, account for their work, and compose.

An operating system for agents makes agents a class of computational object.

These distinctions matter because the industry’s pinch point keeps moving. From 2023 through early 2025 it was model capability, almost exclusively. In 2026 it is everything around the model: who the agent is, what it is allowed to do, what it remembers, who pays for it, and whether anyone can prove what it did.

The explosion of harnesses has not touched those problems. It has concentrated where the tooling and the money already were, in software engineering, which is no surprise. So models, harnesses, and agents are abundant.

Agents you can deploy in a regulated enterprise, at scale? Not so much.

An agent is a model plus a harness

I take the formula from François Chollet, who observes that a harness is a neurosymbolic program. The neural part is the model. The symbolic part is the harness. An agent is the union of both.

I would have assumed it was fairly obvious, but in case it’s not: a million-line codebase (also known as a ‘harness’), running at inference time, orchestrating thousands of calls to a neural network for any given task, is the exact definition of a ‘neurosymbolic architecture’.

— François Chollet

The model maps inputs to outputs. It generates text, classifies, extracts, reasons over context. In some genuinely strange way we do not fully understand, it reasons. Most of the investment and most of the excitement in AI so far have gone to the model.

The harness is the software that decides what the model sees, what tools it can call, how its outputs are validated, whether and when it pauses for human review, what it remembers, and how its work is accounted for. That is the doorkeeper’s job spelled out: everything standing between a raw model API call and an agent that does something in the world.

Where the model once reigned alone, the harness has been gaining. The leverage points are shifting. A 2026 result (Meta-Harness, arXiv:2603.28052) showed that optimizing the harness rather than the model weights produced +7.7 accuracy points at 4× fewer context tokens. And harnesses transfer across models: the same Claude Code that improves one can be pointed at another, and a harness built for one model will often improve a second.

The harness, not the model, is where the marginal return on engineering effort now sits. That is why the harness industry sprang up all at once. Every framework, from the open-source agentic loops to the enterprise platforms, is shipping a harness. They are all, in Chollet’s sense, shipping neurosymbolic programs.

Every one of those programs is drawn at the scale of a single agent: one model, one harness, their union. Run a thousand agents in a regulated enterprise and a second symbolic layer appears above the harnesses, deciding which of them may act, what they may touch, what they remember, and who pays. No harness can be that layer, because each sees only its own agent. That layer above the harnesses is an operating system for agents.

The question is whether any of the frameworks shipping harnesses is shipping one.

The symbolic control plane

A harness controls six things about how an AI creates value.

1. Context assembly is what the model sees: which facts, which history, which tools, which instructions are injected into the context window for a turn. It may be the highest-leverage decision a harness makes. It determines whether the model works from the right information or hallucinates across the gap.
2. Tool dispatch is what the model can do: which tools are available, with what arguments, under what authority, with what handling when they fail. A model with no tools is a chatbot. A model with tools and no governance? Pure liability.
3. Validation decides whether the model’s output is acceptable: type checking, schema conformance, semantic checks, refusal handling. The harness is the verification layer that catches what the model gets wrong before it reaches the world.
4. Human-in-the-loop is when the model pauses for a person: which actions require approval, who approves, how long the pause lasts, what happens on timeout. This is where the line between autonomous and supervised gets drawn.
5. Memory is what the agent keeps: what is written, what is retrieved, what is forgotten, what is shared with other agents. The harness owns the agent’s relationship to its own past, and to the Training Gap, which is everything that happened in the world between the freezing of the model’s weights and now.
6. Lifecycle is how the agent starts, runs, stops, fails, and resumes. The harness is a process manager for an agent’s execution.

Birgitta Boeckeler’s “Harness Engineering” (martinfowler.com, 2026) names three parts of a complete harness: context engineering, or what to show the model; architectural constraints, or what the model is not allowed to do; and garbage collection, the fight against the slow drift that accumulates as the harness and its environment change.

A harness is easy to build. A good harness is hard to build. It is a neurosymbolic program that must be correct, replayable, auditable, and adaptable. The harness industry is real engineering, and the best harnesses are genuinely impressive.

But a harness is not an operating system for agents.

You will say the best harnesses already do half of what follows. They do, for one agent at a time. That is the boundary, and everything that matters lies on the far side of it.

The problems a harness doesn’t solve

A harness solves the problems of one agent. The problems of many agents, of whole fleets of them, in a regulated enterprise, are different.

Identity. Who is this agent, who authorized it, whose surrogate is it, and on whose authority did it act? Every harness answers differently, or not at all. In a regulated enterprise, “the agent did it” is not an answer. What the enterprise requires is cryptographic identity, delegation chains, revocation, and an audit trail that outlives the agent that created it. No harness ships this. Every harness that needs it reinvents it, badly or wastefully, and there is no third option.

Memory. What did one agent learn that another can reuse? What is the agent’s, what is the tenant’s, what is the system’s? How is memory isolated between tenants, garbage-collected, retrieved? A harness that hands one agent a context window has not solved memory. It has deferred it. Real memory is tiered, versioned, provenance-bearing, and shared across agents within a fleet under policy. One tenant’s agent must never read another tenant’s memory; agents within a tenant reading one another, under a protocol with trust ratings and verifiable reasoning, is a capability, not a leak. No harness ships this.

Data integration. The value is in the enterprise’s own data and systems, not in the model. An agent is worth deploying only when it can reach that data under policy, and reach it where the data is governed rather than by copying it somewhere less controlled. A harness wires one agent to a handful of tools. A fleet needs a governed, auditable path to the systems of record, with retrieval that carries the provenance and permissions of whatever it returns. No harness ships this.

Authority. Is this agent allowed to take action X? Not whether the tool call is syntactically valid, but whether, under this tenant’s policy, at this confidence, for this consequence, with this delegation chain, the action is authorized by its owner. The same gate, and the same doorkeeper. A harness can ask the model to grade itself, which is the doorkeeper asking each arrival whether it ought to be admitted. Enforcement is a different thing: a policy decision point that is deterministic, auditable, and separate from the model’s own judgment, because the model is an untrusted semantic sensor, not a source of its own authority.

Recovery. Agents fail partway. A step half-completes, a downstream call times out, a plan turns out wrong three actions in. The question is not whether this happens but what undoes it: which effects roll back, which must be compensated, what state the system returns to, and who is left to clean up when nothing does. A harness retries. Recovery is the harder thing, a defined path back from a partial failure, so a botched run is a repairable event rather than a mess a human operator reconstructs by hand. No harness ships this.

Observability. Did this agent do what it claimed, and can you prove it, replay it, detect its drift? And one step out: what is the whole fleet doing, which agents are running, what they can touch, what they hold, what their lineage and provenance are? A harness can log its own actions, but the log is the harness describing itself, and the state of the fleet is larger than any one harness and not the sum of the separate logs. A sealed, non-repudiable trace that an auditor can verify months later, after the agent is gone and the team has moved on, is not something a harness produces.

Economics. Who pays for this agent’s work, how is it metered and billed and budgeted, and what stops a runaway agent from spending a quarter’s compute in an afternoon while everyone is asleep? A harness can count tokens, but the token count is the vendor’s own word for it. A tamper-evident meter the customer can verify and no vendor can forge is a different matter entirely.

Each of these is an enterprise-platform problem, not a harness problem. Each is something every harness needs and no harness should own by itself. The harness industry’s answer has been to skip them, in the open-source frameworks, or to bundle them into a vertical stack, in the enterprise platforms. The vertical stack works for one vendor. It does not work for an industry.

The platform beneath all the harnesses

An operating system for agents is the platform that provides those seven as services any agent can use and compose, rather than as problems each team or harness builder must solve alone.

A harness is the agent-local control program. It decides what one agent sees, does, and remembers. An operating system for agents does not replace the agent or its harness. It makes both better by giving them a platform to stand on.

This is what makes agents a class of computational object: things that can be supervised, governed, paused, migrated, audited, and resumed, rather than a collection of one-off programs. Here an agent parts ways with a human user. A person uses an operating system; the system does not schedule, pause, or replay the person. An agent is both the user the platform serves and the process the platform manages, and that doubling is one of the concrete ways an agent is not a person.

Look, this is just what operating systems have always done. What changed is the user. The thing at the terminal is now an agent, not a person, and that move from a human user to an agent user, from UX to AX, forces the same rework underneath that filesystems, databases, and mail systems have each been through before.

Why the pinch point moved

So far the industry has been able to skip the platform because the deployments were small, single-tenant, and low-stakes. A harness was good enough. A developer running an agent loop on a laptop does not need durable identity or sealed observability. A single team using a framework for internal tooling does not need cross-tenant memory isolation or a tamper-evident billing meter.

That phase is ending. The industry has spent three years fucking around; now it gets to find out. Agents are moving into regulated enterprises: finance, healthcare, defense, energy, where the stakes are as real as the audits and the liability that come with them. In a regulated environment, the questions a harness cannot answer are exactly the questions that block deployment.

No harness answers these questions; an operating system for agents answers all of them.

What the enterprise gets from an agentic OS

The value of an operating system for agents is not primarily better agents. It is agents you can deploy. The gap between a demo and a deployment is not model capability. It is everything else.

An enterprise that cannot answer those seven questions cannot put agents into production, however good the model is. An operating system for agents closes the gap.

For the buyer, the first thing on the other side of that gap is deployability. Agents go into regulated environments because identity, authority, enforcement, and audit are platform services, not per-agent afterthoughts. Then verifiability: sealed, non-repudiable traces an auditor can check months later, and a bill the customer can recompute from the signed chain and hold against the vendor’s. Then isolation by construction rather than by convention, because the platform enforces the tenant boundary instead of trusting each agent to honor it. Then composability: many agents, many harnesses, one platform, sharing identity, memory, and authority. And then cost control: a meter that cannot be inflated and a budget that cannot be exceeded, in a unit neither side can game.

WunderOS

WunderOS is an autonomic operating system for agents. It is the platform beneath agents and their harnesses, providing identity, memory, data integration, authority, recovery, observability, and economics as services any harness can compose. It does not replace harnesses. It makes agents deployable. That is the whole difference between an agent you can demo and an agent you can deploy, and it is what you want underneath you when the fucking-around is over and the finding-out begins.