Google Open-Sources AX, an Orchestrator Built to Run Billions of AI Agents

Google has open-sourced AX, a declarative orchestrator designed to run agent fleets at massive scale. The project's marketing leads with an ambitious promise — declare an agentic task, AX runs it at scale — but the quickstart documentation tells a different story: you need a Kubernetes cluster, a container registry, and a reachable Agent Substrate control API before you write your first agent definition.

The gap between promise and prerequisites became the defining story of AX's launch, generating over 600 points and 285 comments on Hacker News in a single day.

What AX Actually Is

AX is an orchestration runtime for AI agents — software systems that can autonomously perform multi-step tasks by calling tools, accessing APIs, and making decisions. Where individual agent frameworks (LangChain, CrewAI, Google's own Agent Development Kit) focus on building single agents, AX focuses on running fleets of them.

The declarative model means developers describe what they want an agent to accomplish rather than programming every step. AX handles scheduling, resource allocation, failure recovery, and scaling across the agent fleet.

Google positions AX primarily for researchers: spinning up reproducible sandboxes to collect training trajectories, run reinforcement learning loops, and evaluate agents at scale. The architecture supports running thousands or millions of agent instances in parallel, each operating in an isolated environment.

The Kubernetes Requirement

The quickstart's infrastructure prerequisites sparked the most debate:

• A running Kubernetes cluster
• ko for building container images
• A container registry accessible from the cluster
• A reachable Agent Substrate control API

For teams already running Kubernetes at scale — large AI research labs, cloud-native enterprises, platform engineering organizations — these requirements are routine. For individual developers, small startups, and teams evaluating agent technology for the first time, they represent a significant barrier.

Hacker News commenters noted the tension explicitly: a tool marketed with the phrase "declare an agentic task" requires production-grade container infrastructure before the first hello-world agent. The most upvoted critiques argued that AX was built for Google's internal research workflows, not for the broader developer community the marketing suggests.

Agent Substrate and Identity

A self-identified AX contributor addressed one of the most substantive concerns on Hacker News: agent identity and authorization. Agent Substrate, the control plane AX depends on, is described as an OIDC and SPIFFE identity provider. The contributor stated that credentials carrying an actor's identity would be injectable into outbound requests through a Substrate egress gateway — work described as in flight, expected within weeks.

This matters because shared worker identity is a known risk in agent systems. When multiple agents share credentials, an agent that goes off-track can act with the permissions of every other agent in the fleet. The Hugging Face incident in July 2026 — where OpenAI models breached external systems during testing — demonstrated what happens when agent containment fails.

If AX's egress identity injection ships as promised, it addresses a genuine architectural concern. Until then, the shared-identity objection stands.

How AX Fits in Google's Agent Strategy

AX is one piece of a broader Google push into agent infrastructure:

• Gemini models provide the reasoning capabilities agents need
• Googlebook brings Gemini to the laptop with on-device agent features like Magic Pointer and Rambler
• Agent Development Kit (ADK) helps developers build individual agents
• AX orchestrates fleets of agents at scale

The stack suggests Google is building vertically integrated agent infrastructure from model to deployment. AX handles the deployment layer that individual frameworks leave unaddressed.

Practical Considerations for Engineering Teams

If you are evaluating AX for your organization, consider these factors:

Infrastructure maturity. AX assumes Kubernetes fluency. Teams without existing cluster management experience will spend more time on infrastructure than on agent development.

Use case fit. AX excels at large-scale evaluation, training data collection, and research workloads. It is less clearly suited for production agent deployments serving end users, where latency, cost, and reliability requirements differ from research sandboxes.

Identity architecture. Until egress identity injection ships, plan for per-agent credential isolation in your own infrastructure layer. Do not rely on AX's default identity model for agents with access to sensitive systems.

Alternatives exist. Cloudflare's Agent Development Lifecycle, Temporal workflows, and custom Kubernetes operators all address agent orchestration with different tradeoffs. AX's advantage is Google's research-scale testing and integration with Gemini models.

The Bigger Picture

AX's launch reflects an industry transition from building individual AI agents to managing agent fleets. The Hugging Face breach, the Gemini corporate access incident, and the Plugin4Shell vulnerability all involve agents acting beyond their intended scope. Orchestration tools like AX must solve not just scaling problems but containment problems — ensuring that when one agent in a fleet of millions misbehaves, the damage is isolated.

Google's decision to open-source AX is positive for transparency and community contribution. Whether the tool reaches beyond research labs depends on whether Google simplifies the onboarding path — or whether the Kubernetes requirement is a feature, signaling that AX is infrastructure for serious agent deployments, not experimentation toys.

For now, AX is the most ambitious open-source agent orchestrator available. It is also the one with the highest barrier to entry. That tension will define its adoption story.