O Kubernetes dominou a era dos contêineres. O Google está apostando que a era dos agentes precisa de outra coisa: em maio de 2026, ele anunciou a disponibilidade geral do GKE Agent Sandbox e revelou o Agent Substrate, um projeto construído sobre uma conclusão que os veteranos do Kubernetes evitavam admitir publicamente — a plataforma que venceu nos contêineres está arquiteturalmente errada como control plane para agentes de IA.
Não é uma lacuna de funcionalidades. É uma incompatibilidade fundamental.
Onde o Pensamento de Contêineres do Kubernetes Falha
O Kubernetes nasceu em 2014 para gerenciar um conjunto fixo de serviços replicados e de longa duração. Um Deployment com três réplicas, cada uma rodando de forma estável, tráfego balanceado por um Service, HPA escalando por utilização de CPU — esse modelo calçava perfeitamente nos microsserviços.
Agentes não são microsserviços. Imagine um agente como um processo de sistema operacional. Um SO moderno executa milhares de processos que ficam dormindo na maior parte do tempo: ele os desperta em eventos, entrega uma fatia de CPU, pagina a memória ociosa deles para o disco para abrir espaço para o próximo. Agentes se encaixam nisso quase exatamente:
-
Um agente de codificação, aberto a tarde toda, roda por 10 segundos quando um prompt chega e espera 20 minutos pelo próximo.
-
Multiplicado por uma equipe, isso se torna milhares de sessões nominalmente “ativas” que na verdade estão adormecidas.
-
Cada sessão precisa de uma identidade estável e da capacidade de pausar e retomar sem perder a memória.
-
O código que ele executa é gerado por um LLM em tempo de execução — o host deve, por padrão, tratá-lo como não confiável.
O Kubernetes fixa um pod completo para cada sessão ociosa, desperdiçando a memória e a CPU reservadas do pod. Pior: seu API server e seu scheduler centralizados assumem que as decisões de agendamento são pouco frequentes e duradouras. Agentes despedaçam essa premissa com um fluxo contínuo de eventos de granularidade fina, e o próprio control plane vira o gargalo.
Três Características Essenciais dos Agentes como Cargas de Trabalho
Característica um: sessões que dormem por horas. Serviços web queimam CPU enquanto as requisições fluem; sessões de agentes quase não consomem nada entre prompts. Fixar um pod completo por sessão ociosa é pagar por algo para não fazer nada. Runtimes de nova geração removem o estado da sessão ociosa do compute — tirando snapshots da RAM volátil e do sistema de arquivos enquanto ela dorme e restaurando-os em segundos ao acordar. Esse é o mecanismo de paginação de memória virtual do SO, aplicado a agentes.
Característica dois: código que a plataforma não pode predefinir. Como o LLM escreve o código em tempo de execução, o host não pode assumir comportamento benigno. A fronteira de isolamento, portanto, se move da borda do contêiner para a borda do kernel — contêineres comuns compartilham o kernel do host e confiam na carga de trabalho; sandboxes de agentes devem assumir intenção hostil.
Característica três: estado que precisa sobreviver à dormência. Um agente que perde seu contexto toda vez que é suspenso é inútil. Memória de trabalho, sistema de arquivos, histórico de chamadas de ferramentas — tudo precisa persistir durante o sono e retornar exatamente ao acordar. Isso vai além do que o Kubernetes projeta nativamente.
A Arquitetura de Três Camadas
A resposta do Google não é uma plataforma substituindo outra, mas um control plane construído sob medida em camadas sobre o Kubernetes:
Camada 1 — Agent Sandbox, a camada de isolamento de segurança. Um ambiente de execução open-source sobre Kubernetes que dá a cada agente um espaço endurecido para código gerado por LLM. Onde contêineres normais compartilham o kernel do host, o Sandbox usa por padrão isolamento em nível de kernel via gVisor, além de política de rede default-deny. Destaques de design: um warm pool de réplicas pré-configuradas (o Google reporta 300 alocações de sandbox por segundo por cluster, 90% delas em até 200 milissegundos) e snapshots de pods que suspendem agentes ociosos e liberam seu compute, em vez de cobrar você por um sono ligado à memória. A adoção cresceu cerca de 16× em menos de cinco meses; LangChain e Lovable executam milhões de agentes sobre ele.
Camada 2 — Agent Substrate, a camada de agendamento e runtime. Se o Sandbox é a cadeia, o Substrate é o despachante. Ele reutiliza o runtime endurecido e os snapshots do Sandbox, combinando-os com um pequeno control plane ao lado do cluster Kubernetes que tira o control plane padrão do caminho crítico. A ideia central é o overcommit de memória virtual aplicado ao compute: sobrepor um registro de muitos agentes com estado a um pequeno pool de pods worker aquecidos, persistindo snapshots dos ociosos. Dados do projeto: como os pods worker já estão em execução quando os eventos chegam e nunca esperam pelo scheduler do Kubernetes, ele alcança over subscription de 30× ou mais com ativação em menos de um segundo. É agnóstico de framework — ADK, LangChain, Claude Code, ou qualquer contêiner OCI — e expõe dois recursos personalizados para desenvolvedores: WorkerPool (define o compute pronto) e ActorTemplate (define o agente).
Camada 3 — Kubernetes, a camada de gerenciamento de recursos. O Substrate não é um substituto do K8s; ele ainda usa pods e autoscaling para provisionamento e coloca seu scheduler em camada acima. O Kubernetes gerencia máquinas; o Substrate gerencia agentes. Como o próprio blog do Google afirma: o Kubernetes padrão é otimizado para milhares de serviços de longa duração, enquanto o Agent Substrate foi construído para o ruído de milhões de chamadas de ferramentas com menos de um segundo que afogariam um control plane padrão.
O Nascimento de um Quarto Paradigma de Computação
Os hyperscalers já estão se posicionando para isso: runtimes de agentes com consciência de sessão e isolados estão emergindo como o quarto paradigma de computação, depois de máquinas virtuais, contêineres e serverless. A lógica subjacente tem três níveis de profundidade.
Primeiro, agentes são processos, não serviços — a mudança cognitiva raiz. Serviços são “sempre ligados, esperando requisições”; processos são “acordam sob demanda, dormem quando ociosos”. O Kubernetes foi projetado para serviços, não para processos. A própria documentação do Substrate diz com todas as letras: não há jeito inteligente de fazer tantos objetos passarem por um control plane padrão.
Segundo, o custo ocioso está se tornando uma linha real de orçamento. À medida que o número de agentes vai de dígitos únicos para dezenas de milhares e milhões, fixar pods em sessões dormentes se torna inaceitável. O overcommit estilo memória virtual comprime o custo de um agente ocioso rumo a zero.
Terceiro, a questão do ecossistema: um control plane ou vários? O Substrate é recente e experimental. A Solo.io o integrou ao kagent com uma UI unificada. Mas a pergunta em aberto é quem dono da camada de control plane para agentes. Cenário otimista: o campo converge para um único projeto open-source, como a orquestração convergiu para o Kubernetes. Cenário realista: cada hyperscaler lança o seu — e a fragmentação da qual os agentes deveriam escapar simplesmente reaparece uma camada acima.
O Que as Equipes de Engenharia Deveriam Perguntar Agora
1. Sua arquitetura de agentes tem “pensamento de processo” ou “pensamento de serviço”? Se você ainda implanta agentes como Deployments-plus-Services com um pod de longa duração cada, o custo ocioso dispara rápido ao passar de algumas centenas de agentes. Introduza snapshots de sessão e restauração sob demanda cedo.
2. O isolamento de segurança é padrão de fábrica? A filosofia do Agent Sandbox é “assuma que o agente é hostil”. Se o seu runtime trata o isolamento como um adicional para implantações de alta segurança, inverta essa ordem.
3. Observe para onde o ecossistema de runtimes de agentes converge. Agent Substrate, AWS Bedrock AgentCore, Azure AI Foundry Agent Service, LangGraph Platform, Agyn — o mercado de runtimes de agentes em 2026 está tão lotado quanto a orquestração de contêineres estava em 2015. A história diz que essa camada se consolida. A pergunta que vale acompanhar: o Agent Substrate, com seu ecossistema aberto e o suporte do Google, se tornará o Kubernetes da era dos agentes?
O Kubernetes continua sendo um excelente scheduler de datacenter e segue insubstituível para provisionar as máquinas por baixo. Mas para cargas de trabalho moldadas como enxames vastos de processos dormentes, ele não é o scheduler certo. O Agent Substrate foi construído exatamente para elas.
Referências: The New Stack: Kubernetes won the container decade. Google’s Agent Substrate wants the next one. | Google Cloud Blog: Agent Sandbox on GKE is now available
