Agent Substrate: a Kubernetes control plane for multiplexing idle agents

What Agent Substrate is for, and who should care

Agent-like workloads are idle most of the time. An agent waits on a model response, a tool call, a human, or a queue. If each agent gets its own always-on pod, most of the cluster is reserved for work that is not happening. Agent Substrate takes that observation as its design premise: it maps a larger set of actors onto a smaller set of ready workers, and relies on idleness to oversubscribe the physical infrastructure.

The README is explicit that this is not an SDK for building agents. It is a runtime for running them at scale. The project calls itself low-opinion, meaning the workloads it manages do not have to be literal AI agents, though those are the example it uses. The intended audience is an infrastructure team that already runs Kubernetes and wants higher density than plain Pods and autoscaling give them, plus agent-specific scheduling and lifecycle control.

The stated targets are sub-second resume and suspend, heavy multiplexing onto the same hardware, and consistent lifecycle operations across sandbox technologies including microVMs and gVisor. Those are goals stated in the README, not measured results, and the repository does not publish a benchmark table in the documentation available.

Actors, workers and the Kubernetes layer underneath

The core abstraction is a pair: actors and workers. An actor is an application, such as an agent. A worker is a ready execution slot. The control plane manages an actor's lifecycle (create, destroy, suspend, resume), assigns actors to workers in real time, and routes incoming traffic to them. The README describes the control plane as providing full lifecycle management for agent sandboxes.

Kubernetes is not replaced. It handles infrastructure provisioning and worker lifecycle management through Pods, and the project builds on Pods and Pod autoscaling. Agent Substrate adds the agent-specific scheduling and control on top. The argument in the README is consistency: using Kubernetes underneath means the same infrastructure management applies to the other pieces of an end-to-end agent deployment, which the project frames as useful for reinforcement learning scenarios that span agentic, inference and training cycles.

Sandboxing happens at the kernel level. The README says Agent Substrate manages standard OCI containers via gVisor, and that microVMs are also supported as a sandbox technology. State persistence across hibernation is described as full-state snapshots of volatile RAM and filesystem state. The demo claims roughly 250 stateful actors across 8 physical pods, with 30x or more oversubscription. That is a demo description, not a reproducible benchmark number published in the repository.

The Go module path is github.com/agent-substrate/substrate, and the dependency list shows the shape of the system: Envoy control-plane packages for the data path, nftables and netlink for networking, containerd ttrpc, a PostgreSQL driver with goose migrations, and AWS and Google Cloud SDKs for storage and infrastructure. The installer builds a set of control-plane images (ateapi, atecontroller, atelet, atenet) and a kubectl plugin.

Installing Agent Substrate on a kind cluster

The README's quickstart is a development setup, not a production install. It assumes Go, kubectl and docker are installed and configured on your machine, and says other dependencies, including kind, are managed through Go. The first script creates a cluster and a local registry, defaulting to IPv4; the README notes that IP_FAMILY=dual or IP_FAMILY=ipv6 overrides that.

hack/create-kind-cluster.sh

Next the installer deploys the control plane along with PostgreSQL and rustfs.

hack/install-ate-kind.sh --deploy-ate-system

Then the counter demo, which is the walkthrough the README points at for reproducing the video.

hack/install-ate-kind.sh --deploy-demo-counter

The kubectl plugin is a separate Go install from the cmd directory.

go install ./cmd/kubectl-ate

With that in place you create an atespace, which the README says is required before creating actors, and then a counter actor inside it.

kubectl ate create atespace demo
kubectl ate create actor my-counter-1 -a demo --template=ate-demo-counter/counter

The README's quickstart continues with port-forwarding the network, but the text is truncated at that point, so treat the steps above as the confirmed part and read demos/counter/README.md for the rest. The Makefile is the other build path: it defines VERSION stamping through the internal/version package and builds images with ko, with KO_DOCKER_REPO defaulting to gcr.io/$(PROJECT_ID)/ate-images.

Where Agent Substrate is the wrong tool

