Agent Substrate vs Agent Sandbox: análise das mudanças no GKE para agentes

Um Pod por agente não escala. Na documentação oficial do Google Kubernetes Engine (abre em nova aba) (GKE), essa restrição física define a recomendação arquitetural imediata para engenharia de plataforma: equipes que operam agentes de IA devem adotar o Agent Substrate como padrão para a maioria das cargas de trabalho, restringindo o uso do Agent Sandbox aos casos em que cada agente exige um Pod (a menor unidade de implantação do Kubernetes) dedicado, acesso direto a GPUs ou TPUs, uma especificação PodSpec completa ou execução em clusters GKE Autopilot.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​‌‌​​​​‌​‌‌​​​‌​​​‌‌​‌​​​‌‌​​​‌​​​‌‌​‌​‌​​‌‌​‌​​​​‌‌​​‌​​​‌‌​‌​​​​‌​‌‌​‌​​‌‌​‌‌‌​​‌‌​​​‌​‌‌​​​‌‌​‌‌​​‌‌​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​​‌‌​​‌‌​​​​​​‌‌​‌‌‌​​‌​‌‌​‌​‌‌​​​​‌​‌‌​​‌‌​​​‌‌‌​​​​‌‌​​‌​​​​‌​‌‌​‌​​‌‌​‌‌​​‌‌​​​‌‌​​‌‌‌​​‌​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌‌​​​‌‌​​​‌​​‌‌​‌‌‌​​‌‌​‌‌‌​​‌‌​‌​‌​​‌‌​​‌‌​‌‌​​‌‌​⁠

Essa divisão reflete uma incompatibilidade estrutural entre o comportamento de agentes autônomos e o design original do Kubernetes (abre em nova aba), consolidado ao longo de uma década para orquestrar microsserviços contínuos.

O gargalo do plano de controle e o desperdício por ociosidade

Um assistente de programação gera um script em shell, executa o código para testar uma hipótese e para. Enquanto o usuário lê a resposta ou o modelo de linguagem processa o próximo passo, o ambiente de execução aguarda sem processar nada, mas mantém memória e estruturas de rede alocadas.

Em publicação no Google Open Source Blog em novembro de 2026, os engenheiros Yu Liao, Haowei Cai e Federico Bongiovanni, da equipe de engenharia do Google Cloud e do grupo SIG API Machinery, apontam que cargas de trabalho de agentes com estado (stateful) impõem dois gargalos que o Kubernetes padrão não foi construído para suportar: desperdício de recursos ociosos e sobrecarga do plano de controle (control plane, a camada central que agenda contêineres e gerencia o estado do cluster).

Na documentação técnica do Agent Substrate no GKE, o Google detalha a mecânica dessa limitação. Implantações tradicionais do Kubernetes associam cada agente ativo a um Pod dedicado. Mesmo em clusters grandes, essa relação de um para um trava na taxa de transferência de agendamento (scheduling throughput) da API do Kubernetes e na latência de inicialização de cada Pod. O orquestrador padrão também não possui suporte nativo para hibernação de Pods; manter milhares ou milhões de agentes ociosos aguardando interação humana drena a capacidade computacional que deveria servir cargas ativas.

O problema de escala vem acompanhado de uma falha de fronteira de segurança. Em artigo no Google Cloud Blog publicado em 10 de novembro de 2026, o Cloud Developer Advocate Abdelfettah Sghiouar descreve o risco de operar frotas multi-tenant (clusters compartilhados por múltiplos clientes ou equipes): quando agentes executam scripts e comandos shell gerados dinamicamente por modelos de linguagem, esse código deve ser tratado como não confiável. Rodar instruções arbitrárias em contêineres comuns, que compartilham o mesmo kernel do sistema operacional do nó hospedeiro, expõe o cluster a escapes de sandbox (quando um processo rompe o isolamento do contêiner e invade a máquina subjacente) e à escalação de privilégios.

Da criação do Agent Sandbox à doação do Agent Substrate

A tentativa do Google de resolver o isolamento e a latência de inicialização aconteceu em duas etapas distintas, separadas por um ano de operação em produção.

