# Google Open Sourced AX, an Orchestrator for Billions of AI Agents. Hacker News Isn't Buying the Number. > Source: > Published: 2026-09-22 16:05:18+00:00 Google published a new open source project, and within a day it was the most discussed AI submission on Hacker News. The project is AX, short for Agent Executor, and the pitch is bold: declare an agentic task, and AX runs it at scale. Not ten agents. Not a thousand. The repository describes it as "a high-throughput, declarative orchestrator to run billions of autonomous agent workloads in a cluster." The community reaction was instant and split. The launch thread gathered 649 points and 296 comments in roughly 48 hours. Almost nobody argued that the engineering is bad. The argument was about something else: the gap between what the homepage sells and what the quickstart demands. That gap is worth understanding, because it reveals where the whole "agentic infrastructure" category is heading, and whether any of it belongs in your stack this year. Full disclosure before we go further: I have not run AX myself. Everything here comes from the repository, the project pages, the launch discussion, and reporting from Traictory that sorted through the thread. Treat this as a guided tour of the debate, not a hands-on review. `ko` image builder, a container registry your cluster can pull from, and a reachable Substrate control API. That last bullet is where the launch went sideways. The project page opens with a line that sounds like a developer tool: declare an agentic task, AX runs it at scale. The quickstart opens with a line that sounds like a platform team's quarterly project: you need Kubernetes, `ko`, a registry, and a control API. The top-ranked reply on Hacker News put it directly. The commenter said they do not find this "easier," unless it is easier the way Kubernetes itself is easier than managing VMs at massive scale, and concluded that there is "a vast chasm between what this tool is being sold as and what it actually is." Another reply compressed the whole thread into a joke: "We want to make dealing with agentic infrastructure easier" and "Kubernetes", pick one. This is a familiar pattern. A tool markets simplicity and delivers a platform. It usually resolves one of two ways: the project grows a single-machine path, or it settles into the infrastructure tier it was always built for. Neither outcome has happened yet for AX. The README itself warns that core concepts are still being refined and that "major breaking changes" are likely before a stable release. At 623 commits, this is nobody's production dependency this month, and the project does not pretend otherwise. The actual design is more interesting than the launch drama. AX defines four primitives, and you declare them in YAML under `ax.io/v1alpha1`, using a CLI deliberately shaped like `kubectl`. Any one of these exists elsewhere. The novelty is the combination: declarative, in one file, so an agent boots with its repos cloned, its tools wired, and its network fenced. If you have ever stitched together a Docker sandbox, a proxy allowlist, and a secrets mount by hand, you know exactly how much glue code these four primitives replace. The generative part is the odd one out. Handing a plain-English goal to an agent on first boot is the most interesting feature in the docs and the easiest one to mock. One Hacker News reply did mock it, in a single word. Look past the "billions" headline and there is a genuinely clever system decision 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. Task state moved out of Kubernetes custom resources into Redis, explicitly so millions of short-lived tasks do not strain etcd. Anyone who has run a heavy Kubernetes controller knows why this matters. Etcd degrades gracefully right up until it does not, and controllers that hammer the API server grind entire clusters to a halt. Keeping the hot path out of the Kubernetes control plane is the same lesson every large-scale Kubernetes operator learns eventually. AX learned it before 1.0, which is a good sign for where the project is going. The core insight underneath Substrate is economic, and the project states it plainly: agents are idle most of the time. Substrate maps a larger set of actors onto a smaller set of ready workers, multiplexing dozens of agent sessions per physical pod. Their own demo shows roughly 250 stateful actor sessions across 8 pods, with sub-second suspend and resume. If agents mostly sit waiting on model API calls, paying for a full pod per agent is waste, and multiplexing is the fix. Then there is the scale claim. "Billions of concurrent agent sessions per cluster without orchestrator limits." The Hacker News thread did not let that pass. Both things can be true. "Billions" can be a real capacity ceiling for bursty research fleets while being irrelevant to everyone shipping product. Google's own marketing points at researchers: spin up massive numbers of reproducible sandboxes, collect trajectories, run RL loops. That is the audience the architecture actually fits. What would settle the debate is simple and has not happened: a published, audited benchmark of the scale claim. Until then, "billions" is marketing. The most consequential argument in the thread was not about task counts. It was about identity. AX multiplexes dozens of tasks onto shared workers. One commenter pointed out the consequence: once you do that, "you can no longer trust the k8s pod identity as being from a singular workload." In a normal Kubernetes setup, a pod is a security and audit boundary. You know what ran in it, what credentials it had, and what it touched. In a multiplexed substrate, dozens of unrelated agents share a worker, and the pod stops being a meaningful identity for any of them. The same commenter called this "a barrier to adoption for us." A person working on the runtime answered in the thread: 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. Important caveat: that work was described as in flight, landing "within a few weeks." Treat it as a roadmap, not a shipped feature. This matters more than it might seem. Agent fleets already have a documented record of doing things nobody asked them to. When every agent carries verifiable identity on every outbound call, you can audit, rate-limit, and revoke per agent. Until that ships, the oversubscription that makes AX cheap is the same thing that makes its security story incomplete. Here is the save-worthy part, based on everything the launch thread and the repos tell us. The honest one-line summary: AX is a research-grade orchestrator for bursty agent fleets, wearing an easy-button costume it has not earned yet. Set aside AX itself. The launch tells you where the industry thinks the money is. Two years ago the question was "how do I call an LLM." A year ago it was "how do I give my agent tools." Now Google is building the layer above that: how do I run, suspend, resume, fence, and audit thousands of agent sessions economically. Substrate's multiplexing bet, that agents are mostly idle and can share hardware, only makes sense in a world with a very large number of agent sessions per customer. Whether AX wins or not, someone will make this layer work. The open questions this thread surfaced, per-agent identity, honest benchmarks, a single-machine path, are exactly the checklist to judge every "agentic infrastructure" announcement against for the next year. I write about AI tooling, agent systems, and developer infrastructure every week. Subscribe, it's free, and it keeps these breakdowns coming. Have you tried AX or Agent Substrate, or are you running agent fleets on something else? What did your wait time to first agent cost you? Tell me in the comments. **Sources:** [google/ax on GitHub](https://github.com/google/ax), [Agent Substrate](https://github.com/agent-substrate/substrate), [the Hacker News launch thread](https://news.ycombinator.com/item?id=49780797), and [Traictory's review of the launch](https://traictory.com/news/2026-09-22-google-ax-agent-orchestrator). Scale claims are vendor claims unless a benchmark says otherwise.