Google Launches AX, Declarative Platform for Large-Scale Agent Execution
Google unveils AX, a declarative agent platform with isolation, network controls, and suspend-resume for billions-scale runs.
Google has released AX, a declarative execution platform for agentic workloads. According to the release information from google on GitHub Trending, it is described as a system that declares workspace and connectivity specifications and handles isolated execution and large-scale operation. The release date is 2026-09-24. Core concepts, communication procedures, and specifications are still being refined. The possibility of major breaking changes before a stable release is explicitly stated.
AX is positioned as a high-throughput declarative orchestrator. It is designed to run billions of autonomous agent workloads on a single cluster. It uses Agent Substrate for the execution layer. The architecture places a control plane on top of an isolated execution mechanism. It is said to feel familiar to those with Kubernetes experience.
Declare an agentic task with workspaces and gateway specifications. AX sandboxes it, wires up its workspace, fences its network, and helps running it at scale.
The above is a quote of the definition from the public repository. It presents task declaration, workspace wiring, network fencing, and large-scale execution support as a single set of functions. Declarative operation applied with a single command is at its core.
Kubernetes-Style Declarative Execution Platform
AX operations are described in manifests using ax.io/v1alpha1. It uses kinds such as Task, Workspace, Gateway, and Model. Multiple kinds can be combined in a single document and applied together. The commands are close to Kubernetes’ kubectl. apply, get, watch, suspend, resume, and ssh are provided.
In the sample task.yaml, a Workspace named golang is defined. golang/go.git is specified as the Git repository. The branch name is also included in the manifest. On the Task side, the workspace domain and a goal statement are specified. The goal statement describes ensuring toolchain availability and building from source. Setting debug to true enables internal inspection via ssh.
The flow after applying also follows a declarative platform. Apply with ax apply -f task.yaml. List status with ax get tasks. Track phase and condition changes with ax watch task test. Directly inspect the workspace inside the sandbox with ax ssh test. The google listing on GitHub Trending shows examples displaying the running agent, worker IP address, and elapsed time.
This approach directly ensures reproducibility. Git, model, and endpoint specifications can be kept in the document. Reapplying the same document aims to launch under identical conditions. Alongside the expanding infrastructure demand shown in Google Proves AI Investments Pay Off With Strong Cloud Performance, some see execution environments becoming increasingly standardized. AX is an attempt to bring that standardization to the agent domain.
Isolated Execution and External
Connectivity Controls
Agents differ in nature from both traditional microservices and batch jobs. They accumulate state and require strict isolation. They involve external calls to model APIs and tool servers. Unmonitored repetition risks runaway costs. AX is designed with this nature in mind.
A Task is the unit for running untrusted agent code in a sandbox. CPU and memory limits can be set. A Workspace pre-wires Git repositories, MCP servers, and skill packs. The aim is to start each run from a warm state. A Gateway restricts outbound traffic to an explicit host allowlist. A Model specifies the language model used by the platform itself. Credentials are stored in Kubernetes Secrets.
These four small primitives form the backbone of operations. Code isolation and launch conditions can be described separately. The scope of external connections can be audited in the document. Model swaps can also be tracked as manifest changes. As shown in Claude Chats Exposed in Google Search, external circulation of model outputs requires oversight. AX’s connectivity controls support that oversight at the platform level.
Pre-binding skill packs and MCP servers helps reduce startup time. Fetching them on every run increases latency and failures. Warm starts are effective for large-scale repetition. The allowlist approach is close to a default-deny posture. Only the minimum necessary external connections are allowed through. Fencing matters for both cost and data leakage.
Task Suspension and In-Sandbox Inspection Controls
AX provides means to intervene in running work. ax suspend pauses a waiting agent. It creates a checkpoint and stops processing. ax resume restarts exactly from the point of interruption. This directly helps control costs for long-running tasks.
ax ssh is a way to enter a running sandbox. It lets you inspect the inside with commands like ls -al /workspace. You can directly see the workspace contents and whether artifacts exist. watch streams phase transitions live. get is used to grasp overall status. The intended operation is to watch over behavior shoulder-to-shoulder.
This operational model suits iterative, trial-and-error development. Manifests can be edited and reapplied repeatedly. Internal inspection helps isolate failure causes. Suspending and resuming avoids wasteful recomputation. It leaves room for humans to intervene when autonomous behavior goes off track. It functions as a safety valve alongside cost limits.
The release information shows an example that packs Task, Workspace, Gateway, and Model into examples/task.yaml. Dependencies can be closed in a single document. This makes it easy to carry from testing to production. It operates at a different layer from user-facing features like 3 Practical Hidden Features to Optimize Your Commute in Google Maps. AX is a control layer for developers and operators.
Design Built for Billion-Scale Execution
AX targets billions of tasks per cluster. It aims to combine high throughput with declarative operation. The control plane lives in a namespace named ax-system. Redis is set up first. The control plane image is built and installed with ko.
Setup requires a Kubernetes cluster. ko and a container registry are also prerequisites. It must be able to reach the Agent Substrate control API. The in-cluster default is api.ate-system.svc.cluster.local:443. Install with make deploy, specifying the registry in AX_IMAGE_REPO. Install the CLI with go install github.com/google/ax/cmd/ax@latest. The ax binary is placed in bin under GOPATH. That path needs to be added.
The key to scaling is separating state management from isolation. Agent Substrate handles isolated execution. AX handles declarations, configuration, and monitoring. Redis is used to hold control state. Manifest-centered operation keeps API calls down. Watch commands also lean on subscribing to state changes.
The warning of breaking changes limits the scope of use. The current stage is for validating the specifications. Concepts and communication procedures continue to be revised. Caution is needed for adoption directly tied to production. Trials in test environments and for research purposes are likely to dominate. Even so, the declarative framework itself is likely to persist. Kubernetes-style operation keeps learning costs down.
Editorial Opinion
In the short term, trials are likely to increase among organizations with Kubernetes operational expertise. Compatibility with manifest management and continuous integration is high, and the barrier to building test environments is low. Because breaking changes are anticipated, production adoption is expected to remain limited.
In the long term, isolation of agent execution and external connectivity controls are likely to become platform defaults. Declarations of workspaces and endpoints will underpin auditing and cost management. As operational track records accumulate, the specifications are likely to stabilize.
The remaining questions are measured evidence to back the billion-scale claim and the effectiveness of cost controls. How far suspend and resume preserve state consistency remains unverified. Whether host allowlists will slow practical work is also an open question.
References
- “google / ax”, by google — GitHub Trending, 2026-09-24 (ARR)
- Source URL: https://github.com/google/ax
Frequently Asked Questions
- What does the AX platform do
- It defines agentic tasks in manifests and handles isolated execution, workspace wiring, network fencing, and large-scale operation. It describes the four elements of Task, Workspace, Gateway, and Model in ax.io/v1alpha1 and applies them with a single command.
- How does it relate to Kubernetes
- The operational feel is close to Kubernetes. It uses manifest apply, listing, watching, suspending, resuming, and in-sandbox access. The control plane is installed on Kubernetes, and Kubernetes Secrets are also used to store credentials.
- What is needed for installation
- A Kubernetes cluster, ko, a container registry, and a reachable Agent Substrate control API are required. After installing the CLI, place the control plane in ax-system with make deploy, and try the first task from examples/task.yaml.
Comments