Google Open-Sourced an Agent Orchestrator That Looks Like Kubernetes. The Design Choice Is the Most Honest Thing They Could Have Done.

Google Just Open-Sourced an Agent Orchestrator That Looks Like Kubernetes. That Is Intentional and It Is the Most Honest Thing They Could Have Done.

Last week Google published AX, an open-source declarative orchestrator for running autonomous agent workloads at scale. The project comes from Google DeepMind and carries four years of internal experience building agentic execution engines. It hit Hacker News with 565 points in a single afternoon, which is a reliable signal that people recognize a genuine engineering artifact when they see one rather than another marketing announcement wrapped in YAML.

I spent the weekend reading the design documents, poking through the Go source code, and comparing it against the two frameworks I have actually used in production — LangGraph for multi-step chains and Temporal for durable execution. The verdict is more nuanced than the Reddit takes suggest. AX solves a real problem, but the problem it solves best is not the one most people think they have. Understanding the difference will save you from a painful infrastructure detour.

What AX Actually Is, Past the Marketing Copy

The elevator pitch is “Kubernetes for agents.” That framing is accurate in a very specific sense and misleading in a broader one. AX is Kubernetes-adjacent: it requires a running Kubernetes cluster, it uses kubectl-shaped CLI verbs (ax apply, ax get, ax describe), and it expresses everything as YAML manifests with apiVersion: ax.io/v1alpha1. If you have operated Kubernetes, the mental model transfers immediately.

But AX is not a Kubernetes controller that wraps pods. It is an orchestration layer on top of something called Agent Substrate — a compute runtime that Google also developed internally, designed from the ground up for stateful, bursty, long-running actor lifecycles. The distinction matters because the performance claims in the documentation are about Agent Substrate’s actor model, not about Kubernetes itself. When they say “sub-second resumption” and “billions of concurrent agent sessions per cluster,” that is the runtime talking, not the orchestrator. AX is the control plane; Agent Substrate is the execution plane. You need both.

The four primitives AX exposes are:

• Task: An isolated execution unit with CPU/memory limits, running in a sandbox.
• Workspace: A declaration of what an agent needs before it starts — Git repos, MCP servers, skill packages, toolchains. AX provisions all of this before the task begins, so the agent starts warm instead of spending its first actions installing dependencies.
• Gateway: Network policy expressed as an explicit allowlist of outbound hosts and ports. If a task tries to reach a host not on the list, the request fails at the network layer, not at the application layer.
• Model: A single place to configure which LLM the platform uses, with credentials pulled from Kubernetes secrets. Rotate a key or change a model version with one ax apply.

The design philosophy is unmistakably infrastructure-flavored. There is no concept of “chains” or “tools” or “agents” in the LangChain sense. AX does not know or care what the agent inside the sandbox is doing. It knows how to start it, isolate it, give it network access to exactly the hosts it declared it needed, checkpoint it when it is idle, and resume it quickly when there is work to do.

The Infrastructure Problem That Everyone Is Ignoring

Most agent frameworks, including LangGraph, AutoGen, and LlamaIndex, solve a code organization problem: how do you structure the routing logic between LLM calls, how do you manage conversation state, how do you compose multiple agents into a pipeline. These are real problems. They are also problems you can solve in application code without a dedicated orchestration layer.

What most frameworks do not solve well is the infrastructure problem that emerges when you try to run agents at anything resembling scale in a real production environment.

I learned this the hard way building a pipeline of research agents — about 200 concurrent sessions at peak, each session potentially lasting 15 to 40 minutes, involving multiple LLM calls and web scraping. The code structure was fine. The production behavior was not.

The specific failure modes we hit, which I suspect are universal:

• An agent would hit a rate limit on the model API at minute 12 of a 15-minute session. The session would die. We had no checkpointing, so the work was lost and the session restarted from scratch, hitting the rate limit again.
• One agent in a batch had a bug that caused it to call an external API in a tight loop. By the time we noticed, it had made 40,000 requests to a third-party service in 90 seconds. The service banned our IP address and sent us an invoice.
• Cold starts dominated our latency numbers. Each new agent session needed to clone a Git repo, install Python dependencies, and authenticate against several services before it could do any actual work.
• We had no visibility into what any specific agent was doing at any given moment. Logging helped but we could not inspect the running state of a specific session interactively.

