The operating system was designed around a very specific idea of what a computer does.
It executes instructions. Discrete, defined, finite. A program asks for memory — the OS allocates it. A program asks to read a file — the OS fetches it. A program terminates — the OS cleans up after it. The whole architecture is built around this model: programs are guests, the OS is the hotel, and everything runs on clearly negotiated transactions between the two.
That model is about fifty years old. And for fifty years, it held up remarkably well.
Then AI showed up. And the model started quietly breaking.
§01 · AssumptionThe Assumption Nobody Questioned
Here's what every operating system ever shipped assumes, at its core: compute is a tool that executes human intent.
You tell it what to do. It does it. You tell it again. It does that too. The human is the source of the instruction; the machine is the executor of it. The OS exists to manage that relationship — to make sure the right instructions get to the right hardware, in the right order, without conflict.
This assumption is so deeply embedded in how operating systems work that it's not documented anywhere. It doesn't need to be. It was just true — obviously, self-evidently true — so it became the ground everything else was built on.
AI makes it not true.
When you introduce a system that generates its own instructions — that takes a high-level goal and produces the sequence of actions required to accomplish it, without a human specifying each step — you've broken the fundamental assumption. The machine is no longer purely an executor. It's partly an author. And the operating system, designed entirely around the executor model, has no idea what to do with that.
The machine is no longer purely an executor. It's partly an author.
§02 · FractureWhat Breaks First
The first thing that breaks is the boundary between application and system.
In the traditional model, that boundary is clean. The application lives in user space. The OS lives in kernel space. They communicate through a defined interface — the syscall — and neither one reaches into the other's territory. It's a good design. It's why your browser crashing doesn't take down your entire machine.
But an AI agent doesn't respect that boundary, because it can't. An agent that's trying to accomplish a goal needs to know things that traditional applications don't need to know — what else is running, what resources are available, what the system has done recently, what it's about to do. It needs context that the OS was never designed to provide, because applications were never supposed to need it.
So what happens? Developers build workarounds. Agents scrape system logs. Applications maintain their own parallel records of system state because the OS won't give them the real one. The clean boundary becomes a porous mess of hacks and edge cases, and everyone just quietly agrees not to talk about it.
That's where we are right now. It's not stable. It's a temporary arrangement that breaks in increasingly visible ways as agents become more capable.
§03 · DiagnosisThe Deeper Problem
The syscall interface isn't the only thing that breaks. The resource model breaks too.
Traditional OS resource management is built around scarcity of well-understood things: CPU cycles, memory addresses, file handles, network sockets. These are finite, measurable, and the OS has decades of research behind how to allocate them fairly and efficiently.
AI workloads introduce a resource that the OS has no model for: context.
Context — the accumulated state of what a model knows, what it's done, what it's been told, what it's trying to accomplish — is the thing that makes AI systems useful. It's also the thing that determines how much compute they need, how long they'll run, and what they'll produce. And unlike CPU cycles, you can't measure it in bytes. You can't schedule it the way you schedule threads. You can't allocate it with the same tools you use to allocate memory.
The OS looks at an AI workload and sees a process consuming resources. It has no visibility into what that process is actually doing, what it needs to complete, or how to manage the thing that actually matters — the context. So it manages what it can see and ignores the rest.
That gap is where AI systems get slow, expensive, unpredictable, and brittle. Not because the models are bad, but because the substrate they're running on was designed for a different kind of compute entirely.
§04 · QuestionThe Honest Question
Here's the question that doesn't get asked often enough: if you were designing an operating system today, knowing what compute actually looks like now, would you design anything like what we have?
The answer is obviously no.
You wouldn't build a syscall interface designed for single-threaded programs running on one machine. You wouldn't build a memory model that treats everything as an addressable byte. You wouldn't build a process scheduler that has no concept of a workload that generates its own subsequent workloads. You wouldn't make any of the decisions that made sense in 1975 and got inherited, layer by layer, into everything we run today.
You'd start from the actual problem: a system where intelligence is a first-class citizen, not an application running on top of infrastructure that doesn't know it exists.
That's a genuinely different operating system. Not a new feature. Not a better scheduler. A different foundational set of assumptions — about what compute is for, what the boundary between system and application should be, what resources are worth managing and how.
§05 · UrgencyWhy This Matters Now
For a while, this was a theoretical problem. AI workloads were niche enough that the gaps in the OS model were manageable — an inconvenience, not a crisis. You could paper over them with good enough hardware and clever enough middleware.
That window is closing.
As AI moves from a feature inside applications to the primary way software works — as agents stop being demos and start being the thing people actually use to get things done — the mismatch between the OS and the workload stops being manageable. It becomes the main bottleneck. The thing that determines how capable AI systems can get, how efficiently they can run, how reliably they can operate in production.
The operating system is the platform everything else runs on. If the platform is built on the wrong assumptions, everything built on top of it inherits those assumptions. And we're at the point where that inheritance is becoming a visible problem — not just for researchers, but for anyone trying to ship AI systems that work reliably in the real world.
If the platform is built on the wrong assumptions, everything built on top of it inherits those assumptions.
§06 · ResolutionWhat Comes Next
The operating system is going to get redesigned. The only question is by whom, and whether they start from the right place.
The wrong way to do it is to add AI features to an existing OS — a context manager here, an agent scheduler there — without touching the foundational assumptions. That produces something that's better than what we have but still wrong at the core. A more comfortable version of the same mistake.
The right way is to treat this as a first-principles problem. To ask: what does an operating system need to do, given what compute actually is now? And to be willing to throw away a lot of inherited answers in the process.
The answers look different than what we're used to. The boundary between system and application moves. The resource model expands. The interface between the OS and the workload gets redesigned around context rather than instructions. None of it is easy, and none of it is fast.
But it's the work. And somebody has to do it.
G. Rajpal is the founder of Nexa. AetherOS is Nexa's first subsidiary — a ground-up rethinking of the operating environment for AI-native compute. Filed under Essay · Published 2026·04·23 · Alameda, California. To get in touch, reach us at hello@nexa.com.