Google Open-Sources AX: The Kubernetes for AI Agents

When AI Agents Need Their Own Kubernetes

Google has released a runtime system built specifically for AI agents called AX (Agent Executor). Its positioning can be summed up in a single sentence: if Kubernetes was built for web services, AX was built for agents.

Developers declare an agent task in YAML, and a runtime designed for "billion-scale concurrent sessions" handles execution — including crash recovery. According to Prism Labs' analysis, AX can restore a "dead" agent from a kernel snapshot in under one second. The project is open-sourced under the Apache 2.0 license, with v0.3.0 already released.

This system has serious pedigree. AX draws from Google DeepMind research and Google's production experience with planet-scale isolation and scheduling. It was released by Jana Dogan (Yana Dogan), a widely respected infrastructure engineer, accompanied by an official Google Cloud launch post. The repository lives at google/ax, written entirely in Go, and has already accumulated over 3,200 stars with only 7 open issues — a number that signals a small, focused, actively maintained codebase rather than a feature-dumping ground.

Four Declarative Primitives: Zero Learning Curve for K8s Users

The entire system can be distilled into four declarative primitives. If you know Kubernetes, you can understand how this works almost intuitively.

• Task: The execution unit — sandboxed agent code with CPU and memory limits.
• Workspace: Pre-wired dependencies — Git repos, MCP servers, skill packages — already "warmed up" before the agent starts.
• Gateway: Network control with explicit egress allow lists and credential injection.
• Model: Centralized LLM configuration, parameters, and secrets — so 50 tasks don't each have to carry 50 separate API keys.

Declare these four in YAML, apply them, and the runtime reconciles reality toward your declared state — exactly the mental model that made Kubernetes so widely adopted.

The CLI also "speaks fluent kubectl." ax apply submits a task manifest and launches it, ax get tasks lists everything running, and ax watch streams progress in real time. The most interesting command is ax ssh: it drops you directly into a running sandbox for interactive debugging. When an agent does something strange at step 400, you can go in and look. Suspend and resume are available at any time. For teams already living in kubectl, the learning curve is essentially zero — same verbs, same YAML reflection, just new nouns.

The Capabilities That Justify a Dedicated Runtime

These are the features that make AX worth existing as a standalone runtime:

• Persistent execution: Implemented via event logs and snapshots.
• Sub-second recovery: Checkpointed actors resume with no cold start.
• Connection recovery: Clients that disconnect mid-session can reconnect and receive all responses they missed, starting from their last seen sequence number.
• Trajectory Branching: Fork an agent from a kernel snapshot to explore an alternative path without losing the original state.
• Generative configuration: Describe a workspace in natural language; AX completes the configuration automatically on first launch.

You could piece together each of these features individually. AX's value proposition is getting all of them from a single runtime, rather than maintaining five custom systems that each fail in different ways at 3 a.m.

Jana Dogan's launch framing is the cleanest summary of that ambition: a general-purpose runtime that handles dynamic scheduling, recovery, auto-repair, auditing, and trajectory branching from kernel snapshots. Notice what's on that list — these are the unglamorous but brutal reliability problems that actually kill agent products in production, not yet another prompt framework. This is Google's bet: while others compete on the harness (orchestration shell), Google is competing on the layer beneath it.

Trajectory Branching deserves its own explanation. In reinforcement learning and agent research, a "trajectory" refers to the complete sequence of states and actions an agent traverses from start to finish. With traditional debugging, if you want to test "what happens if a different decision is made at step 300," you have to rerun from the beginning — extremely costly. AX's trajectory branching borrows the concept of fork() from operating systems: it performs a copy-on-write on a kernel snapshot at any checkpoint, spawning a completely independent agent instance to explore an alternative path while the original continues running, with neither affecting the other. This capability is particularly valuable for agent evaluations (evals) — you can compare the outcomes of multiple strategies in the same "live" environment simultaneously, without maintaining separate replay infrastructure for each.

Agent Substrate: Those "Outrageous" Numbers

Below AX sits the most audacious part — Agent Substrate, a new abstraction layer built on top of Kubernetes. Google claims it is designed for "hundreds of millions of registered agents, millions of sub-second tool calls per second, and billions of concurrent sessions per cluster."