No anúncio feito durante a KubeCon North America em novembro de 2025, assinado pelo gerente de produto sênior Brandon Royal no Google Cloud Blog, a empresa apresentou o Agent Sandbox. Desenvolvido em conjunto com a comunidade no grupo Kubernetes SIG Apps, o componente foi desenhado como uma primitiva para execução de código e uso de computador (computer use) por agentes. Para contornar a lentidão na criação de ambientes isolados do zero, o Agent Sandbox permitiu que administradores configurassem pools pré-aquecidos (pre-warmed pools) de sandboxes. Segundo os números declarados pelo Google Cloud nesse lançamento, o uso de pools pré-aquecidos entrega latência inferior a um segundo para cargas de agentes isoladas, o que representa uma redução de até 90% no tempo de espera em relação às inicializações a frio (cold starts). Trata-se de uma métrica de fornecedor associada ao recurso de pré-aquecimento, sem publicação de testes independentes nas fontes consultadas.

Faltava resolver a densidade por máquina.

Na KubeCon North America de novembro de 2026, realizada em Salt Lake City, o Google Cloud deu o passo seguinte ao doar o projeto Agent Substrate e o runtime de isolamento gVisor (abre em nova aba) para a Cloud Native Computing Foundation (abre em nova aba) (CNCF) na categoria Sandbox, conforme reportado pelo SiliconANGLE e confirmado no blog de código aberto da empresa.

Segundo a documentação oficial da ferramenta no GKE, o Agent Substrate foi construído sobre a base do Agent Sandbox, mas altera o caminho crítico de execução ao contornar os gargalos do plano de controle padrão do Kubernetes. A arquitetura permite que a aplicação suspenda agentes ociosos de forma direta, liberando CPU e memória imediatamente para processos ativos. Com a remoção da obrigatoriedade de acionar o ciclo completo de agendamento de um Pod dedicado para cada instância, o Google afirma que o sistema consegue sustentar de dezenas a milhões de agentes concorrentes distribuídos em um número limitado de máquinas, iniciando sessões mais rápido e com maior densidade por nó do que o Agent Sandbox isolado.

Comparativo arquitetural: Agent Substrate vs. Agent Sandbox

Ambas as soluções continuam ativas na documentação do GKE, mas atendem a requisitos de infraestrutura diferentes. Enquanto o Agent Substrate foca em alta densidade e suspensão rápida fora do caminho crítico do agendador padrão, o Agent Sandbox preserva a semântica completa de um Pod tradicional do Kubernetes para cargas que não podem abrir mão dela.

Na documentação do Agent Sandbox no GKE, a arquitetura exige a instalação do controlador Agent Sandbox controller no cluster e opera em conjunto com o Sandbox Router, um componente de rede responsável por fornecer um endpoint estável e realizar o tunelamento de tráfego até os Pods que executam os agentes. Um limite operacional explícito na documentação é que o Agent Sandbox não detecta agentes ociosos por conta própria; cabe inteiramente à camada de aplicação monitorar a inatividade e decidir quando acionar a suspensão.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​‌‌​​​​‌​‌‌​​​‌​​​‌‌​‌​​​‌‌​​​‌​​​‌‌​‌​‌​​‌‌​‌​​​​‌‌​​‌​​​‌‌​‌​​​​‌​‌‌​‌​​‌‌​‌‌‌​​‌‌​​​‌​‌‌​​​‌‌​‌‌​​‌‌​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​​‌‌​​‌‌​​​​​​‌‌​‌‌‌​​‌​‌‌​‌​‌‌​​​​‌​‌‌​​‌‌​​​‌‌‌​​​​‌‌​​‌​​​​‌​‌‌​‌​​‌‌​‌‌​​‌‌​​​‌‌​​‌‌‌​​‌​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌‌​​​‌‌​​​‌​​‌‌​‌‌‌​​‌‌​‌‌‌​​‌‌​‌​‌​​‌‌​​‌‌​‌‌​​‌‌​⁠

Isolamento de execução: gVisor versus microVMs e Kata Containers

Para impedir que comandos gerados por LLMs comprometam o nó do cluster, as adaptações do GKE substituem o compartilhamento direto do kernel Linux por camadas adicionais de contenção. A documentação técnica do Agent Sandbox detalha o suporte a duas abordagens principais de isolamento em nível de kernel: o uso do gVisor (via GKE Sandbox gerenciado) e o uso de microVMs (máquinas virtuais ultraleves) ou Kata Containers (tecnologia que empacota contêineres dentro de máquinas virtuais dedicadas).

A escolha entre um kernel em espaço de usuário e a virtualização assistida por hardware costuma dividir equipes de segurança, mas no GKE essa decisão esbarra em uma restrição funcional direta documentada pelo Google.

