The Governor — Why the Agentic Age Needs an Operating System

It holds the money, watches the work, proves it — and undoes it if it lied. The whole idea of an agentic operating system in one picture. This is an educational tour of what that means, and why the word “operating system” is the right one.

Five years ago, on a whiteboard that has long since been wiped clean, I sketched something I called an “LLM operating system.” It was mostly arrows and boxes and a lot of question marks. At the time it was a solution impatiently searching for a problem — the models of the day could barely hold a paragraph in their heads, let alone be trusted to run for an hour unattended — and I did the sensible thing. I filed it under too early and got on with other work.

It is not too early any more.

My instinct for the shape of the thing came from an unfashionable place. Long before any of this, in a previous life, I was part of the kernel team at Microsoft, working on Windows Server 2003. That is a long time ago now — long enough that saying it out loud makes me feel faintly geological — and the work was about as far from a glossy AI demo as it is possible to get. But you do not forget how an operating system thinks once you have spent time inside one. You learn, in your bones, that the interesting problems are never the features. They are the boring, load-bearing questions underneath: who owns the memory, who is allowed to do what, how do you stop a misbehaving program without taking the whole machine down, and how do you know, afterwards, what actually happened.

Here is the thing that made me sit up when agents arrived. In the two decades between that kernel and this one, the fundamental architecture has barely changed. The hardware is unrecognisable and the languages have turned over twice, but the shape of an operating system — the division of responsibilities, the boundaries it draws, the questions it exists to answer — would be perfectly legible to an engineer from 2003. That is not a failure of imagination. It is because the problems an operating system was invented to solve never went away. They simply waited, patiently, for a new kind of program to solve them for.

Agents are that new kind of program.

When programs became untrusted, we built an operating system

Rewind far enough and computers had no operating system worth the name. A program ran straight on the hardware, owned everything, and was trusted absolutely — because there was only one of it, written by the same people who owned the machine. That arrangement survived exactly as long as programs stayed trustworthy. The moment software became something you acquired rather than something you wrote — untrusted, unpredictable, occasionally hostile — computing grew an operating system around it: a layer that owns the resources, meters them, isolates the damage, and keeps the audit trail. The OS exists because we stopped being able to take the program’s word for anything.

Now look at how we run agents in 2026. They execute for hours. They spend real money — a frontier model billing fifty dollars per million output tokens is a genuine hole in the floor if you leave it running overnight. They edit real repositories, send real emails, touch real production systems. They are, by any honest definition, untrusted programs. And most of the stack still runs them the way DOS ran software in 1985: straight on the hardware, on the honour system, with a prayer.

The agent stack itself is surprisingly complete. There are runtimes that drive an agent through its tool calls. There are orchestrators that queue and schedule work. There are billing systems that meter every token after the fact. What has been conspicuously missing is the component that sits above the agent and answers the two questions nothing else in the stack can:

Did the agent actually do the work it claims it did? And what did that cost — was it even allowed to spend it?

Almost every system that comes close is broken in the same direction. It reports spend after the money is gone, instead of bounding it before a token is generated. And it takes the agent’s own word for whether the work got done. For a chat app, that is a rounding error. For an unattended agent working through the night, it is the entire problem.

The right word is “governor”

So I built the thing from the whiteboard, and I gave it the plainest name I could. A run governor. It sits between you and an autonomous agent and does four things a harness never does: it decides what the agent may run as, it bounds what the agent may spend, it proves whether the work was really done, and it undoes the work if it wasn’t.

I insist on “operating system” rather than “harness” for one specific reason. A harness runs the agent — it is a launcher. An operating system decides what the agent may run as, and then feeds what the agent actually did back into what it is allowed to do next. That loop — history shaping permission — is the difference between a script and a system, and it is the whole point.

The analogy is not decoration. Almost every part of the kernel I once worked on has an exact counterpart in the agentic stack, and naming them tells you, with slightly uncomfortable precision, exactly what has been missing.

Classical OS	Agentic OS	The question it answers
a process	a run	what is the unit of execution?
the scheduler	model selection + cron	what runs, on what, and when?
memory limits · ulimit	the budget lease	how much may it consume — enforced before, not billed after?
users & permissions	trust tiers	what is this allowed to do unattended?
the syscall boundary	the ports	how does the kernel stay ignorant of the hardware?
exit codes	the verified verdict	did it actually succeed?
kill -9 + core dump	abort + containment	how do we stop it and undo the damage, recoverably?
the audit log	the append-only ledger	what happened, and what did it cost?

The left column is thirty years old. The right column is the same ideas, wearing new clothes.

Read that table and the déjà vu is the message. We are not inventing a new discipline. We are re-applying a very old one to a program that finally, genuinely needs it.

No fast path

Every way work can enter the system — a human at a terminal, a CI job, a cron firing at 3am, your own application calling a library — converges on the same governor. There is deliberately no shortcut, no privileged “trusted internal” lane that skips the checks. This is a lesson the kernel taught me and the credit-card statement re-taught me: the fast path around the governor is always the thing that burns the money at four in the morning on a Sunday, when no one is watching and the one code path you never hardened is the one that runs a thousand times.

Once inside, every run passes through the same governed lifecycle. It is worth walking slowly, because each stage is a small, stubborn refusal to trust something the industry currently trusts by default.

