Em maio de 2026, a Google fez duas coisas no Cloud Next: levou o GKE Agent Sandbox à disponibilidade geral e revelou um projeto chamado Agent Substrate. Juntos, os anúncios admitiram o que os veteranos do Kubernetes há muito relutavam em dizer em público — a plataforma que dominou a era dos contêineres não foi construída para ser o control plane de agentes de IA.
Isso não é uma feature que falta. É uma incompatibilidade arquitetural fundamental, e ela se resume a três problemas concretos.
Por Que Kubernetes e Agentes Não Combinam
A forma mais clara de enxergar isso: um agente se comporta como um processo em um sistema operacional, não como um serviço em um datacenter. Um sistema operacional moderno executa milhares de processos, a maioria deles dormentes. Ele os acorda mediante eventos, concede uma fração de CPU, pagina a memória ociosa para o disco para abrir espaço para o próximo. Os agentes se comportam quase exatamente assim — enquanto o Kubernetes foi projetado para gerenciar um conjunto fixo de réplicas de longa duração. Essa incompatibilidade explica por que a infraestrutura de agentes hoje roda sobre o Kubernetes, em vez de dentro dele como um workload de primeira classe.
-
O workload é fundamentalmente diferente. Agentes são sessões stateful e de longa vida que passam a maior parte do tempo ociosas, acordam para executar uma rajada de código e voltam a dormir. Esse código é gerado por um LLM em tempo de execução, então o host precisa tratá-lo como não confiável por padrão.
-
O padrão de consumo é diferente. Um agente de codificação fica aberto a tarde inteira, roda por 10 segundos quando um prompt chega e espera 20 minutos pelo próximo. Multiplique pela equipe e você terá milhares de sessões nominalmente ativas que, na verdade, estão dormindo.
-
A granularidade de agendamento é diferente. Agentes geram um fluxo contínuo de eventos de agendamento de granularidade fina, quebrando a premissa por trás de um scheduler construído para um número moderado de pods de longa duração.
O Que Cada Projeto Realmente Resolve
Os dois projetos da Google não são concorrentes — são camadas com funções distintas.
Agent Sandbox: a cela de segurança
O Agent Sandbox responde à questão do isolamento. É um ambiente de execução open-source construído sobre Kubernetes que dá a cada agente um espaço endurecido para executar código gerado por LLM — pense numa cela, não num contêiner comum. Contêineres regulares compartilham o kernel do host e confiam no workload; o Sandbox assume que o workload é hostil e desenha a fronteira de acordo.
-
Isolamento de kernel por padrão via gVisor, com interfaces plugáveis para trocar por Kata Containers e obter isolamento completo de kernel.
-
Warm pools vencem cold starts: cada cluster aloca 300 sandboxes por segundo, 90% delas em até 200 milissegundos.
-
Snapshots de pods suspendem sessões ociosas, liberando computação para você parar de pagar por agentes dormindo.
-
Política de rede default-deny vem como baseline, sob a premissa de que qualquer agente pode executar algo que não deveria.
A adoção cresceu cerca de 16× em menos de cinco meses, razão pela qual a Google o levou à disponibilidade total. A LangChain e a Lovable executam milhões de agentes nele.
Agent Substrate: um runtime para milhões de agentes ociosos
Se o Sandbox é a cela, o Agent Substrate é o scheduler que decide qual agente roda onde. Ele reutiliza o runtime endurecido e a maquinaria de snapshots do Sandbox e os combina com um pequeno control plane que fica ao lado do cluster Kubernetes — tirando o control plane padrão do caminho crítico.
O design toma emprestado diretamente o manual do overcommit da memória virtual: agentes são processos, warm pools correspondem a um conjunto de núcleos de CPU, e snapshots de sessões ociosas são páginas trocadas para o disco. O Substrate sobrepõe um registro de muitos agentes stateful a um pequeno pool de pods workers já aquecidos. Como os pods workers já estão em execução quando os eventos chegam — nunca esperando o scheduler do Kubernetes —, o projeto relata oversubscription de 30× ou mais com ativação em menos de um segundo.
Também é independente de framework: ADK, LangChain, Claude Code ou qualquer contêiner OCI pode ser o executor.
O Runtime de Agentes Como Quarto Paradigma da Computação
Dando um passo atrás, runtimes de agentes com consciência de sessão e isolamento estão se consolidando como o quarto paradigma da computação, depois de máquinas virtuais, contêineres e serverless:
| Paradigma | Abstração central | Granularidade de agendamento | Isolamento | Exemplos típicos |
|---|---|---|---|---|
| Máquinas virtuais | SO completo | Minutos | Nível de hardware | VMware, EC2 |
| Contêineres | Grupos de processos | Segundos | Nível de kernel (cgroups) | Docker, Kubernetes |
| Serverless | Funções | Milissegundos | Nível de runtime | Lambda, Cloud Functions |
| Runtimes de agentes | Sessões stateful | Sub-segundo + dormência | Nível de kernel (gVisor/Firecracker) | Agent Substrate, E2B |
O que torna o runtime de agentes único é que ele precisa lidar com dois extremos ao mesmo tempo — longa dormência e rajadas súbitas —, uma combinação que nenhum dos três paradigmas anteriores jamais precisou enfrentar.
O Que Essa Mudança Significa
O Kubernetes segue como infraestrutura, mas perde o control plane
O Kubernetes continua cuidando de pods e autoscaling por baixo, mas a lógica que governa o agendamento de agentes está sendo elevada. Isso não é substituição — é camadas. O Kubernetes faz o que faz bem (nós); o Agent Substrate faz o que faz bem (ciclos de vida de agentes).
A infraestrutura de agentes está se consolidando rápido
AWS, Google Cloud, Azure e Cloudflare agora oferecem designs de sandbox para agentes, e divergem na implementação: a Cloudflare usa isolamento de contêineres mais isolates V8, a E2B usa microVMs Firecracker, a Google usa gVisor. O campo enfrenta a mesma questão de convergência das guerras de orquestração — um runtime de agentes open-source dominará como o Kubernetes dominou?
Para desenvolvedores: de implantar serviços a gerenciar sessões
Quando agentes se tornarem computação mainstream, as perguntas mudam de “como faço deploy de um serviço” para “como gerencio os ciclos de sono e despertar de um milhão de sessões stateful” — o que exige novas ferramentas de monitoramento, logging, debugging e gestão de custos. A Solo.io já integrou o Substrate ao kagent, com uma UI unificada de gerenciamento.
O Que Você Pode Fazer
-
Equipes de plataforma: acompanhe o progresso open-source do Agent Substrate e modele o custo de um runtime de agentes. Além de um certo escala de deploy, o agendamento nativo do Kubernetes deixa de ser suficiente.
-
Desenvolvedores de aplicações de IA: interiorize o modelo mental — agentes são processos, não serviços. Não force o comportamento de agentes nos primitives do Kubernetes; use uma oferta existente de Agent Sandbox.
-
Arquitetos: observe onde os runtimes de agentes convergem. É cedo, mas quando um padrão se formar, todo o stack de infraestrutura de aplicações de IA se reorganiza.
O Agent Substrate da Google é uma exploração inicial, não um produto acabado. Mas seu design já aponta o caminho: um agente não é um serviço — é um processo. Quando a camada de infraestrutura absorver totalmente essa ideia, os agentes finalmente poderão escalar de verdade.
O Kubernetes dominou a década dos contêineres. A próxima pertence aos agentes — e os agentes precisam do próprio runtime.
Referências: The New Stack / Google Cloud Blog / InfoQ
