Google's agent demo packs 31 sessions a pod where its stated duty cycle allows 151

Google's stated workload shape carries the whole packing argument: a burst of tool calls for 200ms, then 30 seconds idle waiting on a model, a human, or an API ^[10]. Divide it. Each agent is busy 0.2 seconds out of every 30.2, so one worker could in principle carry 151 of them ^[1]. The public demo carries 250 sessions on 8 pods ^[8], which is 31.25 per pod ^[2], about 21% of what the duty cycle allows ^[3]. The 151 assumes bursts never coincide. Agents driven by the same user-facing event do not idle independently, and queueing, not the mean, sets how many workers you provision.

The density comes from moving state. A large population of actors maps onto a small pool of workers, with full memory and filesystem state snapshotted out and rehydrated on demand ^[11]. A Hacker News commenter noted that Google already runs gVisor-based sandboxing at scale in GKE, along with pod snapshot and rehydration ^[15]. If that holds, AX points existing production capability at a new workload type. Google's design target is billions of concurrent agent tasks per cluster; the demonstrated figure is 250 on 8 ^[16].

Two layers publish restore figures, one in seconds and one below a second. GKE Agent Sandbox provisions 300 sandboxes per second at sub-200ms latency and snapshots idle agents to resume in seconds ^[6]. Agent Substrate, announced in May 2026, claims sub-second reactivation from a fully hibernated state ^[7][8]. Provisioning at up to 200ms against a 200ms active window is up to 100% overhead on the burst ^[4], and at 300 per second the entire 250-actor demo population would start cold in about 0.83 seconds ^[5].

The developer surface is four primitives: Task for isolated execution, Workspace for repos, MCP servers and skills, Gateway for egress allowlisting and credential injection, and Model for centralized model and secret configuration ^[12]. It is YAML submitted the same way as a Deployment or a Job, because it is a Kubernetes manifest ^[14]. Workspace also has a generative mode that takes a plain-English goal, such as "set up a Python 3 dev environment", and has the agent scaffold the rest ^[13].

The durability question attaches to the top of the stack. The repo is Apache 2.0 in the official Google GitHub org, without the "unofficial, not supported" disclaimers Google usually attaches to side projects ^[2]. It also has two names, AX internally and Agent Executor publicly ^[1]; products with settled ownership usually manage one. The skeptical case in the thread is that AX is a Google Cloud Platform effort that most of Google DeepMind has never touched ^[17]. The precedent cited is Gemini CLI, effectively superseded by Antigravity CLI after its consumer authentication path was deprecated in June 2026 ^[18]. Against that, Google's infrastructure open source record includes Kubernetes, Go, gRPC, TensorFlow, V8, JAX and Protobuf ^[19].

In my view the isolation layer is the part to build against now: it is generally available, built on gVisor ^[5], and the same sandboxing already runs in GKE ^[15]. The semantics that would need rewriting if the brand moves are in Agent Executor, which handles reconnection, session consistency through a single-writer architecture, and trajectory branching, the checkpoint-and-fork of an agent's decision path ^[9].