The newest infrastructure problem begins with a very old assumption: that work lives inside a machine.

Linux namespaces decide what a process can see. Cgroups decide how much CPU and memory it may consume. Containers combine these with capabilities, seccomp, and security modules into something remarkably fast, dense, and easy to use.

But a container is not a small virtual machine. Its processes still meet the host through a shared kernel, making it a weaker boundary for running code that may be actively hostile.

Moving the boundary deeper

Virtual machines move that boundary deeper. The workload receives its own kernel, separated by a hypervisor. MicroVMs remove much of the machinery of a traditional VM, making them faster and lighter, but the trade remains: stronger isolation requires constructing, starting, connecting, observing, and eventually destroying another computer.

For agents, this leaves a strangely limited choice: a convenient process environment with a shared kernel, or a stronger boundary carrying the operational weight of a machine.

Neither describes the thing an agent actually inhabits.

What an agent inhabits

An agent’s working environment includes repositories, compilers, services, credentials, collaborators, unfinished discoveries, and evidence of what has already happened. To clone a private repository, it obtains authority from outside the machine. To test a change, it may depend on a remote service. To finish the work, it may need a decision from another agent or a human.

Those crossings are not exceptions to the work. They are the work.

Place the process inside a microVM and the decisive activity still crosses its walls. Snapshot the VM and its execution state may survive, yet the purpose of the task, its authority, its relationships, and the meaning of its evidence remain elsewhere.

What isolation answers

Cgroups answer how much. Namespaces answer what can be seen. Virtual machines answer where one computer ends and another begins.

None of them answers: where does the work live?

Old systems, better questions

This is where old ideas begin to haunt the present. Plan 9 explored environments composed from resources spread across machines. Sprite and Amoeba treated location as a system concern rather than the identity of the work. Capability systems described authority as an explicit relationship instead of an ambient property inherited from a machine.

Those systems did not solve agentic infrastructure, but they may have been asking better questions.

A habitat, not a machine

There is another possible environment in which the durable object is the work itself: a habitat that persists while agents, processes, and machines come and go. This is not merely a pipeline that survives a restart. A pipeline preserves a predefined sequence; a habitat preserves the resources, authority, relationships, and unfinished state from which the next action can be discovered.

Native processes, containers, or microVMs may still exist underneath, chosen when their properties are useful, but none of them has to define the world the agent experiences.

Not a war against containers

The goal is not weaker security, nor another war against containers. It is to stop confusing an isolation mechanism with an operating model.

The past is not handing over an architecture to copy. It is a reminder that the machine was never the work.


Solu is the False Systems environment for agentic work, built around the work rather than the machine — early, and in active development.