Google · 2026-09-20 · major
AX v0.3.0 — Google's agent orchestrator moves task state to Redis
Google's AX agent orchestrator reached v0.3.0. The release splits it into three services and moves task state from Kubernetes custom resources to Redis Streams, so it can run millions of short-lived agent tasks. Apache-2.0, written in Go.
Google's open agent orchestrator splits into three services and keeps task state in Redis instead of Kubernetes.
Quick facts
| Maker | |
|---|---|
| Version | v0.3.0, released 2026-09-20 |
| License | Apache-2.0 |
| Language | Go |
| Components | ax-server, ax-controller, ax-task-runner |
| Task state | Redis Streams (replaces Kubernetes CRDs) |
| Primitives | Task, Workspace, Gateway, Model |
What is it?
AX v0.3.0 splits Google's open agent orchestrator into three separate services — an API front end, a reconciler, and a sandboxed task runner — replacing the single CLI with an embedded Python harness that earlier versions shipped. The release also removes the ATE client, the SQL event log and the bundled skill examples. It adds design, concepts, manifest, networking, runner and sandbox docs plus Kubernetes deploy manifests for the new architecture.
How does it work?
Task state in AX now lives in Redis rather than Kubernetes custom resources — the change the release commit says lets the system handle millions of short-lived tasks without straining etcd. Jobs are declared as YAML manifests built from four primitives that cover the sandbox, its pre-wired Git repos and MCP servers, its outbound network allowlist, and its model credentials. You apply a manifest the way you apply a Kubernetes object, then watch, suspend or resume the running task from the CLI.
Why does it matter?
Running coding agents at scale means starting and killing very large numbers of short jobs, and Kubernetes custom resources backed by etcd were not built for that churn. Redis Streams removes that ceiling. The Gateway primitive also gives platform teams one place to declare which hosts an untrusted agent may reach. The trade-off: v0.3.0 deletes the old Python harness and the ATE client, so anyone on v0.2.x faces a real migration.
Who is it for?
platform and infrastructure engineers
Frequently asked questions
- Do I need a Kubernetes cluster to run AX?
- AX expects a Kubernetes cluster. The README lists a cluster, the ko build tool, a container registry, and access to the Agent Substrate Control API as requirements, and v0.3.0 ships Kubernetes deploy manifests for the control plane. Redis is a separate dependency now that task state lives there. The ax CLI itself installs with a single go install command.
- What breaks if I upgrade from AX v0.2.x?
- Upgrading to AX v0.3.0 removes the legacy Python harness, the ATE client, the SQL event log and the bundled skill examples, so anything built against those is gone. The repository is reorganized around three binaries instead of one CLI with an embedded harness, and task state moves out of Kubernetes custom resources into Redis. Plan the move rather than bumping the version in place.
- How does AX limit what an agent can reach on the network?
- AX uses a Gateway resource to fence each task: the Gateway declares which listeners the task exposes and restricts outbound traffic to an allowlist of approved hosts and ports. Tasks run in sandboxed workers with CPU and memory limits. Those two controls together let a platform team run untrusted agent code without handing it open internet access.
- Is AX free to use?
- AX is free and open source under the Apache-2.0 license, published at github.com/google/ax. The repository has no paid tier. The real costs are operational rather than licensing: you supply the Kubernetes cluster, the Redis instance, the container registry, and the LLM API credentials that the Model resource points at.
Try it
go install github.com/google/ax/cmd/ax@latest