Clarion Street

Agents Are Becoming Actors: Inside Google's AX and the Agent Substrate

·7 min read

Google announced its open agent runtime at I/O on May 20, 2026, and for four months it stayed mostly quiet. InfoQ wrote it up on September 22 as “Google Open-Sources AX, a Kubernetes-Style Orchestrator for Autonomous AI Agents,” and a Hacker News thread discussed it the same week. The project shipped in May as Agent Executor and now goes by AX, the repo google/ax, built on a Kubernetes layer the GKE team calls Agent Substrate.

I have already written about the agent control plane and about durable execution, so I will not redo either argument. What changed this month sits one layer below both. AX is not another orchestrator. It treats each agent session as a stateful actor that can be checkpointed, suspended, and resumed, then packs dozens of those actors onto a handful of machines. That is a compute story, and it landed the same week as LangChain’s opposite bet, a managed service that does all of it for you. The collision is what I want to write about.

Agents are a scheduling problem, not a serving problem

Agents are “stateful, bursty, and long-running.” They compute hard for a minute, then sit idle waiting on a model response, a tool call, or a human approval. A stateless microservice or a batch orchestrator handles that shape badly. Keeping an idle sandbox alive for every agent is expensive, and cold-starting one on demand adds latency to an interactive loop.

This is the same durability problem I wrote about before, but AX answers it differently. Temporal and Inngest persist an agent’s state so it can resume after a crash. AX persists the whole sandbox so it can be suspended while idle and resumed when there is work. The unit being moved around is a process, not a workflow record.

Checkpoint, suspend, resume

AX wraps each agent session in an “isolated actor sandbox” with CPU and memory limits. When the agent idles, the runtime checkpoints and suspends it. When work arrives, it resumes “in sub-second intervals with zero cold-start delay” and multiplexes “dozens of tasks onto shared host workers.”

The published numbers are the interesting part. Agent Substrate’s README claims “millions of sandboxes with 10x higher density than standard container runtimes,” with “sub-500ms resume operations at over 500 suspend/resume activations per second.” Its demo packs roughly 250 stateful actors onto 8 physical pods, a 30x oversubscription. The mechanism is stated plainly in the README: agents “tend to be idle most of the time,” so you map a larger set of actors onto a smaller set of ready workers.

Two isolation paths sit underneath. One is gVisor’s runsc, which checkpoints and restores userspace processes. The other is a microVM path built on cloud-hypervisor, where each actor runs as its own virtual machine. You can see both in the repo: ateom-gvisor runs the checkpoint and restore commands inside sandboxed pods, and ateom-microvm is its VM peer.

Above the sandbox, AX exposes four declarative primitives under the ax.io/v1alpha1 API group, Task, Workspace, Gateway, and Model. I covered those when they landed, so I will skip them. The point worth keeping is that Substrate is not an SDK. Its README says it is “not an SDK for building agents, but rather a system for running them at scale,” and it lists ADK, LangChain, Claude Code, Codex, and MCP servers as supported frameworks.

The opposite bet shipped the same week

On September 24, LangChain shipped Managed Deep Agents 0.8. It packages the Deep Agents harness with “all of the infrastructure required to run agents in production,” so teams can “focus on agent behavior instead of rebuilding the same infrastructure that every agent needs.” Auth, user-scoped memory, per-user credentials, and HTTP and Slack channels arrive as a managed service.

The two releases are not clean opposites, and I want to be precise about that. AX is not purely low-level; it layers workspace setup and model config on top of Substrate. LangChain is not purely high-level; Deep Agents is a real orchestration loop. And Substrate itself lists LangChain and ADK as frameworks it can host, so the low-level layer can run the high-level one. The cleaner framing is buy versus build. Managed Deep Agents is managed infrastructure as a service. AX is the primitive you run yourself on your own cluster.

Which you pick depends on whether you want to own the runtime or rent it. Teams running their own Kubernetes for cost or compliance reasons now have an answer built by Google’s GKE team. Teams that do not want to run any of it have a LangChain answer.

