Making the OS an agent host is the easy part

In June we wrote that "AI operating system" is well on its way to meaning nothing, and set out a test: if a product does not provide identity, scheduling, memory, I/O and isolation to other software, it is an application, not an OS.

The argument has since arrived from the other direction, and at considerably greater scale. At Build 2026, Microsoft set out Windows as an operating system for AI agents, and the framing has been picked up widely — including a fairly emphatic reading that Microsoft has simply made the AI OS real.

Windows is the loudest example rather than the only one. The same re-architecting is under way across desktop environments generally — the primitives are appearing on macOS and in the Linux desktop stack too, with less fanfare and on different timelines. Read it as an industry-wide shift that one vendor happened to name, not as a Microsoft strategy other people will have to react to.

Read the primitives, not the announcement

The interesting part is not the positioning. It is which primitives are being added: background scheduling, local model routing, shell execution, and persistent agent state.

Notice what is absent from that list. There is no new model, no better reasoning, no capability the chat window did not already have. Every one of those four is a piece of plumbing that operating systems have provided to applications for forty years, now being provided to software that thinks.

That is the whole argument, and it is now being made by a platform vendor rather than by us. An agent that can be scheduled, that can hold state between runs, that can execute, and that can choose where a model runs is not an assistant. It is a process. The moment it is a process it needs everything processes have always needed: a scheduler, an owner, a memory, and a boundary.

It also marks the end of the chat prompt as the primary interface, which is worth saying plainly. Asynchronous work does not have a prompt. It has a queue.

Which is the easy part

None of the above is difficult to agree with, and the industry has now agreed with it. The hard part is the sentence that follows: an agent host is a trust boundary, and it belongs to whoever ships it.

Three things change on the day the OS becomes the runtime, and none of them are solved by the runtime existing.

Persistent agent state is a new class of data, and nobody has a policy for it. The point of it is that it survives the session. That makes it a record of how someone works: what they asked for, what was done on their behalf, what the agent concluded and kept. In most organisations that is personal data sitting under a retention schedule which has never heard of it. It needs to be listable, exportable and deletable, and today it is usually none of the three.

Background execution breaks attribution before it breaks anything else. We have written before that you cannot audit what you cannot attribute. Scheduled, asynchronous work makes that materially harder, because the human who authorised the work is no longer present when it runs. "The agent did it" is not an answer. Which agent, acting for whom, under what delegation, is — and that has to be in the schema before the event, not reconstructed afterwards.

Local model routing is a claim, and claims should be checkable. Local execution is the right default for anything sensitive. But local, asserted by the same vendor who operates the cloud you might otherwise route to, is a promise rather than a property. The question to ask is not whether a local mode exists. It is what you would look at to prove nothing left the device, and whether you can look at it without the vendor.

What we would ask a vendor

Four questions, all answerable, none rhetorical:

1. Where does persistent agent state live, and what deletes it?
2. When a scheduled agent acts, what record names the human it acted for?
3. In local mode, what leaves the device — including telemetry, indexes and crash reports?
4. Can I remove this layer and keep working?

The fourth separates a platform from a dependency. It is also the one we hold ourselves to: e21 OS is deliberately seven products that each stand alone, so that the claim you are not trapped is testable rather than promised.

Where this leaves Akora

We should declare an interest, because we have one. Akora is our desktop AI, and it is this shape by design: it runs on the machine, does analytical work and task automation in the background, and can be flipped to a fully private mode where execution stays local and nothing leaves the device. When it does reach a cloud model, it routes through AiR with sensitive context kept off the wire.

It is built for Windows, macOS and Linux, which is the part most relevant to this shift. If the agent host is a feature of the operating system, then you get one runtime per platform — each with its own state, its own policy, and its own answer to the four questions above. An organisation running three operating systems inherits three of everything, including three places where the audit trail can differ. A host that runs across all three is not a portability nicety. It is what keeps the choice of operating system independent of the choice of agent runtime.

So we are not a neutral observer of this shift. We think the shift is correct, and we have been building for it. Our disagreement with the emerging default is narrower and more specific: the agent host does not have to be the same organisation as the model provider, the telemetry pipeline and the cloud. Those three being one entity is a commercial arrangement, not an architectural requirement.

What we are not claiming

We are not claiming Microsoft has done this badly. The primitives look right, and a platform of that reach normalising them helps everyone building here, ourselves included. We are not claiming Akora is a general-purpose operating system; it is a desktop application that participates in one. And we are early — though that is a statement with a date on it. Availability, Alpha status and certification all move, so the products page is the source of truth for where things stand, rather than this paragraph.

What we will claim is that the interesting question has moved. It is no longer whether the operating system becomes an agent host. That is settled, and it settled faster than we expected.

It is whose.