AX addresses all four of these directly. Checkpointing and resumption via ax suspend and ax resume. Network gateway policies that enforce outbound allowlists at the infrastructure level, not the application level. Warm workspaces that front-load provisioning before the task starts. And ax ssh task123 to shell into a running agent sandbox and see what it is actually doing.

That last capability — interactive shell access into a running agent — is quietly one of the most significant debugging affordances in any agent framework I have seen. Every other system I have used treats the agent as a black box you can observe through logs. AX lets you look inside.

The Kubernetes Tax and Who Pays It

The prerequisite list for running AX is not short. You need a Kubernetes cluster. You need the ko build tool. You need a container registry your cluster can pull from. You need a running instance of Agent Substrate, which is a separate open-source project with its own deployment requirements. Then you deploy AX on top of all of that.

For a team that already operates Kubernetes and already has the supporting infrastructure — a realistic description of any reasonably large engineering organization — this is probably not prohibitive. But for an individual developer or a startup running agents as a side feature of a larger product, this is a lot of complexity to take on. The “quick start” in the README is genuinely quick if you already have the prerequisites. Getting the prerequisites is the hard part, and the documentation acknowledges this without quite solving it.

There is a meaningful comparison to be made with Temporal here. Temporal is a durable workflow engine that has developed significant support for long-running, stateful, resumable workloads. It does not require Kubernetes (though it runs there). It has a genuinely good developer experience for individual engineers and small teams. Several teams I know have used Temporal successfully for agent orchestration without any of the AX infrastructure stack.

The trade-off is density and scale. Temporal’s model is fine for hundreds or low thousands of concurrent workflows. The AX and Agent Substrate claims about billions of concurrent sessions per cluster are oriented at a different population: large-scale reinforcement learning research, code generation at enterprise scale, organizations running many thousands of simultaneous autonomous agents. If that is your use case, the infrastructure investment probably makes sense. If your peak load is 500 concurrent agent sessions, you are probably paying a tax that does not buy you much.

The MCP Integration Is the Quietly Interesting Part

The Workspace primitive lists MCP servers as a first-class dependency alongside Git repos and skill packages. When you declare a workspace, you list the MCP servers your agent needs access to, and AX provisions those connections before the task starts. The agent does not need to discover or authenticate against MCP servers at runtime — they are already available when the sandbox boots.

This is a design decision with real implications. It means the set of tools an agent has access to is determined at declaration time, not at execution time. The agent cannot dynamically discover and connect to new MCP servers mid-session. Whether that is a constraint or a feature depends on your use case, but it is consistent with the general AX philosophy of treating isolation and predictability as first-class properties. An agent that can only reach the MCP servers it declared it needed is an agent that cannot exfiltrate data through an unexpected tool connection it found at runtime.

Given the recent pattern of agent security incidents — the ZCode upload scandal in September, the OpenAI agent write channel vulnerability earlier this month — treating the tool surface as a fixed declaration rather than a dynamic discovery is a defensible security posture. It shifts the trust boundary from the agent’s runtime behavior to the workspace specification, where it can be reviewed by humans before the task runs.

What “Born at Google” Actually Means for Open Source Longevity

The README says AX “was born at Google when agentic runtime systems research met frontier compute.” The project is at v0.3.0, Apache 2.0 licensed, with 11 contributors and 4.7k stars on GitHub as of this week. The warning at the top of the README is admirably honest: “We are still actively refining our core concepts, protocols, and specifications. We will likely introduce major breaking changes prior to a stable release.”

Google’s open source track record is complicated. Google Kubernetes Engine became the industry standard. Google Wave did not. TensorFlow dominated ML infrastructure for several years and then largely lost the development mindshare battle to PyTorch. Google’s pattern is not “open sources everything and maintains it forever” — it is more like “open sources things that are structurally tied to Google’s own production requirements, which creates a maintenance incentive that does not exist for other projects.”

The question for AX is whether it falls into the GKE category or the Wave category. The answer depends on whether Google’s internal agentic infrastructure teams continue to use it. If AX is genuinely the foundation of how Google runs agentic workloads at scale internally, it will be maintained with the level of attention that internal necessity demands. If it is a research project that was open-sourced for visibility reasons but is not on the critical path of any Google product line, the maintenance trajectory will look different.

I do not know which of those is true. Neither does anyone outside Google. The honest position is to treat AX as interesting, technically credible, and architecturally sound while keeping a cautious eye on the production commit velocity over the next six to twelve months. Projects that have Google’s production environments behind them look different from projects that do not. The commit history will tell you which this is.

The Benchmark Claim Deserves Scrutiny

