Google AX is Google's open-source agent orchestrator. You describe an agentic task in a YAML file, and AX spins up an isolated sandbox, pre-wires its Git repos, MCP servers and skills, picks the model, and runs it on a Kubernetes cluster. The README says it's built for billions of autonomous agent workloads.
📺 Watch: New AgentOS + Hermes is Absolutely WILD!
🆓 Start free: FREE AI Course + Community + 1,000 AI Agents — join 75,000+ members learning AI at no cost. → Join free
The project calls itself "Google's open agentic orchestration runtime." It lives at google/ax on GitHub under the Apache-2.0 licence, and the project site is agentexecutor.io. It's written mostly in Go. At the time of writing it has roughly 12,500 stars, around 600 forks and 17 contributors. The latest release is v0.3.1, the seventh release so far.
Read this before you get excited: the README warns that AX and several of its features are in heavy development, and major breaking changes are likely before a stable release. Treat Google AX as something to study and prototype with, not something to put in production today. I haven't run it myself. Everything below comes from the README and the commit history.
If you want the practical version of agents running a real business, the kind you can set up this week without a cluster, that's what we do inside the AI Profit Boardroom. More than 3,000 members build and share their agent setups there.
Why agents need their own orchestrator
Google's argument in the README is simple. AI agents are a new kind of workload, and the old boxes don't fit them. An agent isn't a stateless microservice that answers a request and forgets it. It isn't a batch job that runs once and exits either. Agents build up state as they work. They need strict isolation because they run code you didn't write. They call model APIs and tool servers all day. And, in the README's words, they "can burn money in a loop if nobody is watching."
That last point matters. One agent stuck retrying a task can quietly run up a big model bill. Multiply that by thousands of agents and you need the same kind of control layer that Kubernetes gave to containers. AX is Google's attempt at that layer for agents: it schedules them, fences them off, watches them and stops them.
Google AX: the three primitives
Per the README, AX is a high-throughput, declarative orchestrator that runs on top of Agent Substrate, which handles the sandboxed execution. The README also says: "If you have used Kubernetes, ax will feel similar." Manifests use the ax.io/v1alpha1 API version. Instead of writing scripts, you describe what you want and AX makes it happen. The whole model rests on three building blocks.
| You want to | AX gives you |
|---|---|
| Run untrusted agent code safely | Task: an isolated sandbox with CPU and memory limits |
| Have every agent start with the right tools already loaded | Workspace: pre-wired Git repos, MCP servers and skill packages, plus recently added support for inlined files |
| Control which LLM the agents use | Model: sets the provider and model, with credentials pulled from a Kubernetes secret |
The Task is the agent job itself. The Workspace means an agent starts warm: the repo is cloned, the MCP servers are connected and the skills are in place before it does anything. The Model block keeps model choice and API keys out of the agent's code. The README example sets Google as the provider with a Gemini 3.8 Flash model. Splitting it this way means you can swap the model or the toolset across a thousand agents without touching the tasks.
📺 Watch: Claude AI SEO System Ranks Me #1 on Google
Suspend, resume, ssh and watch
On top of the three primitives, AX gives you lifecycle controls built for how agents actually behave:
- Suspend and resume: checkpoint an idle agent and later pick up exactly where it left off. It doesn't start over and doesn't lose its state.
- ssh: shell into a running agent's sandbox when debug mode is on, so you can see what it's doing from the inside.
- watch: stream the agent's phase and condition changes live as it moves through its work.
Suspend and resume is the feature I'd pay attention to. An agent waiting on a human reply or a slow API doesn't need to hold a machine the whole time. Checkpoint it, free the resources and bring it back later. At cluster scale, that's how you keep agents from eating compute while they sit idle.
What a task file looks like
The README example is a good way to see how AX works in practice. You don't need to read any code to follow it.
The file has two parts. The first is a Workspace that clones the Go programming language repository on a chosen branch, so the agent opens its sandbox with the whole codebase already there. The second is a Task with one plain-English goal: "Ensure that Go tool chain is available and is built from source." Debug is switched on, so you can shell in while it works.
Then the workflow runs. You apply the file to the cluster and AX creates the sandbox, sets up the workspace and hands the goal to the agent. You watch the task come up phase by phase. Because debug is on, you can ssh in and look over the agent's shoulder while it builds the toolchain. The agent gets a goal and a prepared environment, and AX handles the plumbing.
Mid-way reality check: if you're a business owner and not a platform engineer, you probably don't need any of this yet. You need agents doing real work on your laptop. Book a free strategy session and we'll map out which agent setup actually fits your business.
📺 Watch: NEW Google Pomelli Update Is INSANE!
What you need to run AX
The AX command-line tool is deliberately built to feel like kubectl. It uses the same verbs: apply, get, describe, watch and delete, plus agent-specific commands such as suspend, resume and ssh. It follows whatever Kubernetes context is active on your machine, so it works with kubectx if you switch between clusters. Under the hood it talks to the AX control plane over gRPC, a fast remote-call protocol.
Per the README, here's what you need before you start:
- A Kubernetes cluster with Agent Substrate installed first. It runs in its own namespace and provides the sandboxing.
- Go and kubectl on your machine.
- ko, a tool that builds Go container images, plus a container registry your cluster can pull from.
- Install the AX command-line tool with Go, then deploy the control plane using the make target the project provides.
- Apply the example task to confirm everything works.
There's also a demo script that runs the whole lifecycle end to end: create, watch, suspend, resume and clean up. That's the quickest way to see AX working once your cluster is ready. Getting to that point takes real Kubernetes experience, though. This isn't a double-click install.
How fast AX is moving
The commit history shows how young AX is. A week ago the project was restructured into a general-purpose orchestration layer for agentic workloads. The latest commit replaced its Redis Streams queue and controller with direct execution. Those are big architectural changes happening week to week.
That fits the README warning. Google is still settling how AX should work, so anything you build on it now may break on the next release. That's normal for a v0.3.1 project. It's also why you should follow AX closely and wait before depending on it.
Who should care about Google AX (and who shouldn't)
Here's my honest take. Google AX is for platform and infrastructure teams that run agents at scale on Kubernetes: companies with hundreds or thousands of agents that need isolation, cost controls and a single control plane. AX is Google's answer to "how will companies run millions of agents safely?"
It isn't for solo operators. If you run a one-person business or a small team, a desktop agent stack is the right tool: Hermes, Claude Code and Agent OS running on the machine in front of you. The Agent OS guide walks you through that setup, and the best Hermes setup covers the configuration I'd start with.
The idea underneath AX isn't new to this site. In Hermes Bot Screen and the Hermes 3D office, each agent gets its own environment and you can watch what it's doing. Paperclip with Hermes takes the same approach to coordinating a team of agents. AX is that idea at cluster scale: every agent gets its own sandbox, its own workspace and a supervisor. If you want to compare how models perform inside setups like these, Goldie Bench is where I test them.
FAQ
What is Google AX?
Google AX is Google's open agentic orchestration runtime. It's a declarative orchestrator that runs AI agents in isolated sandboxes on a Kubernetes cluster, with pre-wired workspaces, configurable models and lifecycle controls such as suspend, resume, ssh and watch.
Is Google AX free?
Yes. AX is open source under the Apache-2.0 licence, so you can use and change it for free. You still pay for the Kubernetes cluster it runs on and for the model API calls your agents make.
Do I need Kubernetes for AX?
Yes. Per the README, AX needs a Kubernetes cluster with Agent Substrate installed first, along with Go, kubectl, ko and a container registry. If you don't have a cluster, a desktop agent stack is the better place to start.
Start with agents you can run today
Google AX shows where agent infrastructure is heading: sandboxed, declarative and built for huge scale. You don't have to wait for it to put agents to work. Inside the AI Profit Boardroom, 3,000+ members share the exact Hermes, Claude Code and Agent OS setups they use. Membership is locked at $69/month (normally $110). If you'd rather get a plan built around your business, book a free strategy session and we'll work out your next move with Google AX and the agent tools you can use now.
