Cosmonic demonstrated a Kubernetes cluster running wasmCloud on a single 64-core server that could support 1.42 million sandboxed environments, making the case for WebAssembly as a way to host large numbers of narrowly focused AI agents. The demonstration took place at KubeCon + CloudNativeCon North America 2026.
The reported figure describes the number of sandboxed environments the setup could support, not necessarily 1.42 million agents simultaneously performing resource-intensive work. Still, the result highlights a potential alternative to assigning every agent a conventional Kubernetes pod: running task-specific workloads in lightweight WebAssembly sandboxes.
Cosmonic CTO Bailey Hayes said teams could use the approach to deploy AI agents on existing Kubernetes instances. The company is promoting its open-source wasmCloud platform, which includes a Kubernetes Operator for deploying WebAssembly components. The project is being advanced as open source under the Cloud Native Computing Foundation (CNCF).
Matching sandbox size to agent workloads
WebAssembly may suit agents designed to carry out a limited set of tasks, according to Hayes. Such workloads may not need the resources of a larger isolation environment. An AI coding agent, by contrast, could require a more substantial sandbox based on a micro virtual machine, she said.
Isolation is also a security consideration. Without a sandbox, an agent could potentially reach services or applications it should not be able to access. A compact execution environment can therefore help teams separate agent workloads while limiting the infrastructure overhead associated with running them.
The approach addresses one part of a broader scaling problem for AI agents on Kubernetes. If each persistent agent gets its own pod, CPU and memory can remain allocated even when that agent is idle. Large numbers of persistent objects also create work for the Kubernetes control plane, which must track them. As agents make more calls to application programming interfaces, control-plane performance can become another constraint.
Alternative approaches target idle agents and scale
Cosmonic’s wasmCloud demonstration is one of several efforts aimed at improving how agents run on Kubernetes. Google has contributed the open-source Agent Substrate framework to the CNCF. It is designed to separate stateful agent sessions and identities from active compute.
With Agent Substrate, idle agent sessions can be snapshotted and stored, then restored when needed. The framework is described as being able to restore them in under 500 milliseconds. The intended benefit is to avoid keeping compute resources engaged for agents that are not currently active. This differs from the wasmCloud emphasis on using lightweight WebAssembly sandboxes for agent execution.
Both efforts reflect the challenge of using Kubernetes for workloads that may involve very large populations of long-lived agents. Current deployments can consume resources while agents wait, while the control plane must manage persistent workload objects and the API activity associated with them. The source material notes that Kubernetes performance enhancements are needed, but says they are not expected to reach a Kubernetes distribution until next year. It does not specify which enhancements or a release schedule.
In the interim, vendors are also offering deployment options. Solo.io is making an enterprise edition of Agent Substrate available for teams to deploy themselves, according to the report.
A choice for platform teams
For organizations planning agent deployments, the approaches address different parts of the problem. WebAssembly sandboxes may provide a compact execution model for agents with narrow responsibilities, while Agent Substrate focuses on suspending and restoring idle, stateful sessions. Neither approach removes the need to evaluate workload requirements, isolation needs and operational fit.
The demonstration gives platform teams a concrete example of the density that wasmCloud can support in a particular server configuration. It should not be read as a universal capacity figure: the number of environments an installation can run will depend on the workloads and resources involved. The broader decision is whether to adopt an alternative framework on current Kubernetes distributions or wait for Kubernetes and its ecosystem to better accommodate agent workloads.