Two things that cut against both

Two adjacent releases complicate the picture. Microsoft Research published Agensh, a preprint arguing that the central orchestrator is itself the scaling bottleneck, and showed self-organized systems running 1,024 agents without one. Scaling from 1 to 128 agents lifted its mean ProgramBench pass rate from 19.31% to 28.78%. On the pandoc task, going from 1 to 1,024 agents lifted it from 33.89% to 55.06%. It is a preprint on a single benchmark family with a six-hour budget, so I read it as a signal rather than proof.

Cortex open-sourced engrams, a platform that runs coding agents like Claude Code and Codex in per-task microVMs in your own cloud. It already drives internal automations that open their own pull requests and escalate to humans. It is 0.x and its API is explicitly unstable. Both projects are early. What they share with AX is the direction: isolation and lifecycle are being pushed into the runtime, whether that runtime is a Kubernetes sandbox or a microVM.

The target is still moving

The most telling detail about AX is that its own control plane is mid-redesign. On September 20 the repo was restructured from a single CLI with an embedded Python harness into three binaries (ax-server, ax-controller, ax-task-runner), and task state moved from Kubernetes CRDs into Redis so the system could handle “millions of short-lived tasks without straining etcd.” On September 27 that was partly unwound. The controller and the Redis Streams queue were decommissioned in favor of direct, synchronous reconciliation in a single-binary ax-server, guarded by Redis distributed locks. Any post written this week is describing a moving target.

The Hacker News thread split cleanly. Infrastructure engineers liked that AX attacks “the prohibitive cloud costs of idle agents.” Developers pushed back on the “ergonomic workflows” claim, because the quickstart assumes a Kubernetes cluster, ko, a container registry, and a reachable Substrate control API. The sharpest criticism was identity: if AX oversubscribes pods, you can no longer trust a pod’s identity as belonging to a single workload. A reply from a project contributor noted Substrate is working on an OIDC/SPIFFE identity provider whose credentials are injected through the egress gateway, still “in flight” and expected “within a few weeks.”

Caveats

The performance figures come from the projects’ own READMEs and site, and I am treating them as goals until an independent benchmark exists. AX is pre-1.0, and Substrate says its APIs may still change with no backward-compatibility guarantee. The star counts, 12.2k for AX and 3.9k for Substrate as I write this, measure attention from the week of the HN spike, not production installs.

The name matters if you read older coverage. May’s announcement was “Agent Executor.” The repo and site are now “AX.” Substrate’s README opens with “This is not an officially supported Google product” and its ecosystem section lists google/ax and kagent (CNCF Sandbox) as primary consumers.

What I take from it

The actor model is an old idea, Erlang’s answer to fault-tolerant concurrency, returning for a specific reason. An agent is not a request you serve and forget. It is a stateful thing that lives for minutes or days and idles for most of that time. Treating it as a suspendable process instead of a running service is the right shape, and it is the thing I had not seen anyone actually build before this month.

The buy-versus-build split is a more useful way to read this week than any framework war. The churn inside AX is itself evidence of how early this is. The control plane is being redrawn weekly, while the sandbox checkpointing is the part that looks like it will last.

Sources

  1. Google Open-Sources AX, a Kubernetes-Style Orchestrator for Autonomous AI Agents — InfoQ, September 22, 2026
  2. Managed Deep Agents v0.8: new auth, memory, and channels — LangChain
  3. Introducing engrams: an open source software factory — Cortex
  4. Agensh: Scaling Organizational Intelligence to 1,024 Agents — Microsoft Research, arXiv
  5. google/ax: Google’s open agentic orchestration runtime — GitHub
  6. AX — agentexecutor.io
  7. agent-substrate/substrate: Agent Substrate, the core system — GitHub
  8. AX — Google’s Open Agentic Orchestrator — Hacker News discussion
  9. Introducing Agent Executor, Google’s distributed Agent Runtime — Google Cloud Blog, May 20, 2026