Every computing platform eventually needed an operating system. Not because the hardware wasn't powerful enough, but because the complexity exceeded what users could manage by hand. Mainframes got OS/360. PCs got Unix, then macOS and Windows. Phones got iOS and Android. Agents are next.
The models are powerful. The orchestration exists. But there's no operating system.
What would one look like?
The answer is: exactly what you'd expect. Every OS solves the same fundamental problems. Agents need the same solutions, for the same reasons. The primitives are nearly identical.
This is Part 1 of a series. We start with the three most foundational primitives: process management, inter-process communication, and security.
The Process Model
Every OS manages process lifecycle. Spawn, run, suspend, resume, terminate. When you have 50 apps open on macOS, the OS decides what runs in the foreground, what gets backgrounded, what gets killed under memory pressure. You don't think about it. It just works.
Agents have the same problem. Run five agents simultaneously -- research, email triage, content drafting, data analysis, scheduling -- and something needs to manage their lifecycle. Which one gets priority? What happens when one finishes? What if one hangs? Without a process manager, you're back to manually babysitting terminal sessions.
Isolation by Default
Processes are isolated by default. Each gets its own virtual address space. One process cannot see another's memory. This is a feature, not a limitation -- isolation prevents one process from corrupting another. Sharing is the exception, explicitly mediated by the OS.
Agents should work the same way. Each agent has its own context, its own session, its own state. One agent cannot see another agent's context. A research agent doesn't know what your email agent found. A scheduling agent doesn't have access to your content drafts. Isolation prevents one agent from leaking or corrupting another's state.
This is the safe default. Sharing, when it happens, must be intentional.
Child Processes and Delegation
A parent process can spawn child processes. The child inherits relevant context from the parent. It runs independently. If the parent dies, children don't necessarily die -- orphan processes get adopted by init or launchd. The parent can wait for the child's result, or fire-and-forget.
Agent delegation is the same model. A research agent spawns a sub-agent to search academic papers. The child inherits the research question and constraints from the parent. It runs independently and returns results. The parent can wait -- synchronous delegation, "I need these results before I continue" -- or fire-and-forget -- asynchronous delegation, "triage my email while I work on something else."
If the parent agent crashes or times out, the child agents can still complete their work. The OS preserves their output. Orphan adoption, applied to agents.
The mapping is precise:
- Process isolation -- each agent has its own context. Cannot see other agents' state.
- fork() / child processes -- agent delegation. Parent spawns child, passes context. Child runs independently.
- wait() -- synchronous delegation. Parent blocks until child returns.
- Fire-and-forget -- asynchronous delegation. Parent continues, child runs in background.
- Orphan adoption -- child agents survive parent failure. OS preserves output.
We solved process management decades ago. The same patterns apply directly.
Inter-Process Communication
Processes need to talk to each other. Modern IPC uses Unix domain sockets for fast bidirectional local communication, shared memory regions for high-throughput data transfer, and structured message passing for everything else. The OS mediates all of it. Processes don't reach into each other's memory. They send messages through OS-provided channels.
Agent communication follows the same pattern. Agents don't share state directly. They pass structured messages through the runtime -- "here's the research question," "here are the findings," "summarize these results." The OS routes the messages, manages the channels, prevents conflicts.
Local to Network: Same Protocol, Different Transport
IPC started local. Processes on the same machine talking through the kernel. Then networking extended this to processes on different machines. TCP/IP. HTTP. RPC. The critical insight: the programming model stayed the same. A socket API looks identical whether you're connecting to localhost or a remote server. The OS abstracts the transport.
Agent-to-agent communication follows the same evolution. When agent A communicates with agent B, it shouldn't matter whether B is:
- A local process on your machine
- A cloud agent running on someone's server
- An agent on a colleague's machine across your network
Same protocol. Different transport. The runtime handles routing. Just like how the OS networking stack abstracts the difference between local and remote sockets.
This is A2A -- agent-to-agent communication. Not a new concept. It's networking, applied to agents. The protocol is the same whether agents are colocated or distributed across the internet. Discovery works the same way DNS does: find available agents locally, on your network, or in the cloud.
"I'll have your agent talk to my agent" isn't a futuristic prediction. It's just networking.
Permissions and Security
Early computers had no permission model. Any program could do anything -- read any file, access any hardware, modify any system state. DOS was wide open.
Unix added user-level permissions. Files had owner, group, and other access flags. Better, but coarse. If a program ran as you, it could access all your files. The trust boundary was the user, not the application.
Then iOS changed everything.
Per-app, per-capability permissions. The first time an app tries to use the camera, a system dialog appears: "Allow Photos to access your Camera?" The user decides. The decision is revocable anytime in Settings. The OS enforces it at the kernel level -- the app literally cannot bypass the check.
macOS adopted the same model. Camera. Microphone. Screen Recording. Location Services. Contacts. Calendar. Files and Folders. Full Disk Access. Accessibility. Automation. Each capability scoped per-app. Each user-controlled. Each revocable.
The evolution was clear: no permissions, then coarse user-level permissions, then per-app per-capability permissions with user control.
Agents Are at the DOS Stage
AI agents today have no real permission model. You give an agent your API key and it can do anything that key allows. No granularity. No per-agent scoping. No revocation. You either trust everything or trust nothing.
An Agent OS brings the same evolution that iOS brought to mobile:
- Camera maps to microphone / speech-to-text
- Contacts maps to email and contacts access
- Calendar maps to calendar read/write
- Files and Folders maps to file system access, scoped to specific directories
- Screen Recording maps to browser automation / screen capture
- Automation (control other apps) maps to agent delegation -- can this agent spawn other agents?
- Full Disk Access maps to unrestricted tool access -- the "root" equivalent, rarely granted
Same model. Per-agent. Per-capability. User-controlled. Revocable. OS-enforced. "Allow Inbox Ninja to access Gmail?" Allow Once. Allow Always. Deny. Visible in settings. Toggleable anytime. The agent cannot bypass the check.
We solved this problem 15 years ago for apps. The same solution applies directly to agents.
The Pattern
Three primitives. Each one follows the same arc: the concept was invented for traditional computing, agents face the exact same problem, and the solution is the same architecture adapted to the new substrate.
Process management. Inter-process communication. Security and permissions. These aren't metaphors. They aren't analogies. They're the same engineering problems, appearing again because agents are a new class of computation that needs to be governed.
But these are just the foundation. An operating system needs more than processes, communication, and security. It needs a file system. Memory management. Hardware abstraction. A package manager. And one primitive that has no precedent in any previous operating system.
Part 2 covers the rest.