Rodar um agente de IA num notebook é fácil. Sustentá-lo em produção por horas, ou até dias, é outra história. O Google acabou de abrir o código do Agent Executor, um runtime pensado justamente para esse cenário. E, sinceramente, ele resolve dores que todo time de engenharia de agentes já conhece bem.

Por que um agente do Google que cai no meio do caminho custa caro

Primeiro, vamos ao problema real. Fluxos de trabalho com agentes podem durar muito tempo. Além disso, eles dependem de chamadas externas, aprovações humanas e conexões que nem sempre são estáveis.

Quando um agente roda por horas, qualquer falha vira um pesadelo. Você perde contexto. Você perde estado. Consequentemente, precisa reiniciar tudo do zero. O Google apontou que a execução prolongada exige a capacidade de retomar o trabalho após interrupções, falhas ou checkpoints com intervenção humana.

E os números mostram que isso não é detalhe. Segundo o relatório “State of Agent Engineering 2026”, da LangChain, 57,3% dos entrevistados já tinham agentes rodando em produção. Outros 30,4% estavam desenvolvendo agentes com planos claros de implantação. Ou seja, a maioria do mercado já enfrenta esses desafios todos os dias.

Como o Google Agent Executor retoma o trabalho de onde parou

Aqui mora a parte mais interessante. O runtime usa um registro de eventos combinado com snapshots para reconstruir o estado de um fluxo. Dessa forma, quando algo quebra, o agente não recomeça do início. Ele volta exatamente do ponto em que parou.

Esse mecanismo também cobre os checkpoints com intervenção humana. Portanto, se o seu fluxo precisa de uma aprovação manual no meio do caminho, o estado fica preservado enquanto você espera.

Além disso, o Agent Executor lida com desconexões de cliente. Imagine um usuário que perde a conexão durante uma tarefa longa. Quando ele reconecta, o runtime entrega as respostas a partir da última sequência que ele viu. Nada se perde.

Trajectory branching: teste caminhos sem quebrar o fluxo

Há ainda um recurso que vai agradar quem testa muito. Trata-se do trajectory branching, ou ramificação de trajetória. Em vez de rodar o fluxo inteiro de novo, você usa checkpoints para explorar caminhos diferentes.

Na prática, o agente ramifica a partir de um checkpoint anterior. Enquanto isso, o contexto e o estado daquele ponto continuam intactos. Para quem itera muito em prompts e estratégias de decisão, isso economiza tempo e recursos.

Segurança em ambientes multi-tenant não é opcional

Agora, falemos de um ponto delicado. Agentes geram código. Agentes manipulam dados de usuários. E, muitas vezes, fazem isso em ambientes compartilhados por vários clientes.

O Agent Executor traz isolamento por meio de componentes em sandbox. O objetivo é claro: limitar efeitos colaterais e reduzir o risco de atividades maliciosas afetarem o serviço inteiro. O Google citou geração de código e gestão de dados em ambientes multi-tenant como casos típicos.

A documentação do GKE descreve o Agent Sandbox como uma peça feita para rodar código não confiável gerado por LLM. Ele oferece isolamento em nível de kernel via GKE Sandbox e também funciona com contêineres Kata. Além disso, adota uma postura de rede do tipo “negar por padrão”.

Na prática, essa política bloqueia o acesso de código não confiável a redes internas não autorizadas. Ela também bloqueia o acesso ao plano de controle do GKE. Em outras palavras, o que roda dentro do sandbox fica contido ali.

Um único escritor para evitar conflito de estado

O runtime ainda usa uma arquitetura de escritor único para gerenciar o estado da sessão compartilhada. O motivo é simples. Quando vários componentes de um fluxo distribuído tentam alterar a mesma sessão ao mesmo tempo, surgem conflitos. Essa arquitetura limita justamente esse tipo de atualização concorrente.

Google sem prisão: o runtime conversa com a sua stack

Talvez você esteja pensando que isso prende você ao ecossistema do Google. No entanto, o projeto vai no sentido oposto. Ele é agnóstico em relação a frameworks de agentes.

Você pode conectá-lo a vários modelos de implantação. Entre eles estão o Google Antigravity, agentes nativos como o Deep Research e agentes personalizados via API Managed Agents in Gemini. Contudo, ele também roda com LangChain, LangGraph e o Agent Development Kit do Google.

O suporte ao protocolo Agent2Agent é o que costura tudo isso. Por causa dele, o runtime opera entre frameworks e ambientes de implantação distintos. Assim, você não fica refém de uma escolha tecnológica única.

E tem mais. O Agent Executor pode rodar em infraestrutura autogerenciada. Dessa forma, fluxos proprietários executam dentro dos seus próprios ambientes de computação e sandboxes. Você também pode rodar MCPs, skills e outros agentes no seu plano de dados.

Google Agent Substrate: o Kubernetes que entende agentes

O Google não parou no runtime. No entanto, a empresa também anunciou o Agent Substrate, um projeto irmão criado junto com o time do GKE. Ele adiciona uma camada focada em agentes por cima do Kubernetes.

Mas por que uma camada nova? Porque cargas de trabalho de agentes se comportam de um jeito peculiar. Elas costumam ter picos curtos de atividade seguidos por longos períodos de ociosidade. O Kubernetes tradicional, por sua vez, foi pensado para milhares de serviços de longa duração.

A diferença de escala é gritante. Enquanto isso, agentes podem disparar milhões de chamadas de ferramentas de curta duração. Para lidar com esse padrão, o Agent Substrate move agentes para dentro e para fora da capacidade computacional em tempo real. Ele faz isso com um plano de controle mais enxuto.

O GKE Agent Sandbox ainda se integra aos Pod Snapshots. Por conta disso, cargas ociosas podem ser suspensas e retomadas em segundos. Nada de manter recursos parados queimando orçamento.

Os números de alocação que chamam atenção

Os dados de performance ajudam a entender a ambição do projeto. Segundo o Google, o pool de instâncias ativas do GKE Agent Sandbox aloca até 300 sandboxes por segundo, por cluster. Além disso, 90% dessas alocações terminam em 200 milissegundos.

Esse pool existe por um motivo específico. Ele reduz a latência de cold start quando o sistema precisa de novas instâncias de sandbox. Portanto, o usuário final não fica esperando o ambiente subir.

Por fim, o Agent Substrate combina runtime seguro, snapshots, agendamento via Kubernetes e escalonamento horizontal. O Google afirmou que o plano de controle foi desenhado para lidar com centenas de milhões de agentes registrados. E tudo isso continua dentro do ecossistema Kubernetes que você já conhece.

O que isso significa para o seu próximo projeto

No fim das contas, o recado é direto. Colocar agentes em produção deixou de ser improviso. Ferramentas como o Agent Executor e o Agent Substrate tratam confiabilidade, segurança e escala como requisitos de primeira classe.

Se você já tem agentes rodando, vale testar como a retomada por snapshots se encaixa no seu fluxo. E, se ainda está na fase de protótipo, talvez seja a hora de pensar em produção desde o começo. Afinal, o ferramental agora existe e está aberto para a comunidade.

Acompanhe nosso perfil no Instagram!