Why Agents in the Enterprise Need a New OS

A supplier’s invoice arrives at 9:14 Monday morning. The first agent reads it and pulls the matching PO and goods receipt. A second agent compares line items, quantities, and prices, and routes the mismatches. A third agent prepares the journal entry in the ERP. A fourth agent checks the amount against the approval threshold and either posts it or stops and asks a controller. The invoice is large enough to need a signature, so the entry sits in a queue. The controller signs on Wednesday afternoon. By Thursday the cash has moved.

Nothing about that run of agent work is a chat or a coding task. Rather, it’s a core business process that crosses four systems, four agents, and a person, ending with money leaving the firm. The question that matters is whether the controller or, six months later, the auditor, can sign off on it.

My answer is that the layer which can answer the auditor’s questions isn’t a harness and isn’t even a better harness. It’s an operating system for agents, sitting above the harnesses that do the work.

A harness, said once

I’ve made this point at length elsewhere and in PLRN-027, so I’ll keep it short here. A harness is the layer between a model and the world, owning seven concerns around it: context and state, tools, execution, orchestration, verification, observability, and governance with recovery.

Each of these involves facts that the model cannot safely assert for itself. For example, the model says “it’s done”, and something that isn’t the model checks that it’s really done.

A harness for, say, invoice reconciliation is scoped to a single run or session of execution. Everything in the seven concerns is stated per run: what this run can see, what it may call, where its work happens, who may stop it, etc. When the run ends, the harness ends with it. That isn’t a flaw in any particular harness or a mistake by the engineers who built it. It’s just what a harness is.

So let me say plainly, as a down payment on this argument’s credibility:

a harness is necessary, often the highest-leverage engineering investment available, and nothing in this post proposes to replace any harness.

WunderOS doesn’t replace harnesses, any more than an OS replaces the apps that run on it. The harness and the model together are the agent that does the work.

What owns the facts that the work produces?

What back-office automation actually is

The three big areas of agentic AI are (1) software engineering, (2) personal productivity, and (3) back-office automation in the enterprise. The differences between them are large. Back-office work isn’t a harder prompt, and it isn’t a programming job wearing a suit.

What makes back-office automation tasks distinct?

• It’s a stateful process over systems of record, not a one-off reply.
• Many agents of different jobs act on shared data, often at the same time.
• Humans appear at defined gates: approvals, exceptions, escalations, sign-off.
• Money, entitlements, or regulated records move at the end and, in some cases, at defined stages of the process.
• Corrections happen routinely: a posted entry is reversed, a claim reopened, a customer record is corrected weeks later.
• Partial failure is the normal case, and it must be repairable, not merely retried.
• A run outlives the session that started it, the weekend, a model release, and the team that deployed it.

That last trait is the one that coding-agent playbooks don’t prepare you for. A coding agent runs one task for one user and ends. Back-office automation is a family of tasks on shared data under one set of rules, each outliving the session that started it. The coding playbook doesn’t transfer, because the playbook assumes a single harness serving a single purpose, and back-office work is not a single purpose.

The facts agents can’t own about themselves

Here are seven fact-patterns a back-office run depends on, none of which fit inside an agent run.

1. Identity and authority. Which agent acted, on whose behalf, under what delegation, and on whose authority did the money move?

In a regulated firm, “the agent did it” isn’t even a bad answer. The delegation chain has to outlive the agent that exercised it and has to be revocable after the fact. See PLRN-014, authority without assertion, and PLRN-008, taint tracking.

2. Granular accounting control. Whose budget paid for which step, in the firm’s own currency, in a form that can be recomputed from the signed chain rather than taken from a vendor’s invoice.

A token count from a service you don’t control is an assertion, not a measurement. See PLRN-024, firm agentic economics and PLRN-006, provenance by construction.

3. Audit continuity. What did the system know when it decided, and can someone who does not trust the system check that?

Three weeks after the invoice is paid, the supplier issues a credit note and the PO price is corrected. The auditor asks, what price did the matching agent see when it routed the invoice? Three things together make the decision auditable. First, corrections append and never overwrite, and each fact carries two times: when it was true in the world, and when the system knew it. Second, the record of the agents’ work is sealed into a tamper-evident chain that the auditor verifies offline, on their own copy, without trusting the system that produced it. And, third, the model’s output is recorded where it entered the process, so every step after it can be re-derived exactly. Neither a harness nor a log file gives these by themselves. See PLRN-018, bitemporality, PLRN-006, provenance by construction, PLRN-009, recording the parse, and the post One clock loses the decision.

4. Policy stability. Does the rule that bounded the first run still bound the thousandth?

No run may widen the rule that bounds it, and a harness upgrade between Tuesday and Thursday may not silently change enterprise policy. See PLRN-000 on sovereignty and verification.

5. Cross-agent memory. Do two agents on the same account see the same account?

Two agents working on the same customer account on the same day should see the same customer data and the same account state. Memory is a service of the OS, not a possession of the agent, and it stays coherent across a fleet only if a layer beyond any single run or agent owns it. See PLRN-001, vectorspaces and PLRN-016, the agentic data enclave. The OS delivers that memory by placing the relevant facts in each agent’s retrievable context, so the agent finds them without any change to its prompt or its weights. See PLRN-004, control agents without modifying them.

