Most of what we call “agent infrastructure” today is a harness: a loop that wraps a model call, bolts on some tools, and hopes the important state survives until the next turn. That was fine when agents ran for minutes. It breaks when they run for weeks.
I’ve been writing about this from the leadership side — that context is the real work, that agents need commander’s intent rather than step-by-step orders, that the compiler is giving way to natural language. This post is the systems side of the same argument. If agents are going to be long-lived colleagues rather than clever autocomplete, they need something the industry solved fifty years ago for programs: a kernel.
The harness hits a ceiling
A harness is built around a single conversation. Its unit of work is the turn; its memory is whatever fits in the context window plus whatever someone remembered to write to a vector store. Ask it to run for a month — watching a codebase, operating a fleet, managing a research program — and the same failures show up every time:
- Amnesia. State lives in the prompt, so it decays, gets summarized into mush, or disappears on restart.
- No scheduling. Everything is synchronous. There is no clean way for an agent to sleep, wake on an event, or juggle ten threads of work at different priorities.
- Ambient authority. Tools are handed over wholesale. Once the agent has a credential, every step of every task has it too.
- No isolation. One confused sub-task can pollute the context, and the judgment, of everything else running in the same loop.
We keep patching these with bigger context windows and cleverer prompts. That’s like fixing a lack of virtual memory by buying more RAM.
What operating systems already figured out
Early computers had the same problem. Programs ran one at a time, owned the whole machine, and lost everything when they stopped. The fix wasn’t faster programs; it was a layer underneath them that every program could rely on. A kernel gives you a small set of guarantees: processes that persist and can be paused and resumed, memory that is managed rather than hoped for, permissions enforced below the application, and a scheduler that decides what runs when.
Map that onto agents and the shape of the missing layer becomes obvious.
The primitives of an agentic kernel
Persistent processes. An agent is not a chat session; it’s a process with an identity, a goal, and a lifetime measured in weeks. It can checkpoint, suspend, migrate between machines and resume without losing the thread.
Managed memory. The context window is the agent’s registers, not its memory. Beneath it sits working memory, episodic memory of what happened and when, and semantic memory of what it knows. The kernel decides what gets paged into context for the task at hand. This is where context engineering stops being a craft and becomes infrastructure.
Capabilities, not credentials. Instead of handing an agent an API key, the kernel grants narrow, revocable capabilities per task: read this repo, open a pull request, spend up to this budget. Least privilege enforced below the model, where a clever prompt can’t talk its way around it.
Scheduling and interrupts. Agents should sleep until something matters — a deploy finishes, a metric crosses a line, a human replies — and then wake with the right context loaded. Priorities, deadlines and budgets are scheduler problems, not prompt problems.
Isolation and IPC. Sub-agents run in their own address space and talk through explicit messages. A failing child gets killed and restarted; it doesn’t contaminate its parent’s reasoning.
An audit trail. Every action, every capability used, every decision point, recorded. If agents are going to act on our behalf, we need the equivalent of system logs before we need a better model.
Where intent lives
Here the leadership and systems arguments meet. In a harness, intent is a paragraph at the top of a prompt that slowly gets buried. In a kernel, intent is a first-class object: the goal, the constraints, what “done” looks like and what must never happen. It travels with the process, is visible to every sub-agent, and is what the kernel checks actions against. That is commander’s intent, expressed as an operating-system primitive.
Why this matters beyond engineering
For leaders, the kernel question is really a governance question. You cannot responsibly hand an organization’s work to agents that forget, can’t be paused, and hold every key at once. The teams that win the next few years won’t be the ones with the cleverest prompts. They’ll be the ones who build — or adopt — the substrate that makes agents persistent, bounded and accountable.
I’m sketching a specification for exactly this kind of runtime, and testing pieces of it in my own projects: spatial and temporal memory in LOCI-DB, capability-scoped data access in SLM Vault. More on both soon. If you’re working on the same problem from a different angle, I’d like to compare notes.
Zygmunt Dyras is SVP of Engineering at WP Engine, where he leads engineering teams across the US and Europe. He writes about how AI agents change engineering leadership and builds open-source agent infrastructure, including LOCI-DB, a spatial memory for physical AI. Earlier he held engineering leadership roles at UBS, SolarWinds and Intel Security.
Get the next essay in your inbox.
One email when something new is published. No spam, unsubscribe anytime.