The headline claim — “billions of concurrent tasks per cluster” — appears in the marketing copy for Agent Substrate rather than AX directly, but the AX documentation inherits it by reference. I want to be precise about what this claim probably means and what it does not mean.

In actor model systems, “concurrent” often means “actors that are instantiated and potentially resumed, but most of which are idle at any given moment.” A billion concurrent HTTP connections would be extraordinary. A billion concurrent actor instances where 99.999% are checkpointed and idle, consuming minimal memory because their state has been serialized and the execution context has been reclaimed, is a very different claim. It is still impressive if true — maintaining the routing table and scheduling metadata for a billion actor handles is a non-trivial systems problem — but it is not the same as saying a billion agents are actively executing code simultaneously.

The “sub-second resumption” claim is the one I find more concretely verifiable and interesting. Taking a suspended agent — which means serializing its execution state, writing it to durable storage, reclaiming the sandbox — and resuming it into an active running state in under a second is a meaningful performance target. If Agent Substrate actually delivers this at the density they claim, it resolves the biggest latency problem with checkpointing: that the resume latency becomes part of the user-perceived response time for interactive agent applications.

I have not benchmarked this myself and I am skeptical of benchmark claims I cannot reproduce. What I can say is that the design architecture — lightweight actors with fast state serialization, worker-side multiplexing so idle actors do not hold dedicated compute — is consistent with achieving this kind of performance. The design is not implausible. Whether the implementation delivers what the design promises is a different question.

Who Should Actually Look at AX Right Now

Three categories of people should spend real time on AX today:

Infrastructure engineers at large organizations who are already running Kubernetes and are starting to encounter the production failure modes I described above — runaway API costs, session losses from failures mid-execution, inability to inspect running agents, no network controls. AX is solving the right problems for this population and the Kubernetes prerequisite is not a blocker because they already have it.

ML researchers doing large-scale evaluation, trajectory collection for RL training, or benchmark runs that need to run thousands to tens of thousands of agent episodes in parallel with reproducible environments. The warm workspace model is particularly valuable here — every episode starts from an identical, pre-provisioned state — and the debugging capabilities reduce the investigation time when specific episodes produce unexpected results.

Security engineers who need to run agents with hard network isolation guarantees. The Gateway primitive is not a best-effort policy expressed in application code that an agent could bypass by calling a different HTTP library. It is enforced at the network layer. For organizations running agents against customer data or on infrastructure where data exfiltration is a material risk, this is a meaningfully different security posture than anything the application-layer frameworks offer.

People who should probably wait:

Small teams and individual developers building agent-powered products where Kubernetes is not already part of the stack. The infrastructure overhead is real and the benefits do not justify it at low concurrency. LangGraph with Temporal for durability is probably a better fit until you hit scale problems that demand the AX approach.

Teams with significant existing investment in LangGraph or AutoGen codebases. AX is not a replacement for the application-layer frameworks — it is an execution substrate that can run whatever is inside the sandbox, including a LangGraph agent. But migrating to AX does not replace your LangGraph code; it adds an infrastructure layer underneath it. Make sure you are solving an infrastructure problem, not an application-layer one, before you start.

The Deeper Pattern: Infrastructure Is Eating the Agent Stack

Stepping back from AX specifically, I think the broader signal is that the agent framework space is bifurcating in a way that was predictable but is now becoming visible. The application-layer frameworks — LangGraph, AutoGen, LlamaIndex — are increasingly converging toward similar primitives for routing, memory, and tool use. The differentiation at that layer is narrowing.

The execution infrastructure layer is where meaningful differentiation is re-emerging. How do you run agents at scale? How do you checkpoint and resume efficiently? How do you enforce isolation and network policies? How do you provision agent environments reproducibly? These are infrastructure problems and they require infrastructure answers. AX is Google’s answer. Several other startups are building in the same space.

The teams that will have a competitive advantage in twelve months are not the ones with the cleverest prompt engineering or the best agent routing logic. Those advantages are narrow and temporary. The teams with durable advantages will be the ones that figured out how to run agents reliably in production at cost — which means solving the infrastructure layer problems that AX is addressing.

That is the part of the AX announcement that I think is being underweighted in the coverage I have seen. The question is not “is AX a good framework.” The question is what it tells us that Google is open-sourcing its internal agent execution infrastructure. The answer is that the application layer is no longer where the hard problems live. The infrastructure layer is. And Google just told you what they think those problems are.

