Google AX: Inside the Open Agentic Orchestrator on Kubernetes

Google's AX spent September 21, 2026 sitting at #1 on Hacker News — 179 points, 74 comments, under the title "Google's Open Agentic Orchestrator." The repo, github.com/google/ax, describes itself in exactly those words, and it lives under the official google GitHub org rather than behind one of the "not officially supported" disclaimers Google attaches to genuine side projects. That distinction — official org, no disclaimer, Apache 2.0 license — is what several commenters cited as reason to take it more seriously than the usual unofficial Google GitHub drop.

AX is Google's answer to a question that's been building all year across agent harness engineering and multi-agent orchestration posts on this blog: once you're running agents that write code, call tools, and touch real infrastructure, what actually runs the agent — not the model, the runtime? AX's answer is Kubernetes, wrapped in a declarative control plane built on something Google calls Agent Substrate.

TL;DR — what people are asking

The four primitives: Task, Workspace, Gateway, Model

AX's pitch is that agent workloads are a genuinely new kind of compute — short-lived, bursty, frequently idle while waiting on a model or a human, and dangerous to run untrusted — and that existing infrastructure primitives (a VM, a container, a CI runner) weren't built for that shape. So AX defines four new ones.

Task is isolated execution: run untrusted agent code in a sandbox with CPU and memory limits, cheap enough to create, suspend, and destroy that you don't think twice about spinning one up per subtask.

Workspace lists the Git repos, MCP servers, and skills an agent needs — or, in what Google calls a "generative workspace," just describes a goal in plain English and lets the agent set up its own environment on first boot. The example Google ships: a workspace whose entire spec is "Set up a Python 3 development environment," with the agent inferring and installing the toolchain itself rather than a human hand-writing a Dockerfile.

Gateway is network policy — an explicit host/port allowlist for outbound traffic, plus credential injection into requests, so an agent can call the three APIs it needs and nothing else.

Model is one place to configure models, parameters, and secrets, so rotating an API key or pinning a model version is one apply across every task using it, not a fleet-wide find-and-replace.

Here's the shape of a real manifest — a Workspace plus Task that clones golang/go and gives the agent a plain-English goal:

apiVersion: ax.google.com/v1
kind: Workspace
metadata:
  name: go-toolchain-workspace
spec:
  repos:
    - url: https://github.com/golang/go
  goal: >
    Ensure that Go tool chain is available and is built from source.
---
apiVersion: ax.google.com/v1
kind: Task
metadata:
  name: go-toolchain-task
spec:
  workspaceRef: go-toolchain-workspace
  resources:
    cpu: "2"
    memory: "4Gi"

That YAML shape is deliberate — it reads like a Kubernetes manifest because it is one, submitted the same way you'd submit a Deployment or a Job, which is the whole point of building on Agent Substrate rather than a bespoke scheduler.

What "billions of concurrent tasks" and sub-second resumption actually mean

The runtime claims are the actual technical novelty here, not the YAML. AX says it scales to billions of concurrent agent tasks per cluster, because each task is a lightweight actor rather than a full VM or even a full container in the traditional sense — many tasks share worker resources through dense multiplexing instead of each reserving a dedicated slice.

The more interesting claim is sub-second resumption from suspend, with zero cold start. Most of an agent's wall-clock lifetime is spent idle — waiting on a model token stream, a tool call round-trip, or a human approval — and AX checkpoints that idle state so a suspended agent resumes in under a second rather than re-initializing from scratch.

Hacker News commenter prescriptivist offered the most credible explanation of the mechanism: Google already runs gVisor-based sandboxing in Kubernetes (GKE Sandbox) for exactly this kind of isolation, plus pod snapshot-and-rehydration at scale — spin up a pod, snapshot its memory and filesystem to a GCS blob, rehydrate that snapshot on a different node fast. If that's the underlying machinery, AX's sub-second resumption claim isn't a new invention so much as GKE's existing production capability, pointed at agent tasks instead of general workloads. That's a credible, if unverified, technical explanation worth taking more seriously than a bare marketing number — see also Google Cloud's own agent-sandbox honesty post, which argues cold-start marketing across the industry routinely understates real latency and that egress control matters more than hypervisor choice for actual agent risk.

Is this actually Google-backed, or another Gemini CLI?

This is the question the Hacker News thread spent the most energy on, and it deserves an honest answer rather than a marketing one.

The skeptical case, laid out by commenter Mond_: most of Google's leadership and Google DeepMind have probably never heard of AX, and the fact that it reads as "an effort in GCP" — not a Google DeepMind-backed initiative — is a historical red flag for longevity. The cited precedent is exact: Gemini CLI was effectively superseded by Antigravity CLI, a pattern this blog covered in detail when Gemini CLI's consumer authentication was deprecated on June 18, 2026 in favor of the Antigravity migration path. A tool built by one part of Google, without deep buy-in from the part that actually sets AI product direction, is exactly the kind of project Google has discontinued before.

The counter-case: Google's open-source infrastructure track record is genuinely strong where it counts — Kubernetes, Go, TensorFlow, gRPC, V8, JAX, and Protobuf are all Google-originated and all still alive, maintained, and widely deployed years or decades later. That's a different category from Google's shut-down-prone consumer products (the ones that fill killedbygoogle.com), and AX is infrastructure, not a consumer app. The repo's placement — directly under the official google org, described in its own README as "Google's open agentic orchestrator," with none of the hedging language Google attaches to genuinely unsupported side projects — reads as a stronger signal of institutional commitment than a typical Google GitHub drop.

