O ecossistema de agentes de IA está evoluindo rapidamente. À medida que os agentes deixam de executar apenas tarefas curtas e passam a trabalhar por minutos, horas ou até dias, surge um problema que vai além do modelo de linguagem utilizado:

como executar, isolar, suspender, recuperar e escalar milhares de agentes de maneira eficiente?

Foi tentando entender melhor esse problema que comecei a estudar o Google AX.

O próprio projeto descreve o AX como um orquestrador declarativo para workloads agentic, executado sobre o Agent Substrate. A proposta lembra deliberadamente alguns conceitos do Kubernetes: declarar recursos, aplicar manifests, observar estado e deixar uma camada de controle reconciliar o ambiente.

Isso naturalmente levanta uma pergunta:

O Google AX seria uma espécie de “Kubernetes dos agentes de IA”?

Ainda é cedo para responder.

Por isso resolvi não começar pela teoria, mas por um laboratório.

Nesta primeira parte, o objetivo não é instalar todo o AX. Antes disso, quero entender a camada sobre a qual ele executa: Kubernetes + Agent Substrate.

E o primeiro experimento trouxe resultados bastante interessantes.

---

A arquitetura que estamos estudando

Uma forma simplificada de enxergar a arquitetura é:

Aplicação / Sistema Agentic
          │
          ▼
         AX
  Task / Workspace
  Gateway / Model
          │
          ▼
   Agent Substrate
 Actor / Worker / Snapshot
          │
          ▼
      Kubernetes
   Pod / Node / Network
          │
          ▼
    Infraestrutura

O Google AX adiciona abstrações voltadas especificamente para workloads agentic.

Atualmente, o projeto trabalha principalmente com quatro recursos declarativos:

• Task — workload agentic que será executado;
• Workspace — código, ferramentas, skills e demais recursos necessários à execução;
• Gateway — regras de comunicação e acesso externo;
• Model — configuração do modelo utilizado pelo ambiente.

O projeto também possui uma CLI deliberadamente semelhante ao kubectl, incluindo operações como apply, get, describe, watch, suspend e resume.

Mas existe uma camada importante entre o AX e o Kubernetes:

Agent Substrate.

E foi exatamente essa camada que resolvi estudar primeiro.

---

Preparando o laboratório

O ambiente utilizado neste experimento foi:

Ubuntu 26.04
Docker Desktop
16 CPUs disponíveis para Docker
~12 GiB de RAM para Docker

Go 1.27.1

Kind
Kubernetes 1.37.0

Google AX
commit e6211f8

Agent Substrate
commit 67253354

Fixar os commits foi proposital.

AX e Agent Substrate estão evoluindo rapidamente, e o próprio repositório do AX alerta que conceitos, protocolos e especificações ainda podem sofrer mudanças incompatíveis.

Para um experimento reprodutível, portanto, é importante registrar exatamente qual versão está sendo utilizada.

Também criei um KUBECONFIG isolado:

export KUBECONFIG=/mnt/dados/labs/ax-lab/kubeconfig

Isso evita que comandos do laboratório sejam executados acidentalmente contra outros clusters Kubernetes configurados na máquina.

---

Criando o Kubernetes com Kind

O próprio Agent Substrate fornece scripts para criação do ambiente Kind.

Executei:

cd /mnt/dados/labs/ax-lab/substrate
source ../env.sh

hack/create-kind-cluster.sh

O resultado foi um cluster:

kind-ax-lab

executando:

Kubernetes 1.37.0

com as APIs necessárias ao Substrate, incluindo:

ClusterTrustBundle
PodCertificateRequest

Como o host não disponibilizava /dev/kvm para o Docker, o suporte a microVM ficou desabilitado.

Isso não impediu o laboratório porque o Agent Substrate também suporta gVisor, que foi o sandbox utilizado neste primeiro experimento.

---

Instalando o Agent Substrate

Com o Kubernetes funcionando, o passo seguinte foi instalar somente a infraestrutura do Substrate:

hack/install-ate-kind.sh --deploy-ate-system

A instalação criou uma arquitetura consideravelmente maior do que um simples controller Kubernetes.

Entre os componentes ficaram:

ate-api-server
ate-controller
atelet
atenet-router
atenet-egress

PostgreSQL
RustFS

OpenTelemetry Collector
Prometheus
Jaeger

Pod Certificate Controller

Todos os principais componentes terminaram o rollout corretamente.

Também foram criados CRDs como:

csidriverconfigs.ate.dev
sandboxconfigs.ate.dev
workerpools.ate.dev

Um detalhe arquitetural chamou minha atenção imediatamente.

Não existem CRDs Kubernetes chamados:

Actor
Worker
ActorTemplate

Esses objetos pertencem ao control plane do Agent Substrate.

O WorkerPool, por outro lado, é um recurso Kubernetes.

Essa distinção começa a mostrar onde ocorre a separação entre a infraestrutura física de execução e o workload lógico agentic.

---

Criando os Workers

Para o primeiro teste utilizei o Counter Demo existente no próprio projeto:

hack/install-ate-kind.sh --deploy-demo-counter

O demo criou um WorkerPool com três réplicas:

DESIRED   REPLICAS   READY
3         3          3

e três Pods Kubernetes:

counter-...-2l9nl
counter-...-bwff8
counter-...-zdnnd

Do ponto de vista do Agent Substrate, cada Pod tornou-se um Worker:

Worker A   ACTORS 0/1
Worker B   ACTORS 0/1
Worker C   ACTORS 0/1

Nesse momento ainda não existia nenhum Actor de aplicação.

Isso já mostra uma diferença importante:

a capacidade de execução física pode existir antes do Actor.

---

Criando o primeiro Actor

Então criei:

kubectl ate create actor lab-counter-1 \
  -a ate-demo-counter \
  --template counter

