Agent orchestration presents itself as a new discipline: new frameworks, new vocabulary, new failure modes with new names. Structurally, it is an old problem wearing new hardware. An operating system exists because a scarce, shared resource — one machine — must serve many principals whose demands are bursty, whose code is buggy, and who must not be allowed to corrupt each other. An agent orchestrator exists because a scarce, shared resource — a pool of model calls, a window of context, a human's verification bandwidth — must serve many tasks under exactly those conditions. The resource changed. The problem did not.
This series is a map of the correspondence, drawn from building agent systems and finding, one design meeting at a time, that the answer was already written down in a field that had its arguments sixty years ago:
- Branches are processes — scheduling, work stealing, starvation, and the zombie branch nobody reaps.
- Context is virtual memory — working sets, prefetch, page faults, caches, and thrashing.
- Fork and copy-on-write — how a branch inherits a world without paying for a copy of it.
- IPC — pipes, messages, and shared memory, and why branches should exchange artifacts, not conversation.
- Tools are syscalls — the model lives in user mode; the host is the kernel; evidence gates are permission checks.
- Everything is a file — links as symlinks, entries as inodes, a corpus as a filesystem.
- Barriers, deadlocks, backpressure — the synchronization primitives of fan-in.
- Where the isomorphism breaks — the closing audit of this series' own analogy, because an analogy you cannot falsify is just a metaphor.
The claim is not that agent builders should read kernel code. It is that the design instincts which feel like insight in this young field are mostly memory — of constraints that operating systems were the first to be honest about. Where the constraints match, the answers transfer. The last chapter is about where they don't.