Wasm Sandboxes Reach 1.42 Million Density on a Single Kubernetes Server

Cosmonic has put a number on a question many platform teams are starting to ask. At KubeCon + CloudNativeCon North America 2026, the company ran a Kubernetes cluster on a single 64-core server with wasmCloud, hosting 1.42 million sandboxed environments for AI agents. That's a density figure, not a count of 1.42 million agents doing heavy work at the same moment, but it shows how little overhead a WebAssembly sandbox carries compared with a container or a micro virtual machine. I'd read a demo like this as a marketing artifact, not a benchmark you can deploy from. It's still a useful signal about where the cost floor sits.

Why Wasm fits narrow agents

Cosmonic CTO Bailey Hayes framed the demo as an alternative way to deploy agents. Instead of building new infrastructure, teams could run WebAssembly sandboxes on existing Kubernetes clusters and scale them from there. That's a pitch worth taking seriously, because the biggest cost of a new agent platform is usually the platform itself, not the agents running on it. If you already run Kubernetes, you've paid for the hard parts of operations, and the real question becomes whether the new workload can ride on that investment.

The fit depends on the agent. Wasm works best for agents with a limited set of well-defined tasks, and that describes most of what enterprises will actually deploy. Think of a bot that reconciles invoices or triages support tickets. Its surface area is small, and a tight sandbox suits it. An AI coding agent is a different case. It may need a larger sandbox built on a micro virtual machine, because it has to run arbitrary tooling and more varied code paths. Narrow and broad agents shouldn't share one isolation model, and I'd be wary of any vendor that implies they should.

Isolation is the other half of the argument. Without a sandbox, an agent can reach services and applications it was never meant to touch. That's not a theoretical worry. It's the default behavior when an agent inherits whatever credentials and network paths its host already has. A lightweight sandbox per task gives teams a boundary without the cost of a full VM for every agent. Here's the thing, though: density only matters if the isolation holds, and that's the part teams should test themselves rather than take from a demo. A density record says nothing about escape paths or what happens when an agent misbehaves inside its box.

Where the bottleneck actually sits

Cosmonic is pitching wasmCloud as a way to run agents on Kubernetes through an operator that deploys Wasm components. The project is progressing as an open-source effort under the Cloud Native Computing Foundation (CNCF). Hayes went further and suggested agents could become the "killer application" for wasmCloud. I'd discount that phrase a little. Every infrastructure project wants a killer app, and the claim is only as good as the adoption that follows.

The harder problem is that Kubernetes wasn't built for this workload. Today, each active agent gets its own pod. That pod holds memory and CPU even when the agent is sitting idle, which means a large agent population turns into a large pile of idle resources. Pods are designed for long-running services that get scheduled, scaled, and replaced in fairly predictable ways. Agents are different. Many spin up for a single task, wait on a model response or a human, and then sit there. Paying for that waiting time is the waste nobody budgets for.

The control plane also ends up tracking millions of persistent objects it was never designed to manage. That's where things get uncomfortable. Each object carries state that the scheduler, the API server, and the controllers have to watch, and at that scale the bookkeeping itself becomes the load. Control-plane bookkeeping (and this is the part most people overlook) can become the bottleneck long before any node runs short.

API traffic adds pressure. As agents call APIs more often, control-plane performance starts to determine whether the cluster stays responsive. My read is that this is where most of the real operational pain will show up first, well before raw compute runs out. Teams tend to size clusters by CPU and memory, so they'll be surprised when the API server slows down while the nodes look half empty. If you're working in this space, watch request latency and object counts before you watch utilization.

Agent Substrate and the near-term options

Google has contributed an open-source Agent Substrate framework to the CNCF to address the idle-pod problem. It separates stateful agent sessions and identities from active compute. Idle agents get snapshotted and stored, then restored when needed in under 500 milliseconds. Infrastructure is only consumed while an agent is working, which cuts costs. That model is closer to how serverless functions handle idle time, and it's a sensible direction because it treats an agent's state as data rather than as a running process.

The timeline is the catch. Enhancements to the Kubernetes control plane won't reach a mainstream distribution until next year. Until then, vendors are filling the gap. Solo.io, for example, is offering an enterprise edition of Agent Substrate that IT teams can deploy themselves. That's useful for teams that can't wait, but it also means you're adopting a commercial layer on top of an open project. You'll want to know exactly where the line between the two sits before you build anything on top of it.

That leaves a practical decision. Teams can wait for Kubernetes to mature for agent workloads, or adopt a more efficient framework on the distributions they already run. Agents are going to land on Kubernetes either way. The open question is whether the platform adapts quickly enough, or whether teams bring their own sandboxes and substrates to fill the gap while it does. Waiting carries its own risk, since agent deployments that start now will set patterns that are hard to unwind later.

What this means for you

Here's where I land. The density demo is interesting, but it answers the easy question. The hard questions are about idle cost, control-plane load, and isolation under real workloads, and none of those get settled by a single run on one server. Expect the next stretch to be messy. Density, then. Not destiny.

If you're running agents today, start by mapping which ones are narrow and which need a full VM. Measure idle time and API call volume per agent, not just peak CPU. Then test the isolation yourself, because the vendor's benchmark won't do that for you. It's not a glamorous plan, but it's the one that holds up when the agents start misbehaving.