Neither case is provably right yet. The honest read: AX inherits infrastructure Google has a decades-long habit of maintaining (Kubernetes-based systems), but ships from an organizational unit (GCP, not GDM) that has a much shorter track record specifically in agent tooling. Watch who owns the roadmap over the next two quarters, not the initial launch enthusiasm.

AX vs. Scion vs. kagent vs. OpenAI's Agents API

AX isn't the only Google project in this space, and it isn't the only orchestration answer on the market. Hacker News commenter verdverm pointed to Scion (googlecloudplatform.github.io/scion, github.com/googlecloudplatform/scion) as a more mature, more integrative alternative — one that wraps existing agent harnesses like OpenCode plugins rather than requiring teams to adopt the full Agent Substrate stack from scratch. The thread's shorthand for Scion: "closer to OpenClaw on Kubernetes" — a harness-compatible layer, versus AX's lower-level infrastructure primitives.

That last row matters for anyone evaluating build-vs-buy. OpenAI's Agents API went public beta on September 10, 2026 with nine hosted sandbox partners, native subagent concurrency, and MCP tool attachment — all as a managed call, billed at normal model and container rates, with zero Kubernetes to operate. AX asks you to run and manage a cluster; OpenAI's Agents API asks you to make an API call. Neither is strictly better — AX gives you infrastructure-level control (your own egress policy, your own model routing, your own multi-tenant isolation boundaries) that a managed API can't offer, at the cost of actually running that infrastructure yourself.

Two comparisons the Hacker News thread raised but never resolved: how AX stacks up against kagent.dev, a CNCF-style agent framework, and against OpenAI's Agents API specifically on cost and operational overhead at scale. Both are open questions worth revisiting once independent benchmarks exist.

The over-engineering pushback: do you actually need this?

Not everyone in the thread bought the premise that Kubernetes-scale agent infrastructure is necessary at all. Commenter DanMcInerney argued AX is over-engineered next to a much simpler "skills as universal workflow scaffolding" approach — his own project, orchflows, claims you only need two skills (work and review) to build arbitrarily complex workflows that are portable across harnesses like Claude Code, Codex, and Antigravity, without any of AX's infrastructure layer.

Commenter cobolcomesback pushed back on the framing rather than the claim: AX is a workspace/sandbox manager, not a workflow manager, so it's complementary to a skills-based approach rather than competing with it — you could run orchflows-style skill workflows inside AX-managed tasks. The same commenter added a data point from their own experience that cuts against pure agent-driven orchestration generally: it became hard to maintain and too token-wasteful compared to deterministic scripts, reinforcing the pattern this blog covers in multi-agent orchestration patterns — start with the simplest pattern that solves your problem, and add orchestration complexity only when you have evidence simpler systems can't meet your requirements.

A more practical strain of skepticism came from commenters running agents today in plain VMs, Proxmox, or tmux sessions, questioning whether heavyweight Kubernetes-based sandboxing is necessary outside enterprise scale versus just giving an agent bash access and a VM snapshot. Commenter maxgashkov offered the sharpest counter: what a DIY VM setup is usually missing isn't compute isolation — it's egress control and secrets management. Lock those down properly by hand and you cripple the agent's actual performance (it can't reach the package registries and APIs it needs), so you end up rebuilding local package mirrors and auth brokers piecemeal anyway. That "whack-a-mole" is exactly the gap dedicated infrastructure like AX — or, per Google's own honesty about the tradeoffs, GKE Agent Sandbox and the isolation-spectrum thinking behind it — is meant to close once, centrally, instead of per-project.

One naming gotcha: there are two unrelated "ax" projects

If you search for "ax" alongside AI, you'll also find axllm.dev, a DSPy-style prompt framework for TypeScript and other languages that predates Google's AX and has nothing to do with it. The overlap is name only — different maintainers, different scope, different repo. When bookmarking or searching, use the full repo path (github.com/google/ax) or the project's landing page (agentexecutor.io) rather than the bare word "ax" to avoid pulling up the wrong tool.

What to check before adopting AX

1. Confirm your scale actually needs it. If you're running a handful of agents per day, a VM with tight egress rules covers most of what AX solves — see the DIY-vs-infrastructure debate above.
2. Read the Task/Workspace/Gateway/Model docs against your existing agent harness choice. AX is infrastructure underneath a harness, not a replacement for Claude Code, Codex, or Antigravity as your agent loop.
3. Evaluate Scion in parallel if you want harness compatibility (OpenCode-style plugins) without committing to the full Agent Substrate stack.
4. Watch the maintainer signal over the next two quarters, not the launch-week star count — that's the actual test of the Gemini CLI precedent versus the Kubernetes-track-record counter-argument.
5. Wire your Gateway allowlist and Model secrets rotation before your first production Task — the primitives exist specifically because ad hoc egress rules and hand-managed API keys are where agent infrastructure quietly breaks.

Related reading

• Google Cloud's 5 Agent Sandbox Truths: Cold Start, Isolation, Egress
• OpenAI Agents API Public Beta: Codex Harness Behind One Call
• Google Gemini CLI Deprecation: Antigravity Migration Guide
• What Is an Agent Harness? The Scaffolding Layer That Makes AI Agents Reliable
• Agent Harness Engineering: Terminal-Bench and LangChain Lessons
• Multi-Agent Orchestration Patterns: A Complete Guide
• Antigravity CLI Features: Sandbox, Plugins, Subagents

Official sources: google/ax on GitHub, agentexecutor.io, and the Hacker News discussion thread ("Google's Open Agentic Orchestrator," 179 points, 74 comments, September 2026).

Details on AX's primitives, runtime claims, and the Hacker News discussion reflect the repository and thread as of September 21, 2026 — an early-stage open-source project like this can change its API shape, scaling claims, or maintenance status without notice. Verify against the live repo before building production infrastructure on it.