Google doa Agent Substrate, gVisor e OpenRL à CNCF para dar infraestrutura aberta a agentes autônomos
Aprofundamento CEVIU
Aprofundamento
O problema que o Google descreve é de operação, não de modelo. Um agente roda código por alguns segundos e depois espera: resposta do modelo, API externa ou input humano. No Kubernetes padrão, manter um Pod por agente ativo prende memória e CPU nessas pausas, enche o control plane de objetos persistentes e amarra a identidade ao Pod. O Agent Substrate separa as peças: Actors guardam memória, arquivos e identidade; Workers são sandboxes reutilizáveis de um pool warm; Gateways aplicam controle de acesso de entrada e saída e injetam secrets conforme a identidade do Actor, deixando as chaves fora do ambiente do agente.
Quando o agente pausa, o Substrate faz snapshot para storage e devolve o Worker ao pool. Na próxima requisição, restaura em menos de 500 milissegundos. Segundo o Google, o 1.0 sustenta milhões de sandboxes com 10x a densidade de runtimes de container e mais de 500 ativações de suspend/resume por segundo. A camada de isolamento é escolha sua: microVMs Cloud Hypervisor ou gVisor, um kernel de aplicação em Go que trata as syscalls em userspace, sem exigir virtualização aninhada. O OpenRL completa o stack com loops de post-training com RL em Python puro no Kubernetes, usando Dynamic Resource Allocation (DRA), PyTorch/AutoModel, vLLM e integração com o llm-d. Ele nasceu como research preview em fevereiro e ainda não tem suporte a TPU (está no roadmap). Os três projetos estão no CNCF Sandbox, e o gVisor caminha para Incubation.
O que mudou
Em 17 de setembro de 2026, o CEVIU noticiou "Google Cloud Lança Agent Substrate para Potencializar Agentes de IA no GKE", quando o runtime foi apresentado no GKE. Agora ele chega ao marco 1.0, em disponibilidade geral como Agent Substrate on GKE, e o código vai para a governança neutra da CNCF. Em 22 de outubro de 2026, o CEVIU cobriu o Agent Compute Engine, serviço de microVM por agente; o Google posiciona o Substrate como complemento para quem prefere um serviço de microVM via API sem gerenciar clusters. Já em 12 de junho de 2026, a matéria "Agent Substrate habilita agentes de IA no Kubernetes com kagent" mostrava a colaboração com a Solo.io, e o Google agora cita o kagent como projeto CNCF que já roda sobre o Substrate. Em 4 de abril de 2026, o CEVIU registrou a aceitação do llm-d no CNCF Sandbox, e o llm-d reaparece aqui como par do OpenRL.
Por que isso importa
Para quem opera plataforma, a leitura é que o custo de agentes ociosos deixa de ser um problema de Pod por agente. Se o snapshot e restore funcionar como descrito, a conta de memória e CPU parada cai e o control plane respira. A governança na CNCF reduz o risco de amarração a um fornecedor, e a promessa de rodar em qualquer cluster merece teste no seu ambiente. Os números (10x de densidade, 500 ms) vêm do Google, então vale validar com sua carga antes de planejar capacidade.
Linha do tempo
CEVIU noticia a aceitação do llm-d como projeto Sandbox da CNCF.
Google apresenta o Agent Executor, runtime distribuído para agentes de IA.
Solo.io e Google colaboram no Agent Substrate com o kagent.
Google Cloud lança o Agent Substrate no GKE.
Google Cloud apresenta o Agent Compute Engine, com microVM por agente.
Google doa Agent Substrate, gVisor e OpenRL à CNCF e o Substrate chega ao 1.0 com disponibilidade geral no GKE.
Perguntas frequentes
O que é o Agent Substrate e o que ele resolve?
É um runtime open source que separa o estado do agente (memória, arquivos, identidade) do compute ativo. Agentes ociosos viram snapshot em storage e voltam em menos de 500 ms. Isso evita prender um Pod inteiro durante as pausas.
Preciso usar o GKE para rodar o Agent Substrate?
Não. O Google oferece o Agent Substrate on GKE como capacidade gerenciada, mas o código aberto pode ser implantado em qualquer cluster Kubernetes, em qualquer nuvem, com CPUs, GPUs ou TPUs.
Por que usar gVisor em vez de containers comuns para agentes?
Containers comuns compartilham o kernel Linux do host, o que é arriscado para código gerado e não revisado. O gVisor intercepta as syscalls em userspace e mantém densidade de container, sem exigir virtualização aninhada.
O OpenRL já está pronto para produção?
O próprio Google o chama de a camada mais nova do stack. Começou como research preview em fevereiro e entra na CNCF cedo, de propósito, antes de o design se consolidar. O suporte a TPU ainda está no roadmap.
Fontes
- cloud.google.comfonte original
- Categoria
- CEVIU DevOps
- Publicado
- 05 de novembro de 2026
- Editoria
- CEVIU DevOps

