AX is Google’s open-source control plane for running large numbers of stateful AI-agent workloads in isolated environments. It gives developers Kubernetes-like declarative resources for a workload that does not behave like a normal web service or batch job: an agent can work intensely, wait for a model or human, preserve state, and resume later.
The project is real and lives in the official google/ax GitHub repository under Apache 2.0. It is also explicitly pre-stable. Google’s README warns that core concepts, protocols and specifications may receive major breaking changes before a stable release. AX is not a hosted Google Cloud product, and installing it is not comparable to enabling a managed API.
What AX does
AX separates an agent deployment into four resources:
| Resource | Responsibility |
|---|---|
| Task | Runs an isolated agent workload with CPU and memory limits |
| Workspace | Prepares Git repositories, MCP servers, skills and other working context |
| Gateway | Controls network access and credential injection |
| Model | Centralizes provider, model parameters and secret references |
These resources use ax.io/v1alpha1 manifests. Developers apply, inspect, watch, suspend, resume and delete them through an ax CLI shaped like kubectl.
AX builds on Agent Substrate, a separate runtime focused on dense, stateful actors and sandbox lifecycle. AX adds the agent-specific control plane and abstractions above that substrate.
Task: the execution unit
A Task is the running workload. It binds one or more workspaces, starts the configured runner, and tracks lifecycle state. With debugging enabled, an operator can use ax ssh to inspect the environment.
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
name: repository-review
spec:
workspaces:
- name: application
goal: "Prepare the repository and run its tests"
debug: trueThe Task abstraction is useful because an autonomous coding session is not a stateless request. It may create files, run tests, call an MCP tool, wait for approval, and resume with the same filesystem state. AX exposes suspend and resume as first-class operations instead of forcing every application to invent checkpoint behavior.
The isolation boundary still needs review. A sandbox limits a process, but safety also depends on images, mounted data, network policy, credentials and the runner implementation. See our agent sandboxing guide for the broader threat model.
Workspace: repositories, MCP and skills
A Workspace describes what the agent needs before it can work. The official examples include Git repositories, MCP servers and skill packages. AX can also use a natural-language goal to prepare an environment when it first boots.
That convenience creates a governance question. A generated environment is harder to reproduce than a pinned image and lockfile. Production teams should prefer explicit repositories, immutable revisions, controlled dependencies and auditable skills for consequential workloads. Use generative setup for experiments, then convert what worked into a reproducible definition.
MCP support means a workspace can arrive with access to external tools and data. It does not mean every MCP server is trusted. Apply the same server review, authentication and permission boundaries described in our MCP developer guide and AI security hub.
Gateway: network and credential boundaries
Gateway resources define network policies, including explicit hosts and ports, and can inject credentials into permitted requests. This is one of AX’s most important ideas. Agents routinely fetch dependencies, call model providers and connect to tool servers. A default-open network gives compromised code or a bad tool call too much room.
Start with an allowlist for the exact model API, package registries and services required by the Task. Keep provider credentials in Kubernetes secrets rather than manifests or prompts. Separate read-only data access from write-capable production credentials, and log outbound destinations independently of the agent’s own explanation.
A Gateway is a policy mechanism, not proof that the overall deployment is secure. DNS, proxy, metadata-service and credential-injection behavior still need adversarial testing.
Model: central configuration
The Model resource centralizes the provider, model choice, parameters and secret reference used by AX’s generative platform features. That helps operators rotate a key or pin a model without rewriting every task.
It should not hide model lifecycle changes from application owners. A new model version can change tool selection, latency, cost or output format. Treat a Model update like a dependency upgrade: evaluate it, stage it and keep a rollback path. Our LLM regression-testing guide explains how to gate those changes.
Installation requirements
AX is infrastructure software, not a desktop agent. The official quick start requires:
- A Kubernetes cluster
kofor building and publishing Go container images- A container registry the cluster can access
- A reachable Agent Substrate Control API
- Redis deployed as part of the control-plane setup
- Kubernetes permissions to create the AX control plane and resources
The CLI can be installed with:
go install github.com/google/ax/cmd/ax@latestDeployment uses the repository’s Makefile and a target registry:
make deploy AX_IMAGE_REPO=REGISTRY/PROJECTDo not run a moving latest build directly in a production cluster. Pin a reviewed commit or release when the project begins publishing stable releases, and examine the generated images and permissions first.
A minimal lifecycle
After deploying the control plane, operators apply a manifest and inspect the Task:
ax apply -f task.yaml
ax get tasks
ax watch task repository-review
ax ssh repository-review -- ls -la /workspace
ax suspend task repository-review
ax resume task repository-review
ax delete task repository-reviewThis lifecycle resembles Kubernetes, but the workload semantics are different. Suspend and resume preserve agent state, while workspaces and gateways encode context and permissions specific to agent execution.
Where AX fits
Coding-agent fleets: Create isolated workspaces for repository tasks, with controlled Git and network access.
Evaluation pipelines: Run many reproducible agent trajectories against the same task set and capture outcomes.
Research infrastructure: Suspend idle experiments while models, tools or human reviewers respond.
Headless browser testing: Give each run an isolated environment and a narrow network allowlist.
Custom agent services: Host a long-running runner while keeping workspace and model configuration declarative.
For smaller applications, this may be excessive. A queue, container runtime and explicit worker can be easier to operate. Our agent orchestration patterns guide helps decide when a control plane is justified.
What AX is not
- It is not a hosted Google Cloud agent service.
- It is not a model and does not replace Gemini, Claude or OpenAI APIs.
- It is not a desktop coding assistant.
- It is not stable according to the project’s own warning.
- Its massive-scale claims are project goals, not independent production benchmarks published here.
- It does not make untrusted MCP servers, skills or repositories safe automatically.
My take
AX is one of the clearest attempts to define agent workloads as infrastructure primitives rather than ordinary jobs. Task, Workspace, Gateway and Model form a useful mental model even if you never deploy AX. The software itself is for teams already comfortable operating Kubernetes and evaluating an early control plane. It is worth testing in an isolated cluster, but not yet a drop-in foundation for a production product that cannot tolerate breaking changes.
FAQ
Is AX really a Google project?
Yes. The repository is under the official google GitHub organization. The project says it originated from agent-runtime work at Google and draws on Google DeepMind research experience.
Is AX a Google Cloud service?
No. AX is open-source software you deploy with Kubernetes and Agent Substrate. The project does not present it as a managed Google Cloud product.
Does AX require Kubernetes?
The current official deployment flow does. It also requires ko, a registry and access to the Agent Substrate Control API.
Does AX support MCP?
Yes. Workspaces can include MCP servers, alongside Git repositories and skills. Operators still need to authenticate and restrict those servers.
Is AX production-stable?
No. Its README warns that major breaking changes may occur before a stable release.