What Is Agent Substrate? The Runtime Behind kagent

Understanding the Technology Behind kagent — Part 1

A few days ago, I wrote about kagent 1.x.

While writing that article, I realized something interesting.

Most of us focus on kagent because it’s the tool we interact with. We define agents, configure models, assign tools, and deploy them. But very few people stop to ask:

What actually runs these agents behind the scenes?

The answer is Agent Substrate.

It isn’t another AI framework, and it isn’t just another Kubernetes operator. It is the runtime that powers projects like kagent.

This article is the first part of a new series where we’ll explore Agent Substrate from the ground up. Rather than jumping straight into installation or configuration, we’ll understand why it was created and the core ideas behind it.

Why Kubernetes Alone Wasn’t Enough

Kubernetes was created at Google and open-sourced over a decade ago to solve the challenge of running containerized applications at scale. The Pod became the standard unit of deployment for modern cloud-native applications.

For years, that model worked extremely well. Then AI agents arrived.

Unlike a traditional web application, an AI agent doesn’t simply receive a request and return a response. It thinks, calls tools, executes code, talks to other services, waits for language model responses, and sometimes waits for a human to approve something before continuing.

That creates a very different execution pattern. Google’s own write-up notes that agents spend roughly 90–95% of their time just waiting. If every agent gets its own dedicated Pod, all that waiting time still holds on to reserved CPU and memory. And when a Pod has scaled to zero, bringing an agent back through a cold start can take 20+ seconds.

Agents need:

• secure, isolated execution for untrusted, model-generated code
• efficient resource sharing
• persistent state
• the ability to pause and resume without losing context

Google Cloud introduced Agent Substrate to address exactly these needs.

From Google to the CNCF

Agent Substrate isn’t meant to be a Google-only solution. In November 2026, around KubeCon North America, Google Cloud announced it is donating Agent Substrate and gVisor to the Cloud Native Computing Foundation (CNCF) at Sandbox status, alongside OpenRL. The project is open source on GitHub (agent-substrate/substrate), and it has reached 1.0.

This matters. Kubernetes became successful because it was developed in the open under neutral governance. Moving Substrate to the CNCF follows the same path for agent infrastructure, letting cloud providers, vendors and the wider community shape it together.

So, What Exactly Is Agent Substrate?

At a high level, Agent Substrate is a Kubernetes-native runtime for sandboxed, stateful AI agents. Think of it as the execution layer between your agent platform and Kubernetes.

Each layer has a different responsibility:

• kagent defines what an agent is and how it should behave.
• Agent Substrate manages how that agent executes.
• Kubernetes provides the underlying compute, networking and storage.

This separation lets platform teams focus on building useful agents while Substrate handles the hard parts of running them efficiently and safely.

More Than Just Another Operator

At first glance, Substrate might look like a typical Kubernetes operator. It isn’t. It does ship Kubernetes custom resources and a controller, but it also brings its own runtime model: an API server, a networking layer, per-node agents, and sandboxed workers. Google describes it as an actor-based control and data plane built on top of Kubernetes, and it runs on standard Kubernetes (Pods, autoscaling, NetworkPolicies).

Get Isuru Wimalasiri’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The core concepts you will meet throughout this series:

• Actor: one isolated agent instance with its own state
• ActorTemplate: the blueprint that defines an actor’s configuration and lifecycle
• Worker: a pre-warmed Pod that hosts actors
• WorkerPool: the pool of Workers that actors are scheduled onto
• Snapshot: a compressed checkpoint of an actor’s state in object storage, which makes suspend and fast resume possible
• Session: the context that tracks an actor’s activity and checkpoints

A quick note on precision: only WorkerPool and ActorTemplate are Kubernetes custom resources. The others are runtime concepts. And in the kagent 1.x docs, a Session simply means a running conversation with an agent, not a Kubernetes resource.

The Numbers (and a Caveat)

When an agent needs to run again, Substrate restores its state from a snapshot onto an available warm Worker.

• resume in under 500 milliseconds, compared to 20+ seconds for a cold start
• more than 500 activations per second
• up to 10x the density of standard container runtimes

These are vendor-reported figures, and the density gain depends on most actors being suspended at any given time. Treat them as design targets to validate in your own environment, not guarantees.

For isolation, every actor runs inside a dedicated sandbox: gVisor (runsc) or a Cloud Hypervisor microVM. Plain Linux containers are not supported. That’s why gVisor gets its own article next.

What’s Coming Next?

• Part 1: What is Agent Substrate? (this article)
• Part 2: Understanding gVisor — the sandbox behind Agent Substrate
• Part 3: Actors — the fundamental execution unit
• Part 4: Workers and WorkerPools
• Part 5: Snapshots, Suspend and Resume
• Part 6: The Agent Substrate control plane
• Part 7: How kagent uses Agent Substrate

Final Thoughts

When I first started exploring kagent, I thought it was simply another Kubernetes-native AI framework. The deeper I went, the more I realized that the real innovation wasn’t only in kagent. It was in the runtime underneath it.

Agent Substrate is a new way of thinking about how AI agents should execute, scale, and interact with Kubernetes. Understanding that foundation makes every other component in the ecosystem easier to understand.

In the next article, we’ll look at gVisor: why secure sandboxing matters for AI agents, and how it fits into Substrate’s architecture.

Sources

• Google Open Source Blog: Sandboxing Untrusted AI Agents at Scale (Nov 2026) — https://opensource.googleblog.com/2026/11/sandboxing-untrusted-ai-agents-at-scale.html
• Google Cloud: Open infrastructure for autonomous agents comes to CNCF — https://cloud.google.com/blog/products/containers-kubernetes/open-infrastructure-for-autonomous-agents-comes-to-cncf
• Agent Substrate on GitHub — https://github.com/agent-substrate/substrate
• kagent docs: Agent Substrate — https://kagent.dev/docs/kagent/0.x/concepts/agent-substrate/