O projeto Agent Substrate do Google é melhor compreendido por meio de uma única analogia, e a própria documentação de arquitetura do Google a exprime com precisão: trate os agentes como processos em um sistema operacional, não como serviços em um datacenter. Todo o resto do projeto — os warm pools, os snapshots, a sobrescrição de 30× — decorre dessa reformulação.
Se você rodou agentes de IA em produção no último ano, provavelmente já sentiu isso: algo no Kubernetes simplesmente não encaixa. Não porque ele seja ruim — o Kubernetes é o sistema de agendamento mais bem-sucedido da era cloud-native. O problema é mais simples: agentes não são microsserviços.
O desencontro, em um ciclo de vida
A vida de uma sessão de agente é assim: chega um prompt, ele roda por 10 segundos e depois espera 20 minutos pelo próximo evento. Multiplique pelos desenvolvedores de um time e você tem milhares de sessões nominalmente “ativas” que, na verdade, estão dormentes. O API server e o scheduler do Kubernetes foram projetados para serviços de longa duração com contagem fixa de réplicas. Quando agentes chegam aos milhões, suspendendo e retomando constantemente, o control plane deixa de ser uma camada de arbitragem e vira o gargalo.
Na Cloud Next ‘26, em maio de 2026, o Google levou o GKE Agent Sandbox à disponibilidade geral e apresentou o projeto Agent Substrate — dois anúncios que admitiram, discretamente, o que veteranos do Kubernetes relutavam em dizer em voz alta: a plataforma que dominou a era dos containers não é o control plane certo para agentes de IA.
Agente como processo: a separação dimensão por dimensão
| Dimensão | Serviço tradicional (força do K8s) | Agente de IA (fraqueza do K8s) |
|---|---|---|
| Ciclo de vida | Longa duração, sempre ativo | Intermitente, majoritariamente ocioso |
| Estado | Stateless / armazenamento externo | Fortemente stateful, contexto de sessão |
| Granularidade de agendamento | Agendamento de pods em escala de minutos | Despertares de eventos em escala de milissegundos |
| Requisito de isolamento | Fronteira de container | Fronteira de kernel (código não confiável) |
| Escala | Milhares de pods | Milhões de sessões |
Essas diferenças explicam por que a infraestrutura de agentes hoje roda majoritariamente sobre o Kubernetes, e não dentro dele como um tipo nativo de workload, à maneira de Deployments e StatefulSets.
A resposta em três camadas do Google
Camada 1: Agent Sandbox — isolamento seguro
O Agent Sandbox é um ambiente de execução open source construído sobre o Kubernetes que dá a cada agente um espaço endurecido para rodar. Sua premissa de base é que qualquer agente pode executar algo que não deveria:
-
Isolamento de kernel por padrão via gVisor, com política de rede default-deny — configuração de fábrica, não um complemento de segurança.
-
Warm pools: cada cluster pode alocar 300 sandboxes por segundo, 90% delas em até 200 milissegundos — o problema de cold start resolvido com capacidade pré-aquecida.
-
Snapshots de pods: agentes ociosos são suspensos em snapshots e se recuperam em segundos, liberando a computação por baixo.
Clientes como LangChain e Lovable já rodam milhões de agentes sobre ele.
Camada 2: Agent Substrate — agendamento em hiperscala
Resolvido o isolamento, resta o problema mais difícil: agendar milhões de sessões ociosas. O movimento central do Substrate é aplicar o mecanismo de overcommit da memória virtual ao agendamento de computação. Um sistema operacional permite que programas acessem muito mais memória do que existe fisicamente, paginando páginas frias para o disco; o Substrate sobrepõe um registro de muitos agentes stateful a um pequeno pool de worker pods quentes, persistindo snapshots das sessões ociosas. Os números reportados: sobrescrição de 30× ou melhor, com ativação em menos de um segundo.
O Substrate não substitui o Kubernetes. Ele usa pods e autoscaling para provisionamento e, sobre isso, adiciona seu próprio scheduler para as decisões específicas de agentes para as quais o K8s nunca foi projetado.
Camada 3: Kubernetes — gerenciamento de recursos por baixo
O Kubernetes continua gerenciando os nós. A decisão arquitetural é sobre qual camada possui qual função. Na prática, times que rodam agentes de código em escala isolam o código em sandboxes, agendam via Substrate e deixam o Kubernetes provisionar os nós por baixo de ambos.
O control plane de agentes vai convergir?
Quando o Kubernetes se tornou open source em 2014, a orquestração de containers era um campo concorrido — Mesos, Swarm, Nomad — e o K8s venceu de forma categórica. O Substrate agora está numa posição semelhante, com argumentos reais dos dois lados do balanço.
O caso otimista: o pedigree do Google — Tim Hockin, um dos principais contribuidores do Kubernetes, está diretamente envolvido no design do Substrate; o projeto nasceu open source no GitHub, convidando a comunidade para co-design exatamente como o K8s fez; é agnóstico de framework, rodando ADK, LangChain, Claude Code ou qualquer container OCI sem se vincular ao ecossistema do Google; e o kagent, da Solo.io, já o adotou como runtime opcional com uma UI unificada.
O caso pessimista: o campo competitivo está ainda mais concorrido — AWS, Azure e Cloudflare têm seus próprios designs de sandbox para agentes, e a fragmentação do ecossistema pode simplesmente migrar uma camada acima. A infraestrutura de agentes ainda evolui rápido (as assinaturas do Kimi K3 derreteram seus servidores em menos de 48 horas, mostrando a demanda superando a oferta — hardly um ambiente onde padrões se solidificam). E a confiança da comunidade open source em código gerado por IA permanece em aberto — as recentes restrições a contribuições geradas por IA no GCC e no kernel Linux são um lembrete.
O caminho mais provável: o Substrate provavelmente não se tornará um monarca único como o K8s foi. Mais plausivelmente, ele catalisará uma camada de interface padronizada para o “control plane de agentes” — definindo abstrações como Session e Snapshot assim como o Kubernetes definiu Pod e Service — enquanto as clouds competem na qualidade da implementação por baixo.
O que isso significa para quem constrói
-
Adote o modelo de processos. Pare de implantar agentes como microsserviços. Gerenciamento de estado de sessão, recuperação de recursos ociosos e despertares em menos de um segundo agora são métricas arquiteturais centrais, não itens desejáveis.
-
Acompanhe o projeto. O Agent Substrate está aberto no GitHub (github.com/agent-substrate/substrate) — o design da sua API e as discussões da comunidade são os sinais iniciais que valem a pena observar.
-
Mantenha o Kubernetes, reposicione-o. Ele continua sendo um excelente gerenciador de recursos de baixo nível; a camada de agendamento de agentes cresce acima dele. Times de plataforma já deveriam estar rascunhando sua estratégia de camadas de infraestrutura de agentes.
-
Observe a economia de densidade. O desperdício de sessões ociosas está se tornando uma linha de custo que times de plataforma não podem ignorar. O número de 30× de sobrescrição aponta para a fórmula vencedora: quem empacotar mais sessões com densidade, sem sacrificar a latência, ganha.
A infraestrutura da era dos agentes passa por uma mudança de paradigma: de containers para processos. O Kubernetes dominou a década dos containers — mas a votação para o control plane da próxima década acabou de começar.
Referências: The New Stack | Google Cloud Blog