Falsifiable Predictions

In twelve months, either Agent Substrate or AX will have a hosted deployment path that removes the Kubernetes prerequisite — likely a managed service running on GKE or a one-command local mode comparable to Temporal’s dev server. Without this, adoption will remain confined to organizations that already operate Kubernetes, which is large but not the majority of agent-building teams.

LangGraph will ship native support for deploying agents into AX-compatible execution environments. The primitives are complementary — LangGraph owns the application layer, AX owns the execution substrate — and the integration is not architecturally complex. If this does not happen through official channels, community-built integrations will emerge first.

The “billions of concurrent tasks” claim will be either demonstrated publicly with a reproducible benchmark or quietly dropped from the marketing copy within six months. Claims of that magnitude that are not backed by public benchmarks have a short half-life in the engineering community.

At least two large public incidents involving agent security failures — network exfiltration, runaway costs, or data leakage — will be traced back to organizations using application-layer frameworks with no infrastructure-level isolation. These incidents will accelerate adoption of execution substrates like AX among security-conscious organizations faster than any amount of Google marketing would.

The Actor Model Is Not New. The Application to Agents Is.

One thing that gets lost in the coverage of AX is that the underlying computational model — actors as the unit of concurrency, with message-passing, state serialization, and cheap creation and destruction — is fifty years old. Carl Hewitt described the Actor model in 1973. Erlang/OTP built an entire production ecosystem around it in the 1980s and 1990s. Akka brought it to the JVM. Microsoft Orleans formalized it as “virtual actors” or grains on .NET. The actor model is a known, well-understood computational abstraction with decades of production usage.

What AX and Agent Substrate are doing is applying that abstraction to a new workload class where the “actor” is not a small, fast-responding service process but a potentially long-running, expensive-to-execute, model-API-dependent agent. The properties that make actors attractive for service architectures — isolation, cheap creation, location transparency, fault recovery through supervisor trees — turn out to map well onto the properties you want from an agent execution substrate. But the scale of the individual actor changes things substantially.

A typical Erlang actor is measured in kilobytes of heap and microseconds of computation between messages. A typical agent “actor” in the AX sense involves gigabytes of context in the model, multiple external API calls per execution step, and minutes to hours of execution time per task. Applying actor model semantics to this workload class requires rethinking every part of the implementation: state serialization that is fast and space-efficient at the scale of agent context windows, scheduling that accounts for the massive variance in per-task execution time, and resumption that is fast enough to be transparent from the agent’s perspective even though the underlying execution has been checkpointed and suspended.

The Google DeepMind origin is relevant here because the specific problem of running thousands of RL training episodes in parallel — each episode involving an agent, an environment, and potentially multiple model API calls — is structurally identical to the production agent orchestration problem. The research team built infrastructure to run RL experiments at scale. The production team realized that infrastructure was exactly what they needed for production agents. The open-source release is the moment where those two lines converge.

Why the Gateway Primitive Is Underappreciated

I want to spend more time on the Gateway primitive because I think it represents a genuinely important security shift that the mainstream agent community has not fully internalized yet.

The current state of agent network security in most organizations looks like this: the agent runs in a container with unrestricted outbound network access, and security is enforced at the application layer through a combination of tool definitions (“this agent has access to these tools”) and prompt instructions (“do not access external services”). Both of these controls can fail. Tool definitions can be subverted through prompt injection — an adversarial document in the agent’s context that convinces it to call a tool in an unexpected way. Prompt instructions are not enforceable; the model will follow them until it doesn’t. Neither prevents an agent from making raw HTTP requests if the agent’s execution environment allows it.

The Gateway primitive in AX enforces network policy at a layer that the agent code cannot influence at all. The gateway is not configured by the agent. It is configured by the operator when the workspace is declared. The agent’s code runs inside a sandbox where the network stack has been pre-filtered. An agent that wants to call a host not on the allowlist will get a connection refused error, not an instruction that can be overridden. This is the difference between security policy enforced by the controlled system and security policy enforced by the controlling infrastructure. The latter is categorically stronger.

The practical implication is significant for anyone running agents that touch sensitive data. Consider an agent that has read access to a company’s internal documentation. With application-layer security, the threat model includes the possibility that an adversarial document in the documentation corpus contains instructions that cause the agent to exfiltrate data to an attacker-controlled endpoint. If the agent’s network access is unrestricted, this attack succeeds as long as the adversarial instructions are convincing enough. With Gateway-enforced network policy, the attack fails even if the agent follows the adversarial instructions perfectly, because the connection to the attacker-controlled endpoint is blocked at the network layer.