O resultado foi:

lab-counter-1
ACTOR_STATE_SUSPENDED
WORKER POD <none>

Esse resultado é extremamente interessante.

Criar um Actor não criou um novo Pod.

Os três Pods já existentes continuaram exatamente como estavam.

O Actor surgiu como uma entidade lógica, inicialmente suspensa e sem capacidade física atribuída.

---

Ativação sob demanda

O acesso ao Actor ocorre através do atenet-router.

Criei um port-forward:

kubectl port-forward \
  -n ate-system \
  svc/atenet-router \
  8000:80

E então fiz a primeira requisição:

curl -X POST \
  -H "ate-target-actor: ate-demo-counter/lab-counter-1" \
  http://localhost:8000/

O Agent Substrate detectou que o Actor estava suspenso, escolheu um Worker disponível, restaurou o Actor e encaminhou a requisição.

Depois dessa operação:

lab-counter-1
ACTOR_STATE_RUNNING

e um Worker passou de:

ACTORS 0/1

para:

ACTORS 1/1
CPU    1/1
MEMORY 512Mi/1Gi

Nenhum Pod Kubernetes adicional foi criado.

---

Preservando estado

O Counter Demo possui dois contadores.

Um fica na memória do processo.

O outro fica em um arquivo.

As três primeiras requisições retornaram:

memory: 1   file: 1
memory: 2   file: 2
memory: 3   file: 3

Então suspendi o Actor:

kubectl ate suspend actor lab-counter-1 \
  -a ate-demo-counter

O resultado foi:

ACTOR_STATE_SUSPENDED
WORKER POD <none>

Ao mesmo tempo, os três Workers ficaram novamente disponíveis:

0/1
0/1
0/1

mas os três Pods Kubernetes continuaram executando normalmente.

O template utilizado no experimento estava configurado com:

SNAPSHOT_CONTENT_SCOPE_FULL

para onCommit e onPause.

Ou seja, o snapshot deveria preservar não apenas os arquivos, mas também o estado de execução.

---

O resultado mais interessante

Depois de suspender o Actor, fiz uma nova requisição HTTP.

O Agent Substrate restaurou o mesmo Actor.

Mas desta vez em outro Worker Pod.

E a resposta foi:

preserved memory count: 4
preserved file counter: 4

Depois de novos ciclos de suspend/resume, o mesmo Actor chegou a ser executado nos três Worker Pods diferentes existentes no laboratório.

Mesmo mudando de Pod:

Actor ID permaneceu igual
estado em memória permaneceu
estado em arquivo permaneceu

Em um dos últimos ciclos medi também o tempo percebido pelo cliente durante a ativação de um Actor suspenso:

HTTP:               200
time_starttransfer:  0.255009 s
time_total:          0.255087 s

A resposta retornou:

preserved memory count: 6
preserved file counter: 6

É importante não tratar esses aproximadamente 255 ms como um benchmark do Agent Substrate.

Foi uma única medição no meu ambiente local e incluiu todo o caminho:

curl
 → port-forward
 → atenet / Envoy
 → localização do Actor
 → restore
 → aplicação
 → resposta HTTP

Mas como prova funcional, o resultado é bastante interessante.

---

Actor não é Pod

Talvez a principal conclusão deste primeiro laboratório seja essa.

No Kubernetes normalmente pensamos em:

Application
   ↓
Pod

No Agent Substrate encontramos outra camada:

Actor
   ↓
atribuição dinâmica
   ↓
Worker
   ↓
Pod

Durante meu experimento, o mesmo:

lab-counter-1

Executou sequencialmente em Workers diferentes.

Quando suspenso:

Actor → Snapshot

e o Worker voltou a ficar disponível.

Quando chegou uma nova requisição:

Snapshot
   ↓
Actor
   ↓
Worker disponível

A identidade e o estado pertenciam ao Actor.

O Pod fornecia capacidade de execução.

Essa distinção é particularmente interessante para agentes de IA, que frequentemente passam grandes períodos aguardando:

• interação humana;
• resposta de ferramentas;
• eventos externos;
• novos prompts;
• aprovação;
• execução agendada.

Manter um Pod dedicado para cada agente durante todo esse tempo pode ser pouco eficiente.

O modelo Actor/Worker permite pensar em outra relação entre a quantidade de agentes registrados e a capacidade física simultaneamente disponível.

---

E onde entra o Google AX?

Esse é exatamente o próximo passo do laboratório.

Até aqui testamos:

Kubernetes
      ↓
Agent Substrate
      ↓
Actor

Agora quero adicionar:

AX
      ↓
Task
Workspace
Gateway
Model
      ↓
Agent Substrate
      ↓
Actor
      ↓
Worker
      ↓
Pod

O próprio projeto AX apresenta-se como uma camada declarativa de orquestração de workloads agentic sobre o Agent Substrate.

Então a pergunta continua aberta:

Google AX é realmente uma espécie de Kubernetes para agentes de IA?

O primeiro laboratório ainda não responde a isso.

Mas já revelou algo importante:

Por baixo do AX existe um runtime que trata agentes como entidades stateful cujo lifecycle pode ser desacoplado dos Pods Kubernetes que os executam.

Na próxima parte quero instalar efetivamente o AX e investigar o que acontece quando passamos de:

Actor

para:

Task + Workspace + Gateway + Model

A partir daí poderemos começar a responder a pergunta com arquitetura e experimentação — e não apenas por analogia.

---

Referências

Google AX — repositório oficial.

Google Cloud — Introducing Agent Executor, Google’s distributed Agent Runtime.

Agent Substrate — documentação e Counter Demo.

Este artigo faz parte de uma série prática sobre arquitetura para sistemas agentic, Agent Substrate, Google AX e workloads de IA stateful.