Scaling Agent Workloads on Kubernetes (Coming Soon)

Preview — this solution is in development. What follows is the problem it addresses and the shape of the answer. There is no deployment guide yet.

‍

One agent is a deployment. A platform full of them is a different problem.Every team needs somewhere to run the agent, an identity for it to use, anda controlled way for it to reach models and tools — and none of that isstandard, so each team builds its own. Give agents a substrate instead:scheduled, scaled and isolated like any other workload, with the gatewayalready in front of them.

‍

Agents are idle most of the time. Pods are not.

Kubernetes was built for services that are up because traffic is arriving. An agent is not that. It waits for a person, or another agent, or a schedule, thinks for thirty seconds, calls a few tools, and goes quiet again for an hour. Between those bursts it holds a pod, and the pod holds a CPU request and a memory reservation whether or not anything is happening inside it.

‍

Eight agents either way: eight pods, or two workers and an object store.

‍

‍

‍

What runs where

The unit of scheduling stops being a pod and becomes an actor, which changes what sits between the agent and everything else. kagent is where the agent is declared, whether it is Langchain, CrewAI, ADK or a harness. Agent Substrate places it on a warm worker and suspends it when it goes quiet. agentgateway carries every call it makes outward. Each actor gets its own gVisor or Firecracker sandbox, so packing several onto a worker does not mean sharing a kernel between teams.

‍

Diagram of Kubernetes agent deploying actors in worker pods, interacting with LLM providers, MCP servers, and other agents.
Solution Architecture – Scaling Agent Workloads on Kubernetes (Coming Soon)

‍

‍

What lands next

A preview of this solution is in development. It will follow the same shape as the others: a Solution Brief, and a Deployment Guide with every command run on a live cluster.

‍

‍

‍

‍

‍