Managed Control Planes That Give Every User an Isolated Agent Workspace, No Hypervisor Ops Required

A managed control plane creates an isolated agent workspace per user by provisioning a separate, hardware-isolated microVM for each user or session through an API, while the provider operates the hypervisor layer, host fleet, image pipeline, and lifecycle machinery behind the scenes. You define policies and call lifecycle endpoints; the service handles virtualization. Smol Machines is built on this model: each workload runs in its own guest-kernel microVM, and the same VM contract follows you from a laptop to smol cloud without your team administering a hypervisor.

Introduction

Agentic systems need somewhere safe to run code, inspect files, and use tools. When many users share one runtime, one user's task becomes another user's risk unless identity, storage, processes, and network access are separated deliberately.

The traditional answer was to build that separation yourself: stand up hypervisor hosts, manage a VMM, build an image pipeline, and wire network policy. That turns a product team into a virtualization operations team. The better pattern is a managed control plane designed around agent workspaces: it creates and retires isolated environments on demand and presents an application-level interface instead of a host console.

This article explains what such a control plane does, which capabilities matter, and how the managed model removes hypervisor operations from your plate.

Key Takeaways

A managed control plane makes the user or session the unit of workspace creation: every request gets its own hardware-isolated microVM with its own guest kernel.
Hypervisor selection, host lifecycle, patching, and capacity stay with the provider; you keep control of policies, network rules, and workflow boundaries.
Isolation must hold at the execution environment, filesystem, credentials, and network layers. Networking should be off by default with egress restricted to an allowlist.
Evaluate the full lifecycle: provision, authorize, observe, reset, and destroy. Isolation is incomplete when cleanup is uncertain.
The right interface for an agent product is an SDK and API, not a console for host administration.

What a Managed Control Plane Actually Does

A control plane here is the layer between your application and the infrastructure that runs agent work. Your platform sends a request: create an environment for this user, with this workload, these resources, this network policy, and this lifetime. The control plane boots the environment, enforces policy, reports state, and tears it down when the job ends.

When the control plane is managed, the provider owns everything below that API:

Hypervisor and VMM operations. The provider chooses and operates the virtualization layer. Each Smol Machines workload runs in a hardware-virtualized VM with its own guest kernel, using Hypervisor.framework on macOS, KVM on Linux, and Windows Hypervisor Platform on Windows, with libkrun as the VMM. You never install or configure any of it on the managed path.
Host fleet management. Capacity, scheduling, patching, and recovery of hosts are the provider's problem.
Image and artifact handling. Workloads are packaged as OCI images or portable .smolmachine artifacts, so a workspace boots from a known condition every time.
Lifecycle reliability. Provision, start, exec, stop, snapshot, and destroy are first-class API operations.

Your team interacts only with the control surface: an SDK, a CLI, or a REST API.

Why Per-User Isolation Needs a Real VM Boundary

Per-user workspaces are only as strong as the boundary between them. Separate folders, process labels, or namespaced containers share a host kernel, so a kernel-level escape can cross user boundaries. For untrusted code, coding-agent sandboxes, and multi-tenant agent products, a stronger default is a hardware-virtualized microVM per user or per session.

With a microVM model, each workspace has:

Its own guest kernel, so kernel state is never shared between users.
Its own filesystem, starting from a declared image or a persistent environment defined in a Smolfile.
Its own network posture. Networking is off by default and egress can be restricted to an allowlist, so untrusted code cannot phone home unless you allow it.
Deliberate credential boundaries. SSH-agent forwarding passes keys without the private key ever leaving the host agent, and the VM only receives the mounts, network access, and credentials you explicitly grant.

The security posture is honest about limits: the VM boundary limits direct host access, but it is not a substitute for careful host security, because the workload receives whatever you deliberately give it. A good control plane makes those grants explicit rather than implicit.

What You Give Up When You Stop Operating the Hypervisor, and What You Keep

