Agent Zero is preparing its third major iteration. One of the biggest changes is not a new button or a longer list of tools. It is a new answer to a basic question: where should agent-run code actually live?
Until now, code execution has shared the Docker environment that runs Agent Zero. Containers already provide a useful boundary from the rest of your machine, but the agent's tools, Python packages, services, and framework still accumulate in one place.
The v3 work in progress takes a different approach: ordinary agent code moves into its own sandbox, while access to the Agent Zero system becomes an explicit destination for the narrower cases that truly need it.
This is a sneak peek at code currently being prepared and tested—not a general-availability announcement or a production-readiness claim.
A Workspace You Can Throw Away
The current prototype manages named environments directly with gVisor, whose runsc runtime adds another isolation layer between sandboxed work and the surrounding system. A sandbox can be created for a task, used through the normal code-execution tool, stopped and restored, or removed when it is no longer useful.
Temporary sandboxes are designed for disposable work and expire after a period of inactivity. Permanent ones keep a private disk-backed workspace. Both can share an explicit exchange folder, while any additional host folder access must be deliberately mounted.
The implementation also supports standalone sandbox destinations. That means one task can have a clean Python workspace, another can run a specialized toolchain, and a heavyweight service can own an environment tailored to its needs. They do not all have to become permanent residents of the Agent Zero base image.
From One Crowded Image to Clear Ownership
An all-in-one image is convenient at first: preinstall everything and every capability is nearby. Over time, that convenience turns into coupling. Packages conflict. Builds grow. A service needed by one tool becomes part of every installation. It gets harder to tell which capability owns which dependency.
Sandboxes make that ownership clearer. Each environment starts from a selected OCI image, and the current prototype pins the resolved image digest so an existing sandbox does not silently change when a tag moves. Python, Node.js, Git, or any other tool is present only when the chosen image—or the work inside it—provides it.
This is also the direction for heavyweight capabilities such as the search engine. Instead of baking a complete search service into the outer image and keeping it running beside the framework, it can eventually live in a purpose-built sandbox with its own dependencies and lifecycle. That search migration is still future work; the repository currently contains a non-working placeholder rather than a finished sandboxed service.
Plugins Get Their Own Room
The same architecture changes what a plugin can responsibly bring with it.
Today, a plugin that needs a Python package often pressures the main image to install that dependency ahead of time. In the v3 direction, a plugin can prepare packages at runtime inside a disposable sandbox instead. A plugin with a larger workload can go further and own a dedicated sandbox—its tools, packages, writable state, and cleanup policy together in one place.
That is the intended plugin model, not a promise that every plugin already works this way. The important shift is architectural: adding a capability should not automatically mean adding its entire dependency tree to Agent Zero itself.
Isolation Is a Boundary, Not a Slogan
The prototype is deliberately explicit about its limits. It invokes gVisor directly rather than falling back to unsandboxed execution when runtime prerequisites are missing. Network access can be enabled or disabled per sandbox. Shared and host-mounted folders remain real access paths and must be treated accordingly. The actual Linux and gVisor runtime still needs deployment-specific testing in addition to the mocked unit suite.
That is why we are not calling this an impenetrable security box. Stronger isolation, smaller dependency surfaces, and disposable state are meaningful improvements, but safe operation still depends on configuration, mounts, network policy, the selected image, and the host environment.
You may also have heard an early sub-10-millisecond startup figure. We could not verify a benchmark in the current codebase that supports publishing that number, so we are leaving it out. Fast creation and wake-up matter; evidence matters more.
What This Unlocks
For users, the goal is simple: experiments become easier to discard, specialized toolchains stop polluting the main runtime, and risky agent-run code gets a tighter place to operate.
For plugin authors, dependencies can belong to the capability that needs them. For Agent Zero itself, the base image can focus on running and supervising the framework instead of trying to anticipate every tool an agent might ever use.
There is more engineering and real-world validation ahead. But the shape of Agent Zero v3 is becoming clear: a lighter core coordinating environments that are isolated, purpose-built, and replaceable.
That is a much better foundation for an agent that is supposed to learn new ways of working without turning its own home into a junk drawer.