Who substrate is for#
Infrastructure engineers running large-scale multi-agent systems
Agent Substrate lets you oversubscribe your Kubernetes cluster, running more concurrent agent sessions than you have worker pods. If your agent system has many agents idle waiting for LLM responses or user input, the actor multiplexing model converts that idle time into capacity for more agents on the same hardware.
Skip if:
Skip if you are running a small number of agents (under 50 concurrent) with consistently high utilization. The multiplexing benefit only applies when the idle ratio is high; a heavily active agent pool still needs one worker per active agent.
Teams deploying MCP servers as sandboxed infrastructure
The README explicitly lists deploying MCP servers as Substrate Actors, giving each server its own sandboxed environment with zero-trust isolation. This lets you host many MCP servers on shared infrastructure with full state preservation between tool calls.
Skip if:
Skip if your MCP servers are stateless and short-lived. Substrate's value is preserving state across sessions; stateless servers gain little from the actor model.
RL and training pipeline operators on Kubernetes
The architecture targets holistic infrastructure optimizations for RL scenarios that span agentic, inference, and training cycles on the same Kubernetes cluster. Agent Substrate is designed to share infrastructure with inference and training workloads, reducing the operational overhead of maintaining separate clusters for each phase.
Skip if:
Skip if your RL training uses dedicated hardware with specialized schedulers (Slurm, YARN) that are not Kubernetes-native. Substrate runs on Kubernetes only and has no integration with non-Kubernetes schedulers.
Developers building coding agent environments
The Claude Code Multiplex demo shows multiple Claude Code agents multiplexed onto a limited pool of workers, oversubscribing physical hardware. The Sandbox Demo provides a secure Alpine Linux shell environment that preserves filesystem state across sessions, which is the base requirement for a stateful coding agent environment.
Skip if:
Skip if you need a production-stable coding environment today. The project is in early development with no backward compatibility guarantees, making it unsuitable for customer-facing coding agent products at this stage.
The problem it solves#
Running AI agents at scale requires each agent to have its own sandboxed execution environment for filesystem isolation, memory, and network controls. With standard container runtimes, each running agent occupies a dedicated worker even when idle, which means infrastructure costs grow linearly with the number of agents. For an RL training pipeline with thousands of concurrent agent workers, or a coding agent system juggling hundreds of active sessions, this gets expensive fast.
The deeper issue is that agent workloads are idle most of the time. An agent waiting for a user response, an LLM reply, or a tool call result still consumes a full server slot. Paid hosted execution platforms charge per execution-second for that idle time, and self-hosting with naive container runtimes wastes the same resources. There is no standard way in a vanilla Kubernetes setup to snapshot a running agent, evict it to free the worker, and restore it on demand at sub-second latency.
How it solves it#
High-density actor multiplexing
Maps a large pool of actors (running agents or applications) onto a smaller set of shared worker pods, achieving 30x or more oversubscription. The runtime suspends inactive actors and resumes them on demand, exploiting the fact that agent workloads spend most of their time idle. The Counter Demo shows approximately 250 stateful actors multiplexed onto 8 physical pods.
Sub-500ms suspend and resume
Actors suspend and resume in under 500ms at over 500 activations per second across the cluster. Full state is preserved across hibernation cycles, including volatile RAM and filesystem state, via full-state snapshots. This makes it viable to evict an idle actor from a shared worker and restore it on the next incoming request without the caller noticing a context switch.
Multiple sandbox technologies
Supports both gVisor (OCI container-level isolation via a user-space kernel) and microVM sandboxes under a unified actor lifecycle API. You can choose the isolation model that fits your threat model and performance requirements without changing how actor lifecycle operations are managed.
Framework-agnostic OCI container support
Because Substrate manages standard OCI containers at the kernel level, agents built on any framework run without modification. The README lists explicit support for Google ADK, LangChain, Claude Code, CodeX, and MCP servers deployed as Substrate Actors, covering the major agent development stacks.
Kubernetes-native infrastructure management
Uses Kubernetes Pods and Pod autoscaling as the underlying infrastructure layer. The atecontroller reconciles WorkerPool custom resources, the atelet DaemonSet supervises physical worker pods on each node, and atenet provides Envoy-based routing and proxy sidecars. This lets Substrate run alongside other Kubernetes workloads with standard infrastructure tooling.
Strengths and trade-offs#
Strengths
- Apache 2.0 license with full self-hostingThe entire project is Apache 2.0 licensed, which permits commercial use, modification, and distribution without licensing fees. Unlike E2B or Modal, which are managed APIs with per-execution billing, Substrate runs entirely on your own Kubernetes cluster. Once your cluster is provisioned, there are no per-execution charges at any scale.
- Google-origin codebase with active developmentCreated by the team behind Google's Agent Executor and integrated into kagent (a CNCF Sandbox project), the codebase had a last push as recent as September 2026. The project hosts a weekly community meeting and has channels in the CNCF Slack workspace, with a public Google Group for announcements and technical discussions.
- Stateful actor snapshots across sessionsFull-state snapshots preserve an actor's working memory and filesystem state across suspend and resume cycles. The Sandbox Demo shows an Alpine Linux environment preserving filesystem state across arbitrary shell sessions, and the ADK integration preserves agent session state across invocations as actor state.
Trade-offs
- -Not production-ready (early development)The README explicitly states the project is in early development, not ready for production use, and that APIs are almost guaranteed to change with no backward compatibility guarantees. With 520 open issues and the project under six months old as of late 2026, teams should expect breaking changes before any stable release.
- -Requires a running Kubernetes clusterThere is no Docker Compose or standalone deployment path. The quickstart requires Go, kubectl, and Docker installed locally, then provisions a KinD cluster. Production deployments target GKE with GCS for snapshot storage. For teams without existing Kubernetes infrastructure, the setup cost is significant before any actors can run.
- -Network egress is restricted by defaultZero-trust network isolation means actor egress is controlled and filtered by default. The docs include an egress traffic guide and a man-in-the-middle interception guide for egress policy enforcement. Agents that need to call arbitrary external APIs require explicit egress configuration, adding operational overhead beyond the base cluster setup.
substrate vs alternatives#
Agent Substrate vs E2B
Both tools provide sandboxed execution environments for AI agent workloads, but they operate at different layers. E2B is a managed hosted API: you call their SDK, they spin up a microVM sandbox on their infrastructure, and you pay per execution-second. Agent Substrate is a self-hosted Kubernetes runtime you deploy on your own cluster.
| Feature | Agent Substrate | E2B |
|---|---|---|
| License | Apache-2.0 | Proprietary |
| Deployment | Self-hosted on Kubernetes | Managed cloud API |
| Pricing model | Your cluster costs | Per execution billing |
| Sandbox technology | gVisor or microVM | microVM |
| Production readiness | Early development | Generally available |
Agent Substrate is the better choice when you need to run hundreds or thousands of agent sandboxes on your own infrastructure with no per-execution billing at scale. E2B is the better choice when you want a working sandbox API today without managing Kubernetes, or when you need production stability now. Agent Substrate's early-development status means API-breaking changes are expected.
Agent Substrate vs Modal
Modal is a managed serverless compute platform for Python workloads, used to run AI inference and agent code at scale. Like E2B, it is a hosted API with per-execution billing and no self-hosting option.
| Feature | Agent Substrate | Modal |
|---|---|---|
| License | Apache-2.0 | Proprietary |
| Deployment | Self-hosted on Kubernetes | Managed cloud |
| Pricing model | Your cluster costs | Per compute-second |
| Language support | Any OCI container | Python-first |
| Production readiness | Early development | Generally available |
Agent Substrate supports any OCI container and any agent framework; Modal is Python-first. For teams with Go, Node, or polyglot agent stacks, Substrate avoids the Python constraint. For teams that want a working production system immediately, Modal's free tier is available without any infrastructure setup while Substrate requires a Kubernetes cluster.
Agent Substrate vs Daytona
Daytona focuses on standardized development environment provisioning, giving developers reproducible workspaces that run on remote or local infrastructure. The use cases overlap when Substrate hosts coding agents (it includes a Claude Code Multiplex demo), but the abstractions differ. Daytona manages long-lived developer workspaces; Substrate manages short-lived, highly multiplexed agent actors with sub-second suspend and resume.
Quick start#
Self-hosting requires a Kubernetes cluster and Go; the quickstart installs the kubectl-ate CLI after setting up a local KinD cluster.
```shell
git clone https://github.com/agent-substrate/substrate
go install ./cmd/kubectl-ate
```What it's built on#
- Languages
- GoPython
FAQ#
Is Agent Substrate production-ready?
No. The README explicitly states the project is in early development, not ready for production use, and that APIs are almost guaranteed to change with no backward compatibility guarantees. As of late 2026 the project is under six months old. Use it for development, evaluation, and contribution to the project, not production workloads.
Does Agent Substrate require Kubernetes?
Yes. There is no standalone deployment path. Local development uses KinD (Kubernetes in Docker), and production deployments target GKE or other Kubernetes clusters. You need Go, kubectl, and Docker installed to run the quickstart. There is no Docker Compose path and no single-binary install.
How does Agent Substrate compare to E2B or Modal?
E2B and Modal are managed hosted execution platforms with per-execution billing and no self-hosting option. Agent Substrate is a self-hosted runtime you deploy on your own Kubernetes cluster with no per-execution billing. The trade is managed convenience (E2B, Modal) versus infrastructure control and cost savings at scale (Substrate). E2B and Modal are better choices if you want to avoid managing Kubernetes infrastructure or need a production-stable API today.
What agent frameworks does Agent Substrate support?
The README lists explicit support for Google ADK, LangChain, Claude Code, CodeX, and MCP servers. Because Substrate manages standard OCI containers at the kernel level, any agent that runs in an OCI container is compatible without framework-specific changes to the agent code.
What is the license for Agent Substrate?
Apache 2.0. You can use it commercially, modify it, and distribute it without licensing fees or hosting restrictions. The Apache 2.0 license imposes no restrictions on how you run or extend Substrate within your own infrastructure, unlike source-available licenses that restrict resale as a managed service.
Similar open-source tools#
ax
Declarative runtime for autonomous agent workloads
FckSignups
Open-source tools that work instantly, no signup required
agent-toolkit-for-aws
Empower AI agents to build and manage AWS applications
Omnara
Open-source agent deployment API. Self-host or use Omnara Cloud.
orbi
GitHub Issues in, reviewed code merged, tagged releases out
dify
Visual AI workflow builder with RAG, agents, and self-hosting