AX ships as Google's open orchestrator for agent workloads

What happened

Google released AX, an open source orchestrator for running agent workloads in a cluster, as the repository google/ax under an Apache 2.0 licence. The project reached the Hacker News front page on 20 September 2026 under the title "AX – Google's Open Agentic Orchestrator," gathering 294 points and 113 comments. It runs on top of Agent Substrate, a separate Google-linked open source runtime for sandboxed agent execution.

AX is a declarative orchestrator for running agent workloads inside a Kubernetes-style cluster. It gives every agent task its own sandbox, a workspace of cloned repositories, MCP servers and skills, a network gateway restricted to an allowlist of hosts, and a named model configuration, all applied with one YAML manifest and the ax command line tool.

What changed

AX defines four resource kinds, documented in its core concepts, applied together with ax apply -f task.yaml:

• Task: the smallest unit of isolated execution. It declares a container image and command, compute requests and limits, environment variables, a reference to a Gateway, and one or more Workspaces. Its status.phase reads Running, Suspended, Failed or Terminating, and it carries WorkspaceReady, GatewayReady and Ready conditions that ax watch streams live.
• Workspace: populates the sandbox's filesystem and tool landscape once, then binds to as many tasks as needed. It clones git repositories into the workspace path, wires up MCP servers and registries the agent can call, and sets up a skill registry path. A binding can also carry a plain-language goal; on first boot the runner hands that goal to an agent that finishes the setup itself, for example installing a toolchain.
• Gateway: the task's network boundary. It declares the listeners a task exposes and an egress allowlist of hosts and ports, so an agent can be restricted to, say, its model provider and its git host.
• Model: not a model itself but a named configuration, holding the provider, the model identifier, generation parameters such as temperature, and a reference to the Kubernetes secret holding the API key. Rotating a key or pinning a new model version becomes one ax apply instead of a hunt through every task's environment.

Inside every task container, ax-task-runner runs as PID 1. It starts a metadata daemon on port 80 exposing /healthz, /readyz and endpoints that return the live Task and Workspace specs as YAML. When a workspace binding carries a goal, the runner hands it to an agent that needs a GEMINI_API_KEY in the container and gets a 10 minute default timeout, configurable through AX_BOOTSTRAP_TIMEOUT. Setting spec.debug: true turns on gRPC guest services for process control and file access, which is what ax ssh uses to shell into a running sandbox; without it, ax ssh refuses to connect.

The ax CLI is deliberately kubectl-shaped: apply, get, describe, watch, suspend, resume, delete, plus ax ssh. AX itself runs on Agent Substrate, which the AX site says checkpoints an idle task waiting on a model or tool response and brings it back with no cold start, so a fleet of agents can share worker capacity while they wait.

Why it matters for agent builders

Agent workloads do not fit either of the shapes cluster tooling was built for: they are not stateless microservices and not run-to-completion batch jobs. They hold state across a session, need strict isolation from each other, and can keep spending on model calls in a loop if nothing is watching. AX's suspend and resume model means an agent idled on a tool call does not have to keep an idle sandbox billing in the meantime.

Because Workspace treats MCP servers and skill registries as setup steps rather than something each task wires up by hand, it gives a concrete integration point for anyone shipping an MCP server or packaging a skill for use inside someone else's cluster of agents, not only inside a single client such as Claude or Cursor. And Gateway's egress allowlist is a direct, checkable answer to the kind of boundary failure that turns an agent's task into an unintended network client: restrict the sandbox to the hosts it actually needs before it starts.

What to watch

AX's own documentation is candid that it is early: the README states its core concepts, protocols and specifications are still being refined and warns that breaking changes are likely before a stable release. It also assumes a Kubernetes cluster and, for any workspace that uses a plain-language goal, Google's own Antigravity agent and a Gemini API key to bootstrap it, so teams outside Google's stack take on that dependency to use the feature at all.

Key takeaways

• AX is Google's open source orchestrator (Apache 2.0, google/ax) for running agent workloads as isolated, suspendable tasks in a cluster.
• It defines four primitives, Task, Workspace, Gateway and Model, applied declaratively with the kubectl-shaped ax CLI.
• Workspace treats git repositories, MCP servers and skill registries as first-class, one-time setup that binds to any number of tasks.
• Gateway restricts a task's outbound network to an explicit allowlist of hosts and ports.
• AX's own README warns that its concepts and protocols are still changing and that breaking changes are likely before a stable release.

FAQ

What is Google's AX?

AX is Google's open source, declarative orchestrator for running large numbers of isolated agent workloads in a Kubernetes-style cluster. It is built on top of Agent Substrate, a separate runtime for sandboxed, resumable execution, and is released under the Apache 2.0 licence.

What are the four core resources in AX?

Task, Workspace, Gateway and Model. A Task is the isolated unit of execution; a Workspace wires up its git repositories, MCP servers and skills; a Gateway sets its network allowlist; a Model names which provider, model identifier and credential secret a task uses.

Is AX ready for production use?

Not according to its own documentation. The project's README states that its core concepts, protocols and specifications are still being actively refined and warns that major breaking changes are likely before a stable release.

Source: google/ax Discussion: Hacker News

Teams choosing which MCP servers to wire into a workspace like this can compare current options in the MCP servers directory on aiagentslisting.com.