agent-substrate

Agent Substrate

Overview

Agent Substrate is a Kubernetes extension built by Google that solves a problem most developers haven’t hit yet but will: how do you run hundreds or thousands of stateful AI agent sessions without burning through your infrastructure budget? The project hit 511 stars within a month of its May 2026 launch, driven largely by its demo showing 250 stateful actor sessions multiplexed across just 8 physical pods. That’s a 30x density improvement over vanilla Kubernetes scheduling.

The project comes from Google’s internal agent infrastructure team — the same organization behind Agent Development Kit (ADK) and Agent Executor (google/ax). It’s not an officially supported Google product (the README is clear about that), but it carries the architectural DNA of systems designed to run at Google scale. The team hosts weekly community meetings, has active CNCF Slack channels, and ships with working demos that actually run. For a project barely a month old, the maturity level is notable.

The core problem Agent Substrate addresses is the mismatch between how Kubernetes schedules workloads and how AI agents actually behave. Agents spend most of their time idle — waiting for user input, thinking, or blocked on API calls. Standard Kubernetes treats each agent as a persistent pod, which means you’re paying for compute that sits idle 90% of the time. Agent Substrate flips this by maintaining a small pool of warm “worker” pods and dynamically mapping a much larger set of “actors” (agent sessions) onto them. When an agent needs to act, it gets teleported to an available worker with sub-second latency. When it’s done, its full state — RAM, filesystem, everything — gets snapshotted and the worker becomes available for the next agent.

Why it matters

If you’re building any kind of multi-tenant AI system — a coding agent platform, a customer support bot fleet, an autonomous workflow engine — you’ll eventually hit the scaling wall where Kubernetes pod-per-agent economics don’t work. A single coding agent session might use 512MB of RAM but only actively compute for 5% of its lifetime. Multiply that by 1,000 concurrent users and you’re looking at 500GB of RAM for workloads that are mostly sleeping.

Agent Substrate is the first open-source project to tackle this at the infrastructure level rather than the application level. Previous approaches required you to build session management, state serialization, and traffic routing into your agent framework. Substrate handles all of that transparently — your agent code doesn’t need to know it’s running on a multiplexed substrate. It just sees a normal container with a filesystem and network.

The timing matters too. The CNCF has been watching the agent infrastructure space closely, and Agent Substrate’s presence in CNCF Slack channels signals potential future cloud-native ecosystem integration. Google’s backing gives it credibility, but the framework-agnostic design (it works with LangChain, ADK, Claude Code, Codex, or any OCI container) means it’s not just a Google ADK plaything.

Key Features

Actor-Worker Multiplexing. The fundamental innovation. Agent Substrate maintains a pool of warm worker pods and dynamically assigns actor sessions to them. An actor gets a worker when it needs to compute, and releases it when idle. The system handles the mapping transparently — your agent code runs in a normal container, unaware it’s sharing infrastructure. The demo shows 250 actors on 8 workers, achieving 30x oversubscription. This is the kind of density that makes multi-tenant agent platforms economically viable.

Full-State Suspend and Resume. When an actor goes idle, Agent Substrate captures its complete state — volatile RAM, filesystem, network connections — and stores it. When the actor needs to resume, it gets teleported to any available worker with sub-second activation. The state persistence is perfect: your agent’s working memory, open files, and even in-flight computations survive hibernation cycles without any application-level code. This is what enables the multiplexing — you can’t share workers if you can’t cleanly suspend and resume sessions.

Framework and Runtime Agnostic. Because Agent Substrate manages standard OCI containers at the kernel level via gVisor, it doesn’t care what’s inside the container. LangChain agents, ADK agents, Claude Code sessions, MCP servers, custom Go services — they all work. The system provides session identity and persistent working memory as platform primitives, but your agent framework doesn’t need to integrate with them. This low-opinion design is critical for adoption: nobody wants to rewrite their agent code to fit a new infrastructure layer.

gVisor-Based Sandboxing. Each actor runs inside a gVisor sandbox, which provides kernel-level isolation without the overhead of full VMs. This matters for multi-tenant scenarios where you’re running untrusted agent code — a compromised agent can’t escape its sandbox to affect other actors or the host. The security model is stronger than container namespaces alone but lighter than Kata Containers or Firecracker.

Kubernetes-Native Integration. Agent Substrate runs on any standard Kubernetes cluster and doesn’t interfere with regular workloads. It uses Kubernetes for infrastructure provisioning and management, but takes the control plane out of the critical scheduling path for agent-specific operations. You get the operational familiarity of kubectl, Helm, and the Kubernetes ecosystem while gaining agent-specific scheduling intelligence on top.

Session Identity and Routing. The system provides built-in session identity management and traffic routing. Incoming requests get routed to the correct actor regardless of which physical worker it’s currently assigned to. If the actor is hibernating, it gets resumed on an available worker before the request is served. This routing layer is what makes the multiplexing transparent to clients — they always talk to the same logical session.