The status section is unusually blunt: the project is in early development, not ready for production use, and the APIs are almost guaranteed to change. The README states there are no guarantees about backward compatibility and that everything may change. The release list contains a single entry, v0.0.0, tagged at the initial commit on 2026-05-19. The last push to the default branch was also on 2026-05-19, which is four months before the date of this article, so the repository does not show recent activity.

That combination rules it out for anything with an availability commitment. If your agents must stay up during an upgrade, you have no compatibility contract to plan around. If you need a supported product with an escalation path, this is a community project that states it is not an officially supported Google product.

The multiplexing model is also a poor fit for workloads that are not idle. The whole density argument rests on actors spending most of their time waiting. A service that holds CPU or memory continuously will not benefit from being juggled onto a shared worker pool, and the suspend and resume path adds state snapshotting that such a workload does not need. The README's own framing is that agent-like applications are the best example of what it is designed for.

A third boundary is the compatibility window. The README says the project aims to support the latest stable Kubernetes release and the previous minor release. Anything older is outside the stated target, and the quickstart itself is written against a kind cluster rather than an existing production cluster.

How it compares with running agents as plain Kubernetes Pods

The honest alternative is what most teams do today: run each agent as its own Deployment or Pod, and let the Horizontal Pod Autoscaler and the scheduler handle placement. Kubernetes is good at this. It gives you a stable API, a large ecosystem, and a well-understood operational model. The cost is that a Pod holds its resources while the agent inside it is idle, and Pod startup is not designed around resuming a specific agent's memory state onto whichever node happens to be free.

Agent Substrate keeps Kubernetes for provisioning and worker lifecycle but inserts its own scheduling and control layer for the actor-to-worker mapping. The difference is not the container runtime; both run OCI containers. The difference is that Substrate treats an actor's suspend and resume as a first-class operation with full-state snapshots, so an actor can move to any available worker in the pool rather than staying pinned to the node it started on. That is what makes oversubscription possible and what the demo's 250 actors across 8 pods is meant to illustrate.

The trade is control for compatibility. You inherit a young API surface, a control plane you must install and operate (ateapi, atecontroller, atelet, atenet, plus PostgreSQL and rustfs in the kind setup), and a sandbox layer that runs containers through gVisor at the kernel level. If your agents are long-running and busy, plain Pods plus autoscaling remain the simpler answer, and the README's own compatibility statement gives you no reason to migrate yet.

Licence, maintenance and upgrade cost

The project is licensed under Apache-2.0, and the repository carries a LICENSE file plus a _LICENSES/ directory. Apache-2.0 is a permissive licence with an explicit patent grant and a requirement to preserve notices; it does not impose copyleft obligations on your own code. This is a description of the licence text, not legal advice, and the vendored third-party dependencies under vendor/ carry their own licences that you should review before redistribution.

Maintenance is the part to weigh carefully. The last push to the default branch was on 2026-05-19, and the only release is v0.0.0 from the same date. The README states that the project is very young and that the immediate focus is building out the core system and demos, and it warns that contributions which do not align with those goals may not be reviewed or merged in the near term. For an adopter, that means the upgrade path is your own problem: there is no backward compatibility guarantee, so pinning a commit and reading the diff before moving is the only realistic strategy.

The dependency surface adds to the cost. The go.mod requires Go 1.27.0 and pulls in Envoy control-plane packages, nftables, netlink, a PostgreSQL driver, goose migrations, and cloud SDKs for both AWS and Google Cloud. The Makefile builds control-plane images through ko against a KO_DOCKER_REPO, defaulting to gcr.io/$(PROJECT_ID)/ate-images. An upgrade therefore touches your Go toolchain, your container registry, your database migrations and your sandbox runtime, not just one binary.

Editorial conclusion

Adopt Agent Substrate if you are an infrastructure team running many mostly idle agent-like containers and you want to study actor-to-worker multiplexing on a throwaway kind cluster, using the counter demo as the entry point. Do not adopt it if you need a stable API, backward compatibility or production support: the README states it is not ready for production use and that the APIs are almost guaranteed to change, and the only release listed is v0.0.0 from 2026-05-19. Before committing any effort, verify that the Kubernetes version you run is the latest stable release or the previous minor release, which is the compatibility window the README claims, and confirm that the sandbox technology you need (microVM or gVisor) is among those the project supports.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes