An infrastructure layer can run more agents while completing less useful work. Long queues, retries, tool timeouts, memory leaks, and excessive permissions can turn high density into hidden operating cost.
Two infrastructure signals
Google Cloud reported that GKE Agent Sandbox increased density from 61 to 88 OpenClaw agents on one VM in its test profile, or more than 40% more agents per vCPU and over 30% lower cost per agent. This was a vendor test on a specific configuration.
OpenWorker has attracted strong GitHub attention as a worker and agent-orchestration layer, but its README still marks the project as beta. Both signals justify an experiment. Neither proves stability with another workflow’s tools, data, and failure modes.
Metrics required before scaling
A baseline should include:
- cost per correctly completed task, not per running agent;
- p50 and p95 completion time, queue time, and retry rate;
- CPU, RAM, and network use while idle and under burst load;
- timeouts, crashes, and tasks requiring human intervention;
- filesystem, credential, and network isolation between workers.
Density matters only when the quality metrics remain stable. If workers share too much state or authority, compute savings can increase the blast radius of a failure.
What the evidence does not prove
The GKE result is not a guarantee for every model or toolchain. OpenWorker stars measure attention, not uptime, compatibility, or recovery quality.
Action this week
Run a non-sensitive PoC with capped concurrency and restricted worker permissions. Record a one-agent baseline, increase load gradually, and stop when failure rate or p95 latency crosses the agreed threshold.