Google's AX wants to run billions of agents. Its quickstart starts with a Kubernetes cluster.

Google has published a new agent runtime, and the project page leads with a sentence that does not sound like infrastructure at all: declare an agentic task, AX runs it at scale. Open the quickstart and you read something else. You need a Kubernetes cluster, ko, a container registry your cluster can pull from, and a reachable Agent Substrate control API. The distance between those two paragraphs became the story. The launch took roughly 626 points and 285 comments on Hacker News in a day, making it the most-discussed AI submission on the site at the time, and the loudest replies were not about the engineering. They were about who the tool was actually written for.

Where the promise meets the requirements

The repository, under Google's own organization, describes AX as "a high-throughput, declarative orchestrator to run billions of autonomous agent workloads in a cluster." The pitch is that agents are a new kind of workload, neither microservices nor batch jobs: they accumulate state, need strict isolation, call out to model APIs and tool servers, and can burn money in a loop if nobody is watching. AX's four primitives are meant to handle that declaratively, as ax.io/v1alpha1 YAML applied with a single command, behind a deliberately kubectl-shaped CLI.

That design decision is also the problem. In the Hacker News thread that carried the launch, the top-ranked reply did not dispute the architecture. It quoted both halves of the page back at it and drew the conclusion.

"Call me old-fashioned but I don't find this 'easier'. Maybe it's easier in the same way that Kubernetes itself is easier than managing VMs and container deployments at massive scale without such a tool. But there's a vast chasm between what this tool is being sold as and what it actually is." — alembic_fumes, on Hacker News

A shorter reply made the same point as a joke, setting the project's stated goal against its prerequisite: "We want to make dealing with agentic infrastructure easier" and "Kubernetes" — pick one. The complaint is not that the tool is bad: the marketing and the installation instructions describe two different products, and only one is on the homepage.

Four primitives, three of them plumbing

AX's answer is that the primitives are small, and that is the strongest part of the pitch.

Primitive	What it declares
Task	An isolated sandbox with CPU and memory limits
Workspace	Git repos, MCP servers and skills, or a goal in plain English
Gateway	An explicit allowlist of hosts and ports, plus credential injection
Model	Model choice, parameters and secrets in one place

The novelty is in the combination: they are declarative and come up together in one file, so an agent starts with its repos cloned, its tools wired and its network fenced. The generative part is the odd one out — AX can take a plain-English goal such as "Set up a Python 3 development environment" and hand it to an agent on first boot, the most interesting feature in the docs and the easiest to mock, which one commenter did in a single word. The system underneath is harder to dismiss. AX runs on Agent Substrate, a separate project in its own organization with roughly 940 commits, and Substrate is not a library: it ships a control-plane API server, a node-level daemon for snapshotting, an Envoy networking controller and two sandbox executors, one based on gVisor checkpointing and one on micro-VMs.

The number that is doing two jobs

The scale claims are vendor claims, unaudited, and the page does not pretend otherwise: billions of tasks per cluster, one lightweight actor per task, "billions of concurrent agent sessions per cluster without orchestrator limits," dense multiplexing so dozens of tasks share a worker's resources, and sub-second resumption with "zero cold-start delay."

The mechanism behind some of it is visible in the code. On September 20 the repository was restructured around three binaries — a gRPC API server, a reconciler consuming Redis Streams, and a task runner in sandboxed workers — with task state moved out of Kubernetes custom resources into Redis, explicitly so millions of short-lived tasks do not strain etcd. That is a real answer to keeping the control plane off the critical path; commenters who have run heavy controllers against the API server and etcd know how easily those grind to a halt.

The demand side got less scrutiny, and more doubt. One reply asked only "People can afford to run billions of concurrent agents?" Another answered: "billions? who is running BILLIONS of agents? tens, hundreds, maybe a couple thousand at a time? absolutely." The most useful reframing accepted the shape of the workload but not the size of the number: big bursty fleets for evals, reinforcement learning and training, not the daily work of a software team.

The objection that will decide adoption

The technical argument that matters most in the thread is not about task counts. It is about identity. Because AX multiplexes dozens of tasks onto shared workers, one commenter argued, "you can no longer trust the k8s pod identity as being from a singular workload" — after conceding that in enterprise environments Kubernetes is likely already there, and that the stranger requirement is ko, a niche image builder. The same commenter called the identity gap "a barrier to adoption for us."

A self-identified person working on the runtime answered directly: Agent Substrate is an OIDC and SPIFFE identity provider, and credentials carrying the actor's identity can be injected into outbound requests through the Substrate egress gateway — work described as in flight and expected to land "within a few weeks." Treat that as a contributor's roadmap, not a shipped feature. It is also the crux of the story. Fleets of agents already have a documented record of doing things nobody asked them to, which is why shared worker identity is the wrong place to economize. If the egress identity injection lands as promised, the oversubscription objection weakens considerably; until then it stands.

Who should actually try this

If you already run a Kubernetes estate, the entry cost is close to zero: AX follows your active kube context, and the primitives will feel familiar rather than novel. That is a legitimate audience, and the project is honest about being early — the README warns that core concepts and specifications are still being refined and that "major breaking changes" are likely before a stable release. Six hundred and twenty-five commits in, it should not be anyone's production dependency this month.

If you do not run Kubernetes, nothing in AX's ergonomics pitch helps you. The tool sells a joyful workflow and delivers a platform, which is the same shape as arguments about tooling that markets simplicity while requiring a stack underneath. It usually resolves the same way: the project either grows a single-machine path or settles into the infrastructure tier it was built for.

Google markets AX to researchers as a way to spin up "a massive number of reproducible sandboxes to collect trajectories, run reinforcement learning loops, and evaluate agents at scale." That is the audience the architecture fits, and the one that will produce the first credible answer to whether billions is a real number or a capacity ceiling nobody reaches. What would settle the rest: a published benchmark of the scale claim, and identity injection shipping on the schedule a contributor described rather than on the roadmap.