This is not a hypothetical threat. The prompt injection problem in retrieval-augmented agents — where documents in the retrieval corpus can influence agent behavior — is well-documented and actively exploited. The ZCode incident in September 2026 demonstrated that agents operating with broad network permissions will use those permissions in unexpected ways even without adversarial intent. The current trajectory of agent security incidents points directly at this class of problem.

AX’s Gateway is not a complete solution to agent security. It does not address prompt injection itself. It does not prevent an agent from doing harmful things within its declared scope. But it gives operators a meaningful, enforceable control over one of the highest-risk surfaces — unrestricted outbound network access — that no application-layer framework currently provides.

Reading the Commit History for Signals

The GitHub repository shows 625 commits on the main branch, 11 contributors, and the bulk of the significant structural work happening in a single large commit titled “Restructure AX into a general-purpose orchestration layer for agentic workloads.” That is the open-source release commit, which suggests the project was developed internally and released as a mostly complete artifact rather than developed in the open from the beginning. The commit rate since the open-source release is modest — a handful of commits in the weeks following the initial release, mostly documentation and tooling cleanup.

This pattern — large internal development followed by open-source release — is common for Google projects and carries specific implications. The architecture is mature enough that Google’s internal teams were confident releasing it. The contributor base is narrow because most of the development history is internal. The community-contributed feature velocity will be limited until the documentation improves enough that external contributors can meaningfully engage with the codebase.

The v0.3.0 release tag and the explicit breaking-changes warning suggest the team is treating this as a genuine pre-1.0 product rather than marketing a research prototype as production-ready. That is a more honest stance than many open-source releases from large organizations, which often ship projects at a high version number to imply production readiness that is not actually there. The willingness to say “we will break things” is a sign that the team is thinking about the project’s long-term trajectory rather than its immediate reception.

What I would watch in the next three months: whether external contributors start appearing in the commit history, whether the issue tracker reflects active engagement from users outside Google, and whether the documentation becomes detailed enough to deploy AX without reading the source code. Those three signals together will tell you whether this is becoming a community project or remaining a Google-owned open-source artifact maintained by a small internal team.

The Broader Race for Agent Infrastructure Primitives

AX is not the only project in this space. The GitHub trending page the same week AX launched included Coder’s coder/coder — a system for providing secure development environments for developers and their agents — at 461 stars in a single day. The akitaonrails/ai-memory project in Rust was trending for long-term memory across agent CLI sessions. The trycua/cua project is building cross-OS fleet infrastructure for computer-use agents with an emphasis on benchmarks and training data generation.

Each of these projects is addressing a different slice of the same problem: the infrastructure required to run autonomous agents reliably at scale is not provided by the application-layer frameworks, and multiple teams are building that infrastructure independently. AX is the most complete and the most production-credible of the current open-source options, largely because of its Google DeepMind provenance. But it is not operating in a vacuum, and the space is moving quickly enough that the landscape will look substantially different in six months.

The interesting structural question is whether agent execution infrastructure will consolidate around one or two platforms — similar to how container orchestration consolidated around Kubernetes — or whether it will fragment across multiple competing systems with different trade-offs. The container orchestration history is instructive: Docker Swarm, Apache Mesos, Nomad, and Kubernetes all coexisted for several years before Kubernetes achieved dominant mindshare, largely because it had strong backing from Google (which had decade-plus of experience with Borg) and because the Kubernetes API model proved flexible enough to accommodate a wide range of workload types through extension mechanisms.

AX’s Kubernetes-adjacent design — same API patterns, same deployment model, same operator experience — is clearly a deliberate choice to position it as a natural extension of existing Kubernetes infrastructure rather than a competing system. If you already run Kubernetes, AX is not asking you to replace it; it is asking you to deploy one more control plane on top of it. That is a meaningfully lower adoption barrier than asking organizations to replace their orchestration infrastructure entirely, and it mirrors exactly the strategy that allowed Kubernetes extensions and operators to proliferate once the core platform achieved critical mass.

Whether that strategy succeeds for AX depends on whether Agent Substrate achieves the density and performance claims in production deployments, whether the documentation improves enough to reduce the deployment complexity, and whether the community grows large enough that the ecosystem effects — integrations, tooling, shared knowledge — make AX more valuable than the alternatives. None of those are guaranteed. All of them are plausible.