Google's Open-Source AX Agent Orchestrator Meets Skepticism Over 'Billions' Claim

Google has open-sourced AX, short for Agent Executor, a declarative orchestrator its repository describes as capable of running billions of autonomous agent workloads in a cluster. Released under Apache 2.0 on Google's GitHub organization, the project became the most-discussed AI submission on Hacker News within a day, gathering 649 points and 296 comments in roughly two days, according to a dev.to write-up of the launch.

What AX actually is

Per dev.to, AX is a distributed runtime for agent workloads running in isolated environments. It depends on a separate project, Agent Substrate, which supplies a control-plane API server, a node daemon for snapshotting, an Envoy networking controller, and two sandbox executors, one built on gVisor and one on micro-VMs. Substrate carries a disclaimer that it is not an officially supported Google product.

At the time of the dev.to report, the repository had around 1,968 stars and 623 commits. The README warns that core concepts are still being refined and that major breaking changes are likely before a stable release.

The gap between pitch and prerequisites

Much of the Hacker News reaction focused not on engineering quality but on the distance between the marketing and the setup. The project page frames AX as a simple proposition: declare an agentic task and it runs at scale. The quickstart, by contrast, requires a Kubernetes cluster, the ko image builder, a container registry the cluster can pull from, and a reachable Substrate control API.

As dev.to reports, the top-ranked reply argued there was a vast chasm between what the tool is sold as and what it actually is, and that it is only "easier" in the sense that Kubernetes is easier than managing huge numbers of VMs. Another commenter compressed the thread into a joke: making agentic infrastructure easier and requiring Kubernetes, pick one.

Four declarative primitives

The design itself drew more interest. AX defines four primitives, declared in YAML under ax.io/v1alpha1 with a CLI deliberately shaped like kubectl:

• Task: an isolated sandbox with CPU and memory limits, one actor per task.
• Workspace: what the agent starts with, such as cloned Git repositories, wired MCP servers and skills, or even a plain-English goal handled on first boot.
• Gateway: an allowlist of hosts and ports plus credential injection, forming the network fence around the agent.
• Model: model choice, parameters and secrets in one place.

None of these is individually novel, dev.to notes. The appeal is the combination: a single declarative file that boots an agent with its repositories cloned, its tools wired and its network fenced.

The engineering under the headline

According to the dev.to article, the repository was restructured on September 20 around three binaries: a gRPC API server, a reconciler consuming Redis Streams, and a task runner in sandboxed workers. Task state was moved out of Kubernetes custom resources into Redis, explicitly so that millions of short-lived tasks would not strain etcd.

The economic insight underneath Substrate, stated by the project itself, is that agents are idle most of the time. Substrate maps a larger set of actors onto a smaller set of ready workers, multiplexing many agent sessions per pod. The project's own demo reportedly showed roughly 250 stateful actor sessions across 8 pods, with sub-second suspend and resume.

The number nobody believes

The claim of billions of concurrent agent sessions per cluster, without orchestrator limits, drew sharp pushback. Commenters asked who could afford billions of concurrent agents, while the most constructive reframing accepted the workload shape but rejected the figure: realistic usage would be large, bursty fleets for evaluations, reinforcement learning and training-data collection, not everyday software-team work. Google's own messaging points at researchers, which is the audience the architecture fits. As dev.to concludes, both things can be true, and no published, audited benchmark of the scale claim exists yet.

An identity problem that may decide adoption

The most consequential objection concerned identity rather than task counts. Because dozens of tasks share a worker, one commenter argued that Kubernetes pod identity can no longer be trusted as belonging to a single workload, since a pod normally serves as a security and audit boundary. The commenter called this a barrier to adoption. A person working on the runtime responded in the thread that Substrate functions as an OIDC and SPIFFE identity provider, and that credentials carrying an actor's identity can be injected into outbound requests through the egress gateway. That work was described as still in flight.

Why it matters

AX is an early signal of where agentic infrastructure is heading: declarative, sandboxed, multiplexed agent fleets treated as a cluster scheduling problem rather than a per-agent container problem. The Hacker News debate previews the adoption questions every similar system will face, from honest scale numbers to whether security and audit models survive the loss of one-workload-per-pod isolation. With major breaking changes promised, identity work unfinished and no audited benchmarks published, AX reads today as an ambitious experiment, not a production dependency, and the project does not pretend otherwise.