O gVisor funciona interceptando as chamadas de sistema (syscalls) da aplicação e processando-as em um kernel próprio escrito em Go que roda em espaço de usuário, sem repassar a execução diretamente ao kernel Linux do hospedeiro. Por operar como um processo controlado sobre o sistema otimizado para contêineres do GKE, o Google consegue serializar o estado desse processo para gerar snapshots de Pod e escalar horizontalmente com menor sobrecarga de memória.

As microVMs e o Kata Containers isolam o código não confiável por meio de um hipervisor leve que fornece um kernel convidado separado para cada instância. Essa abordagem atende a requisitos estritos de isolamento por virtualização de hardware em ambientes de desenvolvimento persistentes ou execução de binários específicos, mas sacrifica a capacidade de utilizar snapshots de Pod no GKE, forçando a arquitetura a depender exclusivamente de pools pré-aquecidos ou inicializações completas.

O restante da pilha AI-native: cache de inferência, RL e cliente Python

A execução isolada do código resolve apenas uma metade do ciclo de vida de um agente; a outra metade depende da velocidade das chamadas ao modelo de linguagem e da comunicação com a própria API do cluster. Na arquitetura unificada apresentada pelo Google Cloud em novembro de 2026, o suporte a agentes no GKE é complementado por quatro ajustes no ecossistema de código aberto:

• Roteamento de inferência com llm-d 1.0: Agentes operam em múltiplos turnos (multi-turn), enviando o histórico da conversa e o resultado da execução de ferramentas de volta ao modelo a cada passo. Segundo dados do Google Cloud Blog compilados pelo Tech Bytes em novembro de 2026, o componente llm-d 1.0 introduziu pools conscientes de cache de prefixo (PrefixCacheAware pool) e descarregamento de cache (KV offload), o que dobrou a taxa de acerto do KV-cache (memória que armazena cálculos intermediários de atenção do modelo para evitar reprocessamento de tokens repetidos) de 35% para 70% em cargas de trabalho de agentes multi-turno. Assim como nos dados de latência do Sandbox, o número reflete medições divulgadas pelo próprio Google Cloud.
• Pós-treinamento com OpenRL: Doado à CNCF como projeto Sandbox em novembro de 2026, o serviço nativo de Kubernetes gerencia etapas de pós-treinamento baseadas em aprendizado por reforço (Reinforcement Learning), frequentemente usadas para ensinar agentes a escrever código e usar ferramentas, buscando maximizar a taxa de ocupação dos aceleradores.
• Processamento distribuído com KubeRay e Kueue: A pilha integra o framework Ray no GKE por meio do operador KubeRay (também na CNCF Sandbox) combinado ao agendamento de filas do Kueue (abre em nova aba), permitindo escalonamento elástico e controle de cotas para processamento de dados e computação distribuída.
• Modernização do cliente oficial Python do Kubernetes: Como a maior parte dos frameworks de orquestração de agentes e aprendizado de máquina é escrita em Python, engenheiros do Google Cloud passaram a atuar junto ao grupo Kubernetes SIG API Machinery para atualizar o cliente oficial da linguagem, reduzindo gargalos de comunicação programática entre aplicações de IA e o servidor de API do cluster.

Para equipes de engenharia que já operam no GKE, a divisão entre Agent Substrate e Agent Sandbox elimina a necessidade de manter frotas paralelas de máquinas virtuais fora do Kubernetes apenas para isolar scripts gerados por modelos, desde que a arquitetura respeite o limite entre cargas de alta densidade em CPU e cargas que exigem Pods dedicados com aceleradores.⁠​‌​​‌​​‌​‌​​​​​‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌​​‌​‌‌‌​​‌‌​​​‌​​‌‌‌​​‌​​‌‌‌‌‌​​​‌‌​​​​‌​‌‌​​​‌​​​‌‌​‌​​​‌‌​​​‌​​​‌‌​‌​‌​​‌‌​‌​​​​‌‌​​‌​​​‌‌​‌​​​​‌​‌‌​‌​​‌‌​‌‌‌​​‌‌​​​‌​‌‌​​​‌‌​‌‌​​‌‌​​​‌​‌‌​‌​​‌‌​‌​​​​‌‌​​‌‌​​‌‌​​​​​​‌‌​‌‌‌​​‌​‌‌​‌​‌‌​​​​‌​‌‌​​‌‌​​​‌‌‌​​​​‌‌​​‌​​​​‌​‌‌​‌​​‌‌​‌‌​​‌‌​​​‌‌​​‌‌‌​​‌​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌‌​​​‌‌​​​‌​​‌‌​‌‌‌​​‌‌​‌‌‌​​‌‌​‌​‌​​‌‌​​‌‌​‌‌​​‌‌​⁠