Wasm Sandboxes Could Pack 1.42 Million AI Agents onto One Kubernetes Server

Cosmonic's wasmCloud demo at KubeCon + CloudNativeCon North America 2026 ran a Kubernetes cluster on a single 64-core server and hosted 1.42 million sandboxed environments for AI agents. That's a density number that should get infrastructure teams thinking about how they size agent fleets.

The pitch is simple. Instead of giving every agent a full container or virtual machine, you give it a WebAssembly sandbox and let existing Kubernetes clusters handle the scheduling. Cosmonic CTO Bailey Hayes framed it as an alternative deployment model for IT teams that don't want to build a second platform just for agents.

Where Wasm fits and where it doesn't

Wasm is a good match for agents with a small, well-defined job. Hayes pointed out that the bulk of agents an average enterprise deploys will handle narrow tasks, and those agents don't need much room to operate. A lightweight sandbox keeps them isolated.

Isolation matters more than it might seem. Without a sandbox, an agent can reach services and applications it has no business touching. Wrapping each agent in its own execution boundary limits that blast radius, and it does so without the overhead of a full virtual machine.

Here's the catch: not every agent is narrow. An AI coding agent, for example, may need a larger sandbox built on a micro virtual machine. So the likely outcome is a mix, with Wasm handling the high-volume, task-specific agents and heavier isolation reserved for the workloads that need it.

The control plane is the real bottleneck

Density at the sandbox layer is only half the problem. Today, every active agent gets its own pod. Those pods lock up memory and CPU even when the agent is sitting idle. Multiply that across millions of agents and the Kubernetes control plane ends up tracking millions of persistent objects it was never built to manage.

API traffic compounds the issue. Agents make calls to exposed APIs at a rate that can climb quickly, and the control plane's performance starts to degrade under that load. Teams running agents on Kubernetes are already running into efficiency problems on the infrastructure side and performance limits on the control-plane side.

Snapshotting idle agents

Google has contributed an open-source framework called Agent Substrate to the Cloud Native Computing Foundation (CNCF). It separates stateful agent sessions and identities from active compute. Idle agents get snapshotted, stored, and restored when needed in under 500 milliseconds.

That's the part that could change the economics. An agent that isn't doing anything stops consuming pod resources, and the cluster stops carrying a live object for it. Agent Substrate is aimed at running long-running agent workloads at scale on Kubernetes more efficiently, and it addresses the idle-resource problem directly rather than working around it.

Control-plane performance improvements are also needed, and those won't arrive quickly. Hayes's team and the broader Kubernetes community will need to push those changes through, and they probably won't show up in a mainstream distribution until next year. In the meantime, vendors such as Solo.io are offering an enterprise edition of Agent Substrate that IT teams can deploy themselves.

The decision in front of IT teams

AI agents are going to run on Kubernetes regardless of how the platform evolves. The open question is timing and approach. Teams can wait for Kubernetes to be tuned for agent workloads, or they can adopt an alternative framework that makes existing distributions more efficient now.

My read is that most organizations will do some of both. Narrow, high-volume agents are the obvious candidates for lightweight Wasm sandboxes today. Heavier agents will stay on larger isolation models for longer. The teams that benefit most will be the ones that measure idle resource consumption and API load early, before agent counts reach the point where the control plane becomes the constraint.