Agent Executor Ecosystem. Agent Substrate pairs with Google’s Agent Executor (google/ax), a distributed agent runtime that demonstrates building production agent harnesses on top of the substrate. The two projects together provide the full stack from infrastructure to application layer, with integration guides and working demos for common patterns like coding agents, tool-calling agents, and multi-step workflow agents.

Use Cases

• Multi-tenant coding agent platforms — If you’re building something like a hosted Claude Code or Cursor service, Agent Substrate lets you run thousands of concurrent coding sessions without provisioning a pod per user. Each session gets its own isolated filesystem and terminal state, multiplexed across a shared worker pool.

• Customer support bot fleets — Companies running hundreds of support agents that handle conversations with context persistence. Agents can hibernate between conversations and resume instantly when a customer returns, without keeping pods alive 24/7.

• Autonomous workflow engines — Long-running agent workflows that execute over hours or days, with frequent idle periods waiting for external events, API responses, or human approvals. Substrate’s suspend/resume means you don’t pay for idle compute.

• MCP server hosting — Deploy Model Context Protocol servers as Substrate Actors for durable, sandboxed tool serving. Multiple LLM sessions can share MCP server instances with proper isolation.

• Development and testing environments — Run hundreds of isolated agent dev environments on a small cluster, each with its own filesystem and terminal state. Developers can pause and resume their environments across machines.

Pros and Cons

Pros:

• Solves a real infrastructure cost problem that every multi-tenant agent platform will face. The 30x density improvement isn’t theoretical — it’s demonstrated in the project’s demo with 250 sessions on 8 pods.
• Framework-agnostic design means you don’t have to rewrite agent code. Any OCI container works, which is the right architectural choice for infrastructure tooling.
• Google backing with active community infrastructure (weekly meetings, CNCF Slack, YouTube demos) suggests this isn’t going to be abandoned in three months.
• gVisor sandboxing provides meaningful security isolation for multi-tenant scenarios without the performance penalty of VMs.

Cons:

• Self-described as “VERY early development” with APIs that are “almost guaranteed to change.” Building production systems on this today carries significant migration risk.
• Kubernetes dependency means this isn’t for teams running agents on simple VPS or serverless setups. You need a K8s cluster and operational expertise to run it.
• The actor-worker abstraction adds complexity. If you’re running fewer than 50 concurrent agents, the overhead of managing a Substrate cluster probably isn’t worth it compared to simple pod-per-agent scheduling.
• Limited documentation beyond the README and demos. The community is active but small (23 contributors), and the project is barely a month old.

Getting Started

# Prerequisites: Go, kubectl, Docker installed and configured

# Clone the repository
git clone https://github.com/agent-substrate/substrate.git
cd substrate

# Run the counter demo (simplest starting point)
cd demos/counter
# Follow the demo README for cluster setup

# Or try the Secret Agent demo for a more realistic agent scenario
cd demos/agent-secret

# For integration with Agent Executor (google/ax)
# See: https://github.com/google/ax/blob/main/manifests/README.md

Alternatives

Kubernetes Horizontal Pod Autoscaler (HPA) — The default approach for scaling agent workloads. HPA adds pods when CPU/memory metrics cross thresholds, but it can’t multiplex sessions or suspend/resume stateful agents. Choose HPA when your agents are stateless or short-lived, and you don’t need the density optimization. For long-lived, stateful agent sessions, HPA’s pod-per-model economics break down fast.

AWS Lambda / Google Cloud Run — Serverless platforms that scale to zero and charge per request. They work well for stateless agent tool calls but struggle with persistent sessions, filesystem state, and the long-running nature of agent workflows. Choose serverless when your agents are simple request-response tools, not stateful autonomous workers.

Nomad with custom drivers — HashiCorp Nomad offers more scheduling flexibility than Kubernetes and could theoretically implement similar actor-worker multiplexing. But you’d be building the session management, state persistence, and routing layers from scratch. Choose Nomad if you’re already in the HashiCorp ecosystem and want to build custom scheduling, but expect significant engineering investment.

Verdict

Agent Substrate is the most interesting infrastructure project in the AI agent space right now. It’s solving a problem that most developers haven’t encountered yet — the economics of running stateful agents at scale — but will absolutely hit as multi-tenant agent platforms mature. The 30x density improvement is real, the Google backing provides credibility, and the framework-agnostic design avoids the trap of being an ADK-only tool. The biggest risk is maturity: this project is a month old with explicitly unstable APIs. If you’re building a production agent platform today, you should be watching Agent Substrate closely and prototyping with it, but have a fallback plan for when the APIs shift. For teams with fewer than 50 concurrent agents, the complexity overhead isn’t justified yet. But if you’re planning for hundreds or thousands of concurrent sessions, this is the project to build on — or at least to steal ideas from.