6. Recovery. When a run fails halfway, what state is the world in?

A run that failed halfway on Friday night is undone or compensated along a defined path, so Monday morning’s state is something someone can reason about, not a reconstruction that a human has to do by hand. See PLRN-005, substrate recursion and PLRN-030, agents are users and programs.

7. Governed data access. Where does the agent read the data, and under whose policy?

Agents reach systems of record where the data is governed, under policy, rather than by copying it into a place less controlled than where it normally lives. See PLRN-016 and PLRN-014.

Every one of these has a lifecycle radically different from that of a harness or an agent. Each holds or fails while a run is mid-token, mid-plan, mid-execution, and in the intervals between runs. The audit log appends while the model is generating. The budget decrements while the planner burns tokens. The scheduler decides whether a run continues while the run continues. A harness cannot govern a fact outside its scope. It can only report, or assert, one.

A better harness cannot absorb these facts

There are four reasons that harnesses are insufficient, and each follows from what a harness is.

1. Scope. These facts hold between runs as well as during them. A harness that ran on Tuesday may be gone on Thursday, either upgraded, redeployed, or replaced. Evidence has to outlive the system or agent that produced it, and that requires a substrate, not a log file. This is the thing no harness can see.
2. Enforcement. Asking the model whether an action is allowed is the doorkeeper asking each arrival whether it ought to be admitted. Policy enforcement must be deterministic and separate from the model’s own judgment, because the model is an untrusted semantic sensor, not a source of its own authority.
3. Neutrality. When two runs contend for the same record, neither run’s harness can arbitrate without bias. The operating system is the only neutral party in the room.
4. Shared ownership. A harness that tried to own all seven of these facts would be a second, ad hoc operating system, and every team would build its own badly. The value of an operating system is that it is shared, so each fact has one owner and one set of rules. The harness stays the local control program. It does not become an institution.

What the agent OS makes possible

Each item below removes a blocker that currently keeps agent automations out of production for critical functions.

1. Deployability. Agents reach production in regulated environments because identity, authority, enforcement, and audit are platform services, not per-agent afterthoughts. What stops a pilot from becoming a deployment is the absence of these services, not a gap in model capability.
2. Verifiability. Sealed, non-repudiable traces an auditor can check months later, and a bill the customer can recompute from the signed chain. See PLRN-006, provenance by construction and PLRN-009, recording the parse.
3. Isolation by construction. Tenant boundaries enforced by the platform, not by convention or by an agent’s good manners. PLRN-016.
4. Composability. Many agents, many harnesses, one platform, sharing identity, memory, and authority. Harnesses stay interchangeable, which is what makes competition among them useful rather than fatal. In HarnessTax (Pan et al., UC Berkeley, 2026), across Claude Code, Codex CLI, and Pi on SWE-bench Lite and Terminal-Bench 2.0, the average harness effect on success stays within 2% on the first benchmark and about 5% on the second, but the same model can cost up to five times as much in one harness as in another. Pi, a minimal harness with four tools, reaches the Pareto frontier on both benchmarks.
5. Cost control. A meter no vendor can inflate and a budget no agent can exceed, in units neither side can game. PLRN-024.
6. Work that survives. Failed and paused work picks up where it stopped, with defined compensation, so that a Thursday-night failure is a repairable event rather than a mess a human reconstructs. PLRN-005, PLRN-011, saga, and the social tier for human exception handlers (PLRN-017).

What stays in the harness

An OS for agents isn’t a power grab and drawing its boundaries explicitly is part of my approach here. The harness keeps: context assembly for the case at hand; tool choreography and argument shaping; validation of model output shape and semantics; when to pause for a person within the run; and model-specific tactics and prompt work. It also keeps the four gaps named in The missing box: what the agent may see, what it takes when it leaves, what survives a crash, and what you can prove it did…all handled locally by the harness, governed globally by its OS.

The marginal return on engineering effort sits in the harness, where it belongs. The OS raises the floor under that work, so no team has to rebuild the platform underneath.

A test you can run this week

If you have to answer any of the following questions with some form of “we would have to assemble it by hand,” you’d benefit from an OS for agents.

1. On Tuesday the 14th, agent X touched record Y. Whose budget paid, and under whose authority was it acting?
2. A run failed halfway on a Friday. Can you say exactly what state Monday’s run resumes from, and which effects were undone?
3. Two agents worked the same customer today. Did they see the same customer?
4. The auditor arrives in Q3. Can they verify the sealed trace without the team that built it?
5. Did a harness upgrade between runs change the effective policy?

Close

A harness made agents useful. An operating system will make them deployable, and in regulated back-office automation the two do not compete. There is no demo without the harness and no deployment without the operating system. The industry’s dates have been with the model, but the marriage has to be to the owner’s policy and records.

WunderOS is the platform we build for this. It is the layer beneath agents and their harnesses, and it provides identity, memory, data integration, authority, recovery, observability, and economics as services that any harness can compose onto. It doesn’t replace a harness. It makes the harness’s work stand up in a regulated firm. A harness runs an agent. An OS for agents makes them deployable, auditable, and something you can stand behind.