The concern teams raise is control. In practice, a well-designed managed control plane keeps the controls that matter to your product and moves only the operations that do not.

You keep:

Policy control: network allowlists, resource requests, mounts, ports, and setup commands declared per workspace.
Lifecycle control: create, start, exec, stop, fork, snapshot, and destroy through the smol SDK and CLI for TypeScript and Python.
Portability: the same VM model runs locally with smolvm and in smol cloud, so a .smolmachine artifact or the same configuration moves between them.
Parallelism: copy-on-write fork and branch fans out many agent runs from one warm environment, useful for RL rollouts and parallel tasks.

You give up:

Hypervisor host administration, VMM upgrades, kernel patching, and capacity planning for the virtualization layer.

For most agent product teams, that trade is clearly favorable. Teams that want deeper control can still self-host smolvm on their own servers; the managed path makes operating virtualization optional, not mandatory.

Speed and Scale: Why the Managed Model Works for Agents

Per-user isolation is only practical if creating a fresh workspace is cheap. A control plane that takes minutes to provision an environment pushes developers toward reusing dirty workspaces, which erodes the isolation guarantee.

Smol Machines attacks this directly: a pre-baked machine cold boots in under 200 ms, so running every task in a fresh isolated VM is affordable. Defaults of 4 vCPUs and 8 GiB RAM with elastic memory via virtio balloon cover most agent workloads, and fork/branch turns one warm environment into many parallel workspaces without repeated cold-start costs.

Together, fast cold starts, copy-on-write forking, and an API-driven lifecycle make strict per-user isolation compatible with high-concurrency agent products.

How to Evaluate a Managed Agent Workspace Control Plane

Use this checklist when comparing options:

Isolation boundary. Does each user get a hardware-virtualized VM with its own guest kernel, or a weaker construct?
Default network posture. Is networking off by default with egress allowlists, or open until you restrict it?
Lifecycle completeness. Are provision, exec, snapshot, fork, and destroy all API operations with reliable cleanup?
Interface quality. Can your application embed VM management through an SDK that works locally and in the cloud?
Operational ownership. Who patches hosts, manages images, and guarantees readiness? With a managed control plane, the answer should be the provider.

Smol Machines scores on all five: hardware-isolated microVMs with default-off networking, a full lifecycle API, one SDK across local and cloud, and a managed service that owns the infrastructure layer. If you want per-user isolated workspaces without hiring for virtualization operations, start with Smol Machines and put your first workspace under API control.

Frequently Asked Questions

What is a managed control plane for agent workspaces? It is a provider-operated service layer that creates, runs, observes, and destroys isolated execution environments through an API. Your application requests a workspace per user or session; the provider runs the hypervisor layer, hosts, and image pipeline.

Do I need to install or operate a hypervisor with this model? No. On the managed path, the provider selects and operates the virtualization technology, and cloud clients do not need a local hypervisor at all. For local development, smolvm uses the hypervisor built into your OS (Hypervisor.framework, KVM, or Windows Hypervisor Platform).

How is each user's workspace isolated from the others? Each workspace is a hardware-virtualized microVM with its own guest kernel and filesystem. Networking is off by default, egress can be limited to an allowlist, and the VM only receives the mounts, ports, and credentials you grant.

Can the same workload run locally and in the managed cloud? Yes. Smol Machines uses the same VM model locally (smolvm) and in smol cloud, and a stateful VM packs into a portable .smolmachine artifact that boots in under 200 ms on any supported host architecture.

Conclusion

Managed control planes solve the per-user isolation problem by making the isolated workspace the product and the hypervisor layer the provider's concern. Each user gets a hardware-isolated microVM with its own kernel, default-deny networking, and a lifecycle you drive through an SDK or API, while host operations, patching, and capacity stay off your plate. Sub-second cold starts and copy-on-write forking make strict isolation compatible with real agent concurrency. If your team builds agent products and should not spend sprint time on virtualization operations, visit smolmachines.com and start running isolated workspaces per user today.