The trick is replacing heavyweight pods with lightweight actors. Since agents spend most of their time idle — waiting on model responses or human input — dense multiplexing can pack vast numbers of sessions into an ordinary cluster. The control plane itself runs in Kubernetes, driving the substrate through a control API.

Are these numbers "marketing-grade"? Honestly, no one outside Google has verified any metrics at the "billions" level, and the documentation openly acknowledges this is experimental. But the architectural argument holds, and it comes from a team that ran this problem at internal production scale first.

Why not just run agents on bare Kubernetes? Because agents are not web services. Pods assume long-lived processes that continuously handle requests; agents are bursty, mostly idle, and die mid-thought. Kubernetes restarts quickly, but what restarts is a cold pod; AX restores a checkpointed actor with full context intact. K8s network policies are general-purpose; the AX Gateway is "agent-aware" — per-task egress allowlists with credential injection. When the orchestrator's ceiling is thousands of pods per node, Substrate claims billions of sessions per cluster through dense multiplexing.

The Actor Model is the key to understanding Agent Substrate's density advantage. Unlike traditional thread or process models, the Actor model abstracts each concurrent unit as a lightweight "actor": it has private state, communicates with the outside world via message passing, and consumes no thread resources while idle. Erlang/OTP and Akka are classic implementations of this model — a single node can comfortably maintain millions of concurrent actors. AI agent workloads are a natural fit: the vast majority of the time, agents are waiting for LLM inference to return or for human approval, with actual CPU usage being extremely brief. Kubernetes Pod scheduling operates at the "process" granularity — an idle pod still occupies memory and an IP address. An Actor-based Substrate can compress billions of "waiting" sessions into a small number of actually running processes. That's the architectural logic behind those staggering numbers.

Crash as Recovery: The Secret Behind the Axolotl Name

Every agent developer knows the failure story: a migration agent crashes after running for hours. Usually that means restarting from zero, with an entire afternoon lost. With checkpointed actors, the runtime resumes from the last snapshot and the client reconnects as if nothing happened.

Human-in-the-loop pauses work the same way: the agent suspends, waits for approval — minutes or a week — then resumes instantly, consuming zero compute during the wait. That last point directly affects billing: a suspended agent costs nothing, which is what makes patterns like "overnight approval queues" economically viable.

This also explains why the entire project is named after the axolotl (the "six-legged dragon" salamander). This amphibian can regenerate lost limbs; an agent runtime that "regenerates" from a snapshot rather than dying is the entire design philosophy wearing a mascot costume.

Open, Not Walled: One go install Away

The data since launch reveals a "deliberately steady" team: the repository was created in late March, v0.1.0 shipped May 20 alongside the Google Cloud announcement, v0.2.0 in July added workspace permissions and session ID protection, August brought dependency fixes, and today's v0.3.0 locks down workflow action permissions — supply chain hardening isn't glamorous, but it's exactly what you do when preparing for enterprise production: lock the doors before inviting the auditors in.

3,000+ developer stars in four months, 123 days from first public commit to v0.3.0, six releases along the way, 152 forks — for an experimental preview that Google itself describes as actively being refined, that's real momentum.

AX is also not a walled garden. It federates Google's own stack (Antigravity, Deep Research, managed agents on the Gemini API) while remaining compatible with LangChain, LangGraph, ADK, and the A2A protocol. Bring your own harness, run your own data plane, no lock-in. That openness is of course strategic — if everyone's agent substrate runs on Google infrastructure, Google wins. But strategic generosity is still generosity, and Apache 2.0 means it belongs to you regardless.

The A2A Protocol (Agent-to-Agent Protocol) mentioned above is an open standard Google introduced this year, defining how different agents discover each other, negotiate capabilities, delegate subtasks, and return results — roughly "HTTP for the agent world." MCP (Model Context Protocol) is another standard led by Anthropic, solving the interface problem between agents and external tools and data sources — think "USB-C for the agent world." AX is compatible with both protocols simultaneously, meaning it aims to be a protocol-agnostic execution layer: regardless of which communication standard the upper-layer agent framework (LangChain, ADK, etc.) uses, the underlying runtime can handle it. This compatibility strategy is the concrete expression of Google's "win the substrate layer" approach.