Google's AX runs AI agents the way Kubernetes runs pods
AX declares agent work as YAML manifests across four primitives and claims billions of tasks per cluster. Its API is still marked v1alpha1 and there is no announcement blog post.
6,657 stars, 318 forks, Apache 2.0, and an API the maintainers say will break your manifests.
AX, an open-source agent orchestrator published under the Google organization on GitHub, shipped v0.3.0 on September 20, 2026 and reached the front page of Hacker News the next day with 644 points. It is written in Go, licensed Apache 2.0, and carries 6,657 stars and 318 forks. The repository was created on March 30, 2026.
The model will be familiar to anyone who has written a Kubernetes manifest. AX has four primitives. Task is an isolated execution sandbox. Workspace is the pre-wired environment, git repositories and MCP servers included. Gateway sets network policy for what the agent may reach. Model holds the LLM configuration. You write them as YAML and apply them through a CLI that behaves like kubectl. Underneath sits Agent Substrate, Google's sandboxed actor runtime, which the project's site says provides sub-second resumption of suspended agents.
Read the version string
The README claims AX is built to run billions of tasks per cluster. That is a design target from the people who wrote it, on Google-scale infrastructure, not a figure anyone outside has reproduced, and there is no accompanying Google or DeepMind blog post, paper or benchmark to check it against. The site says the project was born at Google when agentic runtime systems research met frontier compute, and draws on DeepMind work, which is provenance rather than evidence.
The API is v1alpha1 and the maintainers say plainly that schema changes will break existing manifests. There is also a hard dependency on Agent Substrate, so this is not a library you drop into an existing service. The release history is short: v0.2.2 in July, v0.2.3 in August, v0.3.0 in September, and the v0.3.0 release notes are empty.
Why a build studio cares
We build agent workflows for clients, and the part nobody budgets for is the one AX names as a first-class object: Gateway, the network policy that decides what an agent can reach. Most agent code we inherit has no such boundary at all, because the framework never asked for one, and the agent ends up with whatever credentials the process it runs in happens to hold. Whether or not AX itself survives its alpha, the four-primitive split is the right shape to copy into a design review, and it is worth an afternoon of reading for that alone. What we would not do today is put a client's production agent fleet on a control plane whose maintainers have written down that your manifests will break.
Next step: read the AX repository and try the four primitives against your own agent design on paper, before writing any YAML. If you want a second opinion on where your agents' network boundary actually sits, write to us at hello@gattyworks.com.