O Agent Substrate do Google foi feito para frotas de agentes. Isso muda o que o time de plataforma assume

Até aqui, quase todo o trabalho com agentes nas empresas foi sobre construir um agente bem feito: o prompt, as ferramentas, a avaliação. O próximo problema é menos vistoso. O que acontece quando a empresa roda milhares de agentes, cada um executando código, a maioria parada a maior parte do tempo, e todos precisando ficar isolados do resto da infraestrutura?

A resposta do Google para Kubernetes é o GKE Agent Substrate, destacado no resumo de infraestrutura de IA de setembro. É um bom sinal de para onde o gargalo está indo: da inteligência do modelo para a execução segura e econômica.

O que o Agent Substrate faz

O Google descreve o Agent Substrate como um runtime open source para cargas de trabalho agênticas no GKE. O desenho parte de como os agentes se comportam de verdade. O anúncio anterior do Google resumiu bem: agentes rodam em rajadas curtas, ficam ociosos por longos períodos e precisam de isolamento forte de kernel e de rede, porque executam código que ninguém revisou linha por linha.

Em vez de manter um contêiner vivo por agente, o Agent Substrate separa o estado do agente dos pods. Agentes suspensos ficam guardados como snapshots e são retomados sob demanda em um pool compartilhado de workers já aquecidos. A memória de trabalho e os arquivos são preservados, e o agente continua de onde parou.

Os números do Google são ambiciosos: segundo a empresa, o Agent Substrate roda milhões de sandboxes com densidade 10 vezes maior do que runtimes de contêiner comuns, com retomadas abaixo de 500 milissegundos a mais de 500 ativações de suspensão e retomada por segundo. O isolamento usa gVisor, com Cloud Hypervisor como opção.

1. Chamada para um agente
2. Snapshot restaurado em um worker aquecido
3. Trabalho roda em sandbox isolado
4. Agente suspenso em snapshot
5. Worker volta ao pool

Fronteira de isolamento para código gerado por IAMemória e arquivos do agente em repouso: dados a classificar e proteger

Leia o status com atenção

A documentação é mais precisa do que a manchete. O Agent Substrate está disponível para todos os clientes do Google Cloud para avaliação e uso fora de produção; o suporte em produção é oferecido a uma lista de clientes aprovados, em um programa de GA privado. Ele roda só em clusters GKE Standard, não no Autopilot, e exige Workload Identity Federation.

A documentação também lista limitações que pesam no desenho enterprise: sem passthrough de GPU, conexões de rede abertas não são preservadas na suspensão e na retomada, e políticas de egress não são suportadas. O Google diz que não há cobrança adicional no GKE.

O irmão do projeto, o GKE Agent Sandbox, está em disponibilidade geral, e o Google lançou em setembro uma versão otimizada para aprendizado por reforço.

O que muda para o time de plataforma

Um runtime gerenciado pelo fornecedor do modelo, como a Agents API da OpenAI, esconde a execução atrás de uma API. O Agent Substrate é a escolha oposta: a execução fica nos seus clusters, e o seu time de plataforma é o dono dela. Isso traz controle, e uma lista de decisões.

Isolamento é o ponto de partida, não o desenho. Um sandbox gVisor protege o host do código gerado pela IA. Ele não decide o que esse código pode alcançar. Como as políticas de egress ainda não são suportadas, os controles de rede precisam vir de outra camada da arquitetura antes que qualquer coisa sensível rode ali.

Snapshot é dado. Se a memória e os arquivos do agente são preservados entre execuções, o storage de snapshots guarda tudo aquilo em que o agente estava trabalhando: dados de clientes, credenciais, resultados intermediários. Classificação, criptografia, retenção e acesso a esse storage precisam de um responsável, como qualquer banco de dados.

Identidade por agente continua sendo sua. A documentação exige Workload Identity Federation para o sistema, mas não descreve um modelo de identidade por agente. Se milhares de agentes compartilham uma conta de serviço, a trilha de auditoria não consegue diferenciá-los.

Ociosidade é o novo vetor de custo. A conta de uma frota de agentes depende de quanto você paga por agentes esperando. Suspensão e retomada são uma alavanca de custo, e o planejamento de capacidade vira uma conversa conjunta entre plataforma e FinOps.

O que isso significa no Brasil

Para quem tem dados de clientes brasileiros, o ponto mais concreto é o storage dos snapshots. Ele guarda o estado dos agentes, e esse estado pode incluir dados pessoais. Se você avaliar o Agent Substrate, confira o suporte por região e mantenha o bucket dos snapshots na mesma jurisdição dos dados que os agentes tratam, por exemplo na região de São Paulo. Isso evita transformar um detalhe de infraestrutura em transferência internacional de dados sob a LGPD.

Para a maioria das empresas brasileiras, frotas de milhares de agentes ainda não são realidade. Mas as perguntas valem desde já para qualquer agente que execute código: onde fica o estado, o que o código pode alcançar e quem responde por cada agente.

O que fazer agora

1. Avalie em um projeto fora de produção, como a documentação prevê, com dados sintéticos.
2. Desenhe os controles de egress de rede primeiro, já que o runtime não aplica essas políticas.
3. Trate o bucket de snapshots como armazenamento sensível: chaves de criptografia, retenção e revisão de acessos.
4. Defina o modelo de identidade antes que o número de agentes cresça: uma identidade por agente ou por tipo de agente, nunca uma para todos.
5. Meça a ociosidade dos seus agentes atuais para estimar quanto a densidade economizaria de fato.

Em resumo

O Agent Substrate é infraestrutura para um estágio que a maioria das empresas ainda não alcançou: frotas de agentes, não pilotos. Mas as perguntas que ele levanta já valem hoje. São os mesmos controles que mapeamos no nosso guia do stack de 2026. Os times de plataforma que respondê-las cedo serão os que vão conseguir escalar.