A Kubernetes runtime built for agents, not services
Google open-sourced AX this week, describing it in the project's own README as "a high-throughput, declarative orchestrator to run billions of autonomous agent workloads in a cluster." It sits on top of Google's "Agent Substrate," a sandboxed execution layer, and it hit the top of Hacker News fast: the submission "AX – Google's Open Agentic Orchestrator" reached 619 points and 283 comments within its first 20 hours, the top AI story on the site that day.
The reason it matters is not the code, which is pre-1.0 and openly unstable. It is the argument the project makes by existing: agent workloads do not fit the shape that Kubernetes and most orchestrators were built for. A microservice handles requests continuously. A batch job runs to completion and exits. An agent does neither — it can sit idle for minutes waiting on a human or an external system, then burst into heavy compute, then idle again, all while holding state that has to survive the gaps. AX's own site frames this directly, arguing that traditional orchestration systems built for stateless microservices or batch jobs aren't suited to agents that alternate between computation and long idle waits, and claims sub-second resumption of a suspended agent with no cold-start penalty.
Whether or not you ever run AX, that framing is useful. It gives a vocabulary for a problem a lot of teams are currently solving with duct tape: keep-alive containers, ad hoc state dumps to a database, cron jobs that poll for "has the agent finished yet." AX's answer is to make suspend-and-resume a first-class primitive instead of something you bolt on.
The four primitives, and what each one replaces
AX exposes four core objects, and they're the part worth studying independent of the runtime itself, per the project's README:
Task is isolated, suspendable execution of untrusted agent code. This is the direct answer to the idle/burst problem above — a Task can be paused mid-run and resumed later without re-paying startup cost. Today, most teams approximate this with a long-running worker process that blocks on a queue, or a serverless function that re-initializes from scratch on every invocation. Neither actually suspends state the way a Task claims to.
Workspace declares the Git repos, MCP servers, and skills an agent needs to do its job. This is essentially a manifest for an agent's environment, the same idea as a devcontainer.json or a Kubernetes ConfigMap, but scoped to what an autonomous coding or ops agent specifically touches — its tools, not just its runtime image.
Gateway enforces explicit network allowlists and credential injection. This is arguably the most important primitive for anyone running agents against real infrastructure: an agent with unrestricted outbound network access and ambient credentials is a standing security incident waiting to happen. A Gateway is the place you'd otherwise hand-build with an egress proxy and a secrets manager, and having it as a declared object rather than tribal infrastructure knowledge is a real improvement.
Model centralizes LLM provider and credential configuration, so an agent's code doesn't hardcode which model or which API key it's calling. This is the least novel of the four — plenty of internal platforms already do this — but bundling it with the other three means one manifest describes an agent's entire operating envelope: what it runs as, what it can reach, what it's allowed to call, and what it talks to for inference.
Taken together, the four primitives are a reference design for "agent-native infrastructure": isolation and suspendability (Task), declared dependencies (Workspace), network and credential boundaries (Gateway), and inference configuration (Model). A team building this by hand today is usually solving each of these separately, with different tools and different levels of rigor, and Gateway in particular is the one most likely to be skipped under deadline pressure.
What actually stands between you and running it
Running AX is not a lightweight decision. Per the README, the requirements are a Kubernetes cluster, the ko build tool, a container registry, a reachable Agent Substrate Control API, and Redis deployed as part of the control plane. That's a full infrastructure commitment before an agent has done any useful work, and it's precisely what drove the sharpest criticism in the Hacker News thread: commenters pointed out the gap between AX's marketing and the actual setup complexity, noting that the quickstart alone demands several pieces of infrastructure beyond Kubernetes itself.
The project is also explicit about its own immaturity. The repository carries a warning that the team is "still actively refining our core concepts, protocols, and specifications" and will "likely introduce major breaking changes prior to a stable release." The first public release, v0.1.0, shipped May 20, 2026, with maintainers stating plainly that they were "releasing this early stage to be able to have some concrete conversations" — this is a discussion draft, not a product.
That candor didn't stop HN from raising Google's track record on developer tools, citing the Gemini CLI-to-Antigravity CLI transition as a precedent for tools that get abandoned or replaced. Independent coverage confirmed AX is Apache 2.0 licensed and positioned as Google's infrastructure response to the shift from chatbots to autonomous agent systems, but also flagged that it comes with no backward-compatibility guarantee. For a team evaluating whether to build on it, that's the real risk: not whether the ideas are sound, but whether the API you integrate against today still exists in a year.
What to do with this if you're not ready to deploy it
If you're already running Kubernetes and experimenting with coding or ops agents, don't start by trying to stand up AX's full stack. Start by auditing your current setup against its four primitives instead. Ask specifically: do our agents have an explicit network allowlist and scoped credentials, or do they inherit whatever the host container can reach? That's the Gateway question, and it's the one most worth answering regardless of what orchestrator you use. Ask whether an agent's dependencies — repos, MCP servers, tool access — are declared anywhere a teammate could read them, or whether they're implicit in a Dockerfile someone wrote six months ago. That's the Workspace question.
If the answers are uncomfortable, you don't need AX to fix them — a well-scoped egress proxy and a manifest file get you most of the Gateway and Workspace benefit without a Kubernetes-plus-Redis-plus-Agent-Substrate stack. Treat AX itself as a signal of where agent infrastructure is heading and a naming exercise for problems you already have, not as a dependency to adopt this quarter. Revisit it once it clears 1.0 and the breaking-changes warning comes off the README — by then you'll know whether Google is still maintaining it, which is exactly the question the HN thread couldn't answer today.
Comments (0)
No comments yet. Start the conversation.