1 select 2 guard 3 reserve 4 checkpoint 5 run 6 verify 7 contain 8 settle 9 record ↺ earn trust

A RunSpec goes in — a task, a goal, a budget. What comes out is not just an answer, but a record of what it cost, whether it was verified, and what the agent is therefore allowed to do next.

Reserve is the heart of it, and the part most billing systems get exactly wrong. The governor does not check your balance before letting the agent spend — it takes a hold. A lease. The money leaves the available balance immediately, up front, before a single token is generated. The distinction sounds pedantic until you have watched it fail: a check can be beaten by two requests arriving at the same instant, each seeing a balance the other is about to spend. A hold cannot. This is ulimit, reborn. You do not politely ask a process to stay under its memory limit and bill it for the overage; you enforce the ceiling before it can breach it. Money should work the same way, and until now it mostly hasn’t.

Verify is the stage I am proudest of, because it embodies the one idea I keep coming back to across everything I build. Something that did not do the work decides whether the work was done. Three independent tiers, and all must pass: a free sentinel (a run that passed its tests and quietly read your SSH keys did not pass), the repository’s own build and test commands, and finally a model judge — handed a fresh context, never shown the agent’s reasoning, and asked to refute the claim rather than admire it. Uncertainty fails. And crucially, the evidence the judge weighs is observed, never self-reported: the artifacts are the tool calls the system actually watched go past, not the tidy summary the agent wrote about itself afterwards. An agent cannot fabricate an artifact, because an artifact is not something it says. It is something the system saw.

The rest of the lifecycle holds the same line. Checkpoint photographs the workspace before the agent touches a file, so anything can be undone. Contain actually undoes it when a run is refuted — recoverably, via a tag and a stash, so nothing is ever destroyed — because a verdict with no containment is just a logging feature with good intentions. Settle charges the true cost even when the work was wrong, because the tokens were genuinely spent and anything else is a lie in the ledger. And record appends all of it — cost, verdict, routing, rollback — to an immutable ledger.

That ledger is the trick. It is not a log you read after the fact. It is an input. What the agent did yesterday decides what it is allowed to do, unattended, tomorrow.

Trust: slow to earn, instant to lose

Autonomy, in this design, is not a checkbox someone ticks. It is earned, and the terms are deliberately unsentimental.

A brand-new task starts at Tier 0 — every run needs a human to approve it. After ten verified passes it reaches Tier 1, where only genuinely destructive actions still need a sign-off. After twenty runs at a 95%-or-better verified pass rate it reaches Tier 2, and only then may it run entirely unattended — the 3am cron job that actually fires on its own.

And one verified failure drops the tier straight back to zero, however good the running average. Forty clean runs followed by a single failure is still a 97.6% pass rate — comfortably above any reasonable bar — and it resets you anyway. Because a flattering average is no comfort at all when the last run is the one that shipped something broken. There is, by design, no button anywhere in the system that grants trust. The moment a user interface can write “twenty verified passes” into a table without twenty passes having actually happened, the ledger describes nothing, and a record is only worth trusting if the sole thing that can write to it is the truth.

A governor is defined by what it refuses to do

The kernel taught me that the character of a system lives in its refusals, not its features. So it is worth being explicit about what this one will not do. It will not invent a budget for you — the number is required, and a governor that guesses your spending limit has missed its own reason for existing. It will not run something it cannot verify. It will not price a model it does not recognise, because “I couldn’t price this” and “this was free” are different facts, and quietly collapsing them is precisely how an unpriced model runs all night against a cap that never fires — so it fails closed. It will not fail open when the billing service is unreachable, because an unbounded agent is the one client that would actually exploit an accidental unlimited credit line. And it will not grant trust, ever, except as the derived consequence of verified outcomes.

The architecture didn’t change because the problem didn’t

I find something quietly reassuring in all of this, and it is the note I want to end on.

The reason the shape of an operating system has barely moved in the twenty-odd years since I last worked inside one is not that the field ran out of ideas. It is that the underlying problem — how do you safely run something you cannot fully trust — was correctly diagnosed a long time ago, and correctly answered. Own the resources. Meter them before, not after. Isolate the blast radius. Keep an audit trail nothing can forge. Those were the right answers in 2003, and they are the right answers now. Only the program is new — and this new program, an agent that reasons and acts and spends on your behalf, is arguably the most in need of governing of anything we have ever run.

The whole of my portfolio is, in the end, one bet made many ways: that trust has to become infrastructure rather than a press release — something measured, earned, and revocable, not asserted in a marketing deck. The Governor is that bet applied to the agentic layer directly. It makes trust a quantity: a hold instead of a check, evidence instead of assertion, rollback instead of regret. Agents are becoming cheap to run and expensive to trust, and the gap between those two facts is exactly the space an operating system was invented to fill.

Which is why the whiteboard sketch stopped being too early. The models finally grew into the problem the architecture was always waiting for — and the oldest idea in computing turned out to be the newest thing the agents needed.

Interactive companion · opens in a new tab Explore the full architecture, live → A self-contained, interactive walkthrough — every layer, port and stage of a run rendered as living diagrams. The long way round, for when the summary above leaves you wanting the schematic.