Google has published AX, an open-source, declarative orchestrator for agentic workloads, and the framing is unusually blunt: it wants to be Kubernetes for agents. The repo’s own warning says the team is “still actively refining our core concepts, protocols, and specifications” and will “likely introduce major breaking changes prior to a stable release.” That is a strange thing to ship publicly. It is also the most honest sentence in the project.
AX is a high-throughput control plane that runs on top of something Google calls Agent Substrate for sandboxed execution. The pitch is scale: “billions of autonomous agent workloads in a cluster.” Whether that number survives contact with real infrastructure is an open question, but the design choices underneath it are worth reading closely, because they encode a specific theory of what agents actually are.
Four primitives, one thesis
The thesis is in the primitives. AX defines four: a Task (an isolated sandbox with CPU and memory limits), a Workspace (pre-wired Git repos, MCP servers, and skill packages so agents start warm), a Gateway (an explicit outbound host allowlist), and a Model (which LLM the platform itself uses, with credentials pulled from a Kubernetes secret).
Each one answers a failure mode that anyone running agents in production has already hit. Tasks accumulate state, so you need isolation and resource caps. Agents call out to model APIs and tool servers, so you need egress control that is an allowlist rather than a hope. Agents burn money in a loop if nobody is watching, so you need suspend and resume. And agents are neither stateless microservices nor run-to-completion batch jobs, which is the sentence in the README that should make platform engineers sit up.
That last point is the real argument. Kubernetes was built for two workload shapes: long-running services and finite jobs. An agent is a third shape. It holds state across a run, it needs to be checkpointed and resumed, and it needs a shell for a human to look over its shoulder. AX’s answer to that last need is ax ssh, which drops you into a running sandbox when spec.debug: true is set. That is a small feature and a large admission: the industry does not yet trust agents to run unattended.
The Kubernetes analogy is the point and the risk
The CLI is deliberately kubectl-shaped. You get apply, get, describe, watch, delete, plus agent-specific verbs like suspend and resume. It follows your active kubectx context, tunnels to the right control plane in the background, and scopes commands to an “atespace” that defaults to default. Manifests are ax.io/v1alpha1. A single task.yaml can declare a Workspace, a Task, a Gateway, and a Model together.
This is a smart bet on familiarity. Every platform team already has muscle memory for declarative YAML and a reconciliation loop. If agents are going to be operated by the same people who run clusters, meeting them in their existing vocabulary lowers adoption friction enormously. The comparison to Kubernetes is not marketing fluff; it is a compatibility strategy.
It is also where the risk lives. Kubernetes earned its complexity over a decade of production hardening. AX is at v1alpha1 and says so. The deployment path requires a Kubernetes cluster, ko, a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443). That is not a weekend project. The control plane lands in the ax-system namespace and depends on Redis. Anyone adopting this now is signing up for breaking changes.
The interesting thing about AX is not that it runs agents. It is that Google is treating the agent as a first-class workload primitive, the way Kubernetes once treated the container.
What the Model primitive quietly concedes
Buried in the CLI reference is a detail worth pausing on. The default model shipped in the examples is google gemini-3.8-flash, served under a google provider. That is the platform’s own LLM, configured separately from whatever models the agents themselves call.
The split matters. AX does not assume the orchestrator and the agent share a model. It treats the control plane’s model as infrastructure, with credentials from a Kubernetes secret, distinct from the model APIs an agent reaches through its Gateway allowlist. That is a more mature architecture than most agent frameworks ship with, and it implies Google expects multi-model deployments where the orchestration layer and the workload layer diverge.
The MCP tell
The Workspace primitive pre-wires “Git repos, MCP servers, and skill packages.” MCP here is the Model Context Protocol, and its appearance as a first-class workspace ingredient is the clearest signal of where the ecosystem has landed. A year ago, tool integration was bespoke glue per framework. Now a Google runtime treats MCP servers as something you declare alongside a Git branch and expect to be ready on boot.
That normalization is the quiet news in this release. The loud news is the scale claim and the Kubernetes framing. The quiet news is that the plumbing debates are settling, and the remaining fights are about orchestration, isolation, and cost control. AX is a bet that those three problems get solved in YAML.
What to watch
The repo is Apache 2.0, so the code is inspectable and forkable. The questions that will decide whether AX matters are not in the README. Does Agent Substrate actually isolate untrusted agent code at the level the security model implies? Does the suspend and resume path preserve state faithfully enough to trust with long-running work? And does “billions of tasks per cluster” hold up outside a benchmark?
For now, the honest read is that Google has shipped a well-shaped skeleton and told everyone it is a skeleton. Builders evaluating agent infrastructure should look at the four primitives as a design checklist even if they never run ax apply. Task, Workspace, Gateway, Model is a cleaner decomposition than most of what is on the market. The breaking changes are coming. The vocabulary might outlast them.