Google AX agent orchestrator: run AI agents that wait

Google AX is an agent orchestrator built on one observation: an AI agent spends most of its life waiting. The Google AX agent orchestrator, covered by InfoQ on 22 September, is an Apache 2.0 runtime that treats each agent as a stateful actor, checkpoints it when idle and, per the project, brings it back in under a second. Read on for what AX actually is, what it asks of your platform team, and whether you should run it yet.

The short answer on that last point: the repository itself says it is not stable. That matters more than any feature on the list.

What is Google AX?

AX is an open-source, Apache 2.0-licensed orchestrator and declarative runtime for autonomous agent workloads, hosted at agentexecutor.io and on GitHub as google/ax. It runs on top of Agent Substrate, a separate open-source runtime Google announced alongside it, which multiplexes many idle "actors" onto fewer ready workers. Google introduced AX as Agent Executor in a Google Cloud blog post on 21 May 2026, where it was described as "available now in preview". The September attention is the open-source project and its documentation catching up.

Item	What the sources say
Licence	Apache 2.0
Runtime underneath	Agent Substrate, built on Kubernetes
Primitives	Task, Workspace, Gateway, Model (ax.io/v1alpha1)
Interface	ax CLI, written in Go, kubectl-shaped
Install needs	A Kubernetes cluster, ko, a container registry, a reachable Agent Substrate Control API
Stability	Major breaking changes likely before a stable release

Why agents do not fit the microservice or batch model

The AX README puts it plainly: agents "are neither stateless microservices nor run-to-completion batch jobs". A microservice handles short request-response lifecycles. A batch job runs to completion. An agent, as InfoQ summarises, is stateful, bursty and long-running: intense compute while reasoning or running code, then long idle stretches waiting on a model, an API or a human.

That profile is awkward on conventional Kubernetes. Keep a dedicated sandbox alive through the idle stretches and you pay for compute that does nothing. Tear it down and you take a cold start the next time the agent needs to act, which hurts interactive loops. The project site calls traditional orchestrators "cost-prohibitive when keeping idle sandboxes running".

How the Google AX agent orchestrator works: four primitives

AX exposes four declarative, Kubernetes-style resources. What each does, from the README and site:

Primitive	Purpose
Task	Runs untrusted agent code in an isolated sandbox with CPU and memory limits
Workspace	Pre-wires Git repos, MCP servers and skill packages, or takes a plain-English goal an agent uses to set up the environment
Gateway	Locks outbound traffic to an explicit allowlist of hosts and ports, and injects credentials
Model	Configures models, parameters and secrets in one place, with credentials from a Kubernetes secret

One detail worth reading closely: the README describes the Model primitive as configuring "which LLM the platform itself uses". Coverage that calls it a unified control point for your agents' LLM providers is broader than the repository's own wording. Check it against your use case before assuming it replaces your model gateway.

Day-to-day use is ax apply, ax watch, ax ssh into a debug-enabled sandbox, and ax suspend and ax resume, which the README says checkpoint actor state and "pick up exactly where it left off".

Agent Substrate and the sub-second resume claim

The speed comes from Agent Substrate. Its README claims sub-500ms resume at over 500 suspend/resume activations per second, support for microVMs and gVisor sandboxes, and a demo of about 250 stateful actors multiplexed onto 8 pods. These are the project's own figures. We have not benchmarked them, and nobody should size a cluster on a README.

Where the coverage and the repository disagree

InfoQ writes that the project is positioned for production agent deployment as well as research. The repositories are more cautious. The AX README opens with a warning that the team is "still actively refining" core concepts and will "likely introduce major breaking changes prior to a stable release". The Agent Substrate README goes further: "It is not ready for production use, and the APIs are almost guaranteed to change."

That is the fact a CTO needs. AX is a well-reasoned design for a real cost problem, published early so people can test it. It is not yet something to put under a customer-facing product with an SLA.

InfoQ also reports community reaction split along predictable lines: infrastructure engineers welcoming a fix for idle-agent cost, and developers pointing out the operational weight of Kubernetes clusters, registries and custom resources. The same summary notes early reports of egress proxy dropped connections and basic secrets management, and that AX is an execution runtime, not a high-level framework like LangGraph or CrewAI.

How do you run AI agents on Kubernetes today?

Without AX, the two common patterns we see are a long-lived pod per agent session, which is simple and wasteful when sessions idle, or a job per step with state pushed to external storage, which is cheaper but slower to resume. Both work. What they share is that your code, not the platform, owns the question of what persists between turns.

AX moves that into the runtime: Agent Substrate says it preserves working memory and filesystem state across hibernation, so the agent resumes rather than restarts. If you have ever debugged an agent that lost context between steps, that is the appeal. It does not remove the need to think about AI agent state between turns; it changes where the state lives.

Should I self-host an agent runtime?

AX is worth a proof of concept if all of these are true:

• You already run Kubernetes with a team that owns it.
• You run many long-lived, sandboxed agents, and idle compute shows up on the bill.
• You need data and execution on your own infrastructure, which is the case Google's own announcement makes for self-managed compute.
• You do research-style work: trajectories, reinforcement learning loops or agent evaluations at scale, which the site names directly.

It is the wrong choice if you run a handful of agents, have no platform team, or need stability guarantees this quarter. A managed agent service, or a simpler container-per-session setup, will cost less in engineering time than operating a preview control plane. We covered that trade-off for OpenAI's hosted option in buy the harness, or keep yours.

Whichever way you go, the Gateway primitive is a good pattern to copy now: outbound traffic locked to an explicit allowlist, with credentials injected at the edge rather than handed to the agent. It is the same principle behind AI agent sandbox security starting with the allowlist.

In the agent systems we build, the practical next step is modest: put AX on a non-production cluster, run one representative long-running agent through suspend and resume, and measure idle cost against your current setup. Our Kubernetes implementation and AI engineering teams can help scope that test. Decide on production after the project ships a stable API, not before.