O agente dorme.
O servidor continua
pagando.

O tempo ocioso também tem uma fatura

Um agente escreve código, chama uma ferramenta e espera. Depois aguarda o modelo, uma resposta de rede ou a revisão de uma pessoa. Se cada sessão conserva um contêiner ativo durante esses intervalos, CPU e memória continuam reservadas para um processo que, naquele momento, não faz trabalho. Em uma sessão isso parece pequeno. Em milhares de sessões longas, vira uma decisão de infraestrutura.

Em 15 de setembro, o Google Cloud apresentou o Agent Substrate no GKE. O projeto aberto procura executar muitos ambientes isolados, chamados actors, sobre um conjunto menor de workers prontos. Quando um actor fica inativo, seu estado pode ser preservado em um snapshot; quando chega outra requisição, ele recebe um worker e retoma a execução. Kubernetes administra as máquinas e os pods de trabalho. Uma camada própria administra a troca rápida entre sessões.

A proposta não é fazer o modelo pensar melhor. É parar de pagar computação ativa durante a espera sem perder o estado necessário para continuar. É uma distinção importante: o lançamento fala de capacidade operacional, não de inteligência do agente.

O que realmente acorda um agente

No desenho publicado, um ActorTemplate define a imagem, a configuração e os recursos de uma sessão. O sistema cria um snapshot inicial e registra cada actor num plano de controle. Quando uma requisição chega ao roteador, ele consulta onde está o actor. Se estiver suspenso, o escalonador escolhe um worker aquecido; o supervisor do nó restaura memória e arquivos; só então o pedido é encaminhado ao processo, por um túnel autenticado.

Há dois custos escondidos nessa frase. Primeiro, guardar estado exige escrever e ler snapshots, inclusive quando o agente migra entre nós. Segundo, manter workers aquecidos consome recursos mesmo quando nenhum actor está rodando. O sistema troca a reserva permanente de uma sessão por um pool compartilhado, armazenamento e coordenação. A troca só compensa quando os agentes passam tempo suficiente parados e acordam com uma frequência que o pool consegue absorver.

O repositório ainda distingue pausa local de suspensão durável. Uma pausa pode manter o estado preso ao nó; a suspensão externa grava o snapshot para que o actor retorne em outro worker. Essa diferença afeta recuperação, latência e custo. Não existe um único número de “tempo para acordar” que represente todos os caminhos.

Dez vezes mais denso, sob quais condições?

O Google anuncia retomada em menos de 500 milissegundos, mais de 500 ativações por segundo e densidade dez vezes maior que a de contêineres tradicionais. Também fala em mais de mil agentes adormecidos por host. São números do fornecedor. O material público não estabelece, para o leitor, uma comparação independente com a mesma carga, tamanho de snapshot, duração de sessão, padrão de chamadas e configuração de isolamento.

Um registro de mil actors dormindo ocupa muito menos que mil processos executando. Isso não significa que o host atenderá mil despertares simultâneos com a mesma latência. Se todos acordarem depois de uma falha, de um evento ou do retorno de uma API, o gargalo pode mudar para armazenamento, rede, workers aquecidos ou plano de controle. Densidade em repouso e capacidade de pico são métricas diferentes.

O isolamento também está no caminho crítico

Cada actor pode executar código que o operador não revisou. O projeto oferece gVisor como isolamento padrão no instalador do GKE; microVMs são outra opção, mas exigem configuração adicional. O gateway controla tráfego e pode fornecer credenciais fora do processo do agente. Isso é mais concreto que pedir ao modelo para não acessar uma chave.

Ainda assim, “seguro por padrão” não é um certificado de produção. O README do repositório chama o Agent Substrate de desenvolvimento inicial, sem garantia de compatibilidade, e diz que não está pronto para uso em produção. Seu modelo de ameaças registra hardening ainda incompleto. A documentação do Google esclarece a distribuição: avaliação e uso não produtivo estão abertos aos clientes; suporte para produção depende de uma lista privada de acesso. Essas afirmações descrevem escopos diferentes e precisam aparecer juntas.

O contraponto é que o sistema já entrega código, documentação e uma demonstração reproduzível. Não é só um desenho de palco. Também não é a única resposta possível: pods convencionais são mais simples quando poucas sessões ficam ociosas; runtimes gerenciados como o AgentCore oferecem outra combinação de isolamento, persistência, duração e custo. Não há comparação pública que autorize declarar um vencedor universal.

O teste que importa para engenharia

Eu começaria com sessões sintéticas e sem dados sensíveis. Rodaria a mesma tarefa em pods convencionais e no Agent Substrate, variando duração da espera, tamanho do workspace e taxa de retomadas simultâneas. Registraria p50, p95 e p99 de ativação, CPU e RAM ocupadas, bytes gravados por snapshot, custo de armazenamento e tempo de recuperação depois da perda de um nó. Separadamente, testaria se uma sessão consegue acessar rede, arquivos ou credenciais de outra.

O Korvo não executou esse experimento. Até que alguém publique resultados comparáveis, o número de dez vezes serve para formular uma hipótese, não para projetar uma fatura. O padrão de arquitetura, porém, já é útil: separar a identidade e o estado do agente da máquina que o executa, manter capacidade compartilhada e fazer a espera devolver recursos.

Um agente não deixa de custar quando dorme. A engenharia decide qual parte da infraestrutura pode dormir com ele e quanto custa acordá-la sem perder controle.