Agent Substrate: 250 Agents on 8 Pods

Agent Substrate runs roughly 250 stateful agent sessions on 8 Kubernetes pods and resumes any of them in under a second. Google Cloud announced it on May 21, 2026; the repository's first line tells you it isn't an officially supported Google product. Both statements are accurate, and if you're evaluating this for anything with a budget attached, the second one matters more than the first.

Key Takeaways:

• Google Cloud introduced Agent Substrate in a GKE blog post by Brandon Royal and Tim Hockin, presenting it as a new open source project rather than a supported product.
• The README states plainly that it is not an officially supported Google product and is not eligible for Google's open source vulnerability rewards programme.
• The core trick is oversubscription: agents idle most of the time, so a large set of "actors" maps onto a small set of ready "workers" with snapshot-based suspend and resume.
• It's not an SDK for building agents. It runs them, and it deliberately holds no opinion about what they are.
• One release exists, tagged v0.0.0 on May 19, 2026, and the README says the APIs are almost guaranteed to change.

What Agent Substrate is

Take the demo the project leads with, because it explains the design faster than the architecture does. A Substrate cluster juggles about 250 stateful actors across 8 physical pods, over thirty times more actors than the hardware could hold if each got its own slot. Working memory and filesystem state survive hibernation through full-state snapshots, so an actor that gets swapped out and swapped back in doesn't notice.

The bet underneath is a behavioural observation rather than a systems one. Agents spend most of their existence waiting: on a model response, on a tool call, on a human. Kubernetes was built for thousands of long-running services that hold their resources, not for a swarm of workloads that are idle 95% of the time and then need a CPU immediately. Google's own framing in the launch post is that standard Kubernetes handles long-running services while Substrate is designed for "the chatter of millions of sub-second tool calls that would otherwise overwhelm a standard control plane."

So Substrate adds a minimal control plane beside Kubernetes rather than on top of it, keeping Pods and Pod autoscaling for infrastructure provisioning while taking over actor scheduling and traffic routing itself. Sandboxes come in two flavours, microVMs and gVisor, with the same lifecycle operations across both.

The operations it cares about are small and specific: create and destroy an actor, suspend and resume one, assign actors to workers in real time, and route incoming traffic to wherever an actor currently lives. Suspend and resume carry the weight. If resuming meant replaying a conversation and rebuilding a container, oversubscription would cost more than it saved, so Substrate snapshots volatile RAM along with the filesystem and restores both. What comes back is the same process at the same instruction, not a re-creation that has to be told what it was doing.

Google's stated reason for building beside Kubernetes rather than inside it also explains what the project won't fix. Provisioning and worker lifecycle stay on Kubernetes, so you still run a cluster, still pay for the nodes, and still own the upgrade path. Substrate makes each node hold far more agents; it does not remove the node.

Whose project is it, exactly

This is where most coverage gets sloppy, in both directions. The repository sits under an agent-substrate organisation, and the README's first paragraph reads: "This is not an officially supported Google product. This project is not eligible for the Google Open Source Software Vulnerability Rewards Program."

Read that as a disclaimer and you'd conclude Google has nothing to do with it. That would be wrong.

Google Cloud announced the project on its own blog on May 21, 2026, under the headline "Agent Sandbox on GKE is now available for everyone, and a first look at Agent Substrate." The authors are Brandon Royal, a product manager on GKE, and Tim Hockin, a GKE software engineer who has been on Kubernetes since its beginning. The post describes Substrate as taking the secure runtime and snapshotting from Agent Sandbox and pairing them with a control plane that sidesteps specific Kubernetes limits without reinventing the rest, then invites the community to help build it.

The accurate reading is narrower and more useful than either extreme. Google started it, staffs it, and markets it, and has withheld the two things an enterprise buyer actually wants: a support commitment and inclusion in the vulnerability rewards programme. Anyone writing "Google's official agent runtime" in a procurement document is overstating what the licence and the README promise.

What it is not

The README spends a paragraph refusing a job, which is rare enough to quote: Agent Substrate is a low-opinion system, the workloads it manages don't have to be literal AI agents, and it is not an SDK for building agents but a system for running them at scale.

That distinction decides whether this repo is relevant to you. If you're writing an agent, Substrate gives you nothing; you want a framework. If you're operating a fleet of other people's agents and your compute bill is dominated by processes doing nothing, this is aimed squarely at you.

Compatibility follows from the same design. Because it manages standard OCI containers at the kernel level through gVisor, the harness inside doesn't matter. The README names ADK, LangChain, Claude Code and Codex, and points out that MCP servers can be deployed as Substrate actors, which is a neat consequence of not caring what's in the box.

That last item is the sleeper. Treating an MCP server as a suspendable, snapshottable actor means a tool endpoint stops being a service you keep running and becomes something that materialises when called and hibernates when it isn't, which is a better fit for how tools are actually used than a permanently warm container.

There is already an ecosystem project building on it: Agent Executor, a distributed agent runtime that Google Cloud describes in a separate post, sits in the google organisation and uses Substrate underneath. Judging a young infrastructure project by whether anything real is built on it is usually more informative than the star count, and here there is at least one, from the same company.

How mature is it

One release. Tagged v0.0.0 on May 19, 2026, and nothing since, as of August 2026.

The README's status section is equally unambiguous: early development, not ready for production use, APIs almost guaranteed to change, no backward compatibility guarantees, and everything in the project may be changed. Kubernetes support covers the latest stable release and the previous minor, which is a narrow window to hold if you're running older clusters.

The activity numbers cut both ways. 1,453 stars and 254 forks in a hundred days is real interest, and commits were still landing on August 21. But 392 open issues against a repository this young says the surface area is large and the edges are unfinished, and a release tag that hasn't moved in three months while the main branch has says the maintainers don't yet consider any of it worth naming a version. That is a defensible position for infrastructure at this stage; it is also the reason MoClaw runs agents on a hosted machine that exists today rather than on a control plane whose APIs are promised to change.

So the shape is a serious engineering effort with a public sponsor and a v0.0.0 tag, which is exactly the profile of something to prototype against and not to launch on. If you want the capability rather than the project, our rundown of agent deployment methods covers what shipping today actually costs.

The idea worth stealing even if you never run it

Substrate's central insight generalises past Kubernetes, and it's the reason the project is worth reading about even if you'll never operate one: provisioning compute per agent is the wrong unit, because the thing you're paying for is mostly idle.

Most teams meet that problem in a smaller form first. An agent needs a machine that stays awake so a scheduled run can fire and a long task can finish, so someone leaves a laptop plugged in, or rents a VM per person and watches it idle. That's the same waste Substrate attacks with snapshots and oversubscription, one layer up. MoClaw solves it the other way round, as a hosted cloud AI computer where the always-on part is somebody else's problem to pool, and it sits alongside whatever you already run locally rather than replacing it.

The second thing worth borrowing is the snapshot discipline. Substrate treats suspend and resume as a first-class operation, with RAM and filesystem preserved, because a session that has to be rebuilt from scratch isn't really resumable. Any setup where an agent's context evaporates when a process dies has the same defect at a smaller scale, and the fix is the same: put the session somewhere that outlives the client. Our explainer on agent sandboxes covers the isolation half of that story.

The third is about who should be doing this work at all. Substrate is a reasonable thing to run when the number of agents is large enough that a percentage point of density is worth an engineer's quarter. Below that line, standing up a control plane, a sandbox pool and the cluster underneath it is a project that competes with the product you were actually trying to ship, and it competes badly, because none of that infrastructure is visible to the person paying you. MoClaw is the other end of that decision: a hosted cloud AI computer where the pooling, the snapshotting and the staying-awake are already somebody's full-time job, and the only thing left for you to build is the agent.

Worth keeping in proportion, though. If you're operating a platform where thousands of tenant agents sit idle between tool calls, none of the above applies to you and Substrate is aimed precisely at your bill. The project is honest about which of those two readers it wants, which is more than most infrastructure repositories manage.

FAQ

Is Agent Substrate made by Google?

Google Cloud introduced it and GKE engineers wrote both the launch post and the code, but the repository states it is not an officially supported Google product and is not eligible for Google's open source vulnerability rewards programme. Treat it as a Google-initiated open source project without a support commitment attached, as of August 2026.

What sandbox technologies does Agent Substrate support?

microVMs and gVisor, with consistent lifecycle operations across both. Because it manages standard OCI containers at the kernel level, the agent framework running inside is irrelevant to it.

Is Agent Substrate production-ready?

No, and the project says so. One release exists, tagged v0.0.0 in May 2026, and the README states it is in early development, not ready for production use, with APIs almost guaranteed to change and no backward compatibility guarantees.

How is Agent Substrate different from Agent Sandbox on GKE?

Agent Sandbox is the secure runtime and snapshotting layer, and it reached general availability on GKE in May 2026. Agent Substrate reuses those capabilities and adds a control plane for scheduling actors onto workers and routing traffic to them, aimed at density rather than isolation.

Do I need Agent Substrate to run AI agents?

Almost certainly not. It targets platform operators running large fleets where idle compute dominates the bill. Running a handful of agents needs a machine that stays up, not a control plane.