Google AX: o Kubernetes dos agentes de IA? Parte 2 — Tasks, estado, Workspaces e execução real sobre o Agent Substrate

Na primeira parte desta série, montei um laboratório local com Kubernetes, Google AX e Agent Substrate para entender uma pergunta aparentemente simples:

Google AX pode ser considerado uma espécie de Kubernetes para agentes de IA?

A resposta começou a aparecer logo no primeiro laboratório.

AX não substitui Kubernetes. Ele adiciona uma camada declarativa voltada a workloads agentic, enquanto o Agent Substrate introduz abstrações como Actors, Workers, snapshots e mecanismos de suspend/resume sobre a infraestrutura do Kubernetes.

Nesta segunda parte, fui além da instalação.

O objetivo foi colocar essas abstrações sob carga experimental:

• criar Tasks reais;
• observar a relação entre Task, Actor, Worker e Pod;
• suspender e retomar execução;
• preservar estado;
• migrar Actors entre Workers;
• testar Gateway e egress;
• utilizar Workspaces persistentes;
• conectar um LLM local;
• e, finalmente, executar um workload de IA utilizando dados reais.

O resultado revelou não apenas capacidades interessantes, mas também algumas diferenças importantes entre o modelo declarativo da plataforma e o comportamento observado na implementação utilizada no laboratório.

Baseline do laboratório

Para tornar os resultados reproduzíveis, trabalhei com versões fixadas.

AX:

e6211f84a9e30dd309304167b8f1d51cbdaf8dab

Agent Substrate:

672533541dbfcd29084e4de2475267088bda3651

Kubernetes:

v1.37.0

O laboratório foi executado sobre Kind, com Workers utilizando gVisor.

Essa informação é particularmente importante porque AX e Agent Substrate ainda estão em rápida evolução. O próprio projeto AX alerta que seus conceitos, protocolos e especificações continuam sendo refinados e podem sofrer breaking changes antes de uma versão estável.

Portanto, sempre que eu falar sobre um comportamento observado neste artigo, estou me referindo a essa baseline específica.

De Task para Actor

A documentação do AX define Task como a menor unidade isolada de execução.

Uma Task declara elementos como:

• imagem;
• comando;
• recursos;
• variáveis de ambiente;
• Workspaces;
• configuração de rede.

AX transforma essa intenção declarativa em recursos executáveis sobre o Agent Substrate.

No laboratório, a sequência ficou clara:

AX Task
   ↓
ActorTemplate
   ↓
Actor
   ↓
Worker
   ↓
Kubernetes Pod

Essa relação é importante porque um Actor não é simplesmente um nome alternativo para um Pod.

O Agent Substrate mantém Actors como unidades lógicas de execução que podem ser suspensas e posteriormente retomadas em Workers diferentes. Os Workers, por sua vez, são implementados sobre Pods Kubernetes.

E foi exatamente isso que conseguimos observar.

Actor ≠ Pod

Em experimentos anteriores, criei um Actor com estado em memória e em filesystem.

Depois de múltiplos ciclos de suspend/resume, o mesmo Actor apareceu executando em diferentes Workers.

A identidade lógica permaneceu constante.

O Pod que o executava, não.

Isso levou a uma das conclusões centrais desta série:

No Agent Substrate, o Actor possui identidade, lifecycle e estado independentes do Worker Pod que momentaneamente o executa.

Esse é um afastamento importante da forma como normalmente pensamos sobre workloads no Kubernetes.

No Kubernetes tradicional, o Pod costuma ser a unidade central de execução.

No Agent Substrate, o Worker Pod funciona mais como uma capacidade computacional disponível para receber Actors.

Podemos pensar conceitualmente assim:

Actor = identidade lógica + lifecycle + estado

Worker = capacidade de execução disponível

Pod = infraestrutura Kubernetes que hospeda o Worker

Snapshot DATA e persistência do Workspace

O experimento seguinte investigou o estado persistente.

Criamos dois arquivos:

/workspace/lab2-persistence.txt
/tmp/lab2-ephemeral.txt

Depois suspendemos a Task.

O AX gerou um snapshot com:

SNAPSHOT_CONTENT_SCOPE_DATA

Após o resume, a Task voltou para outro Worker.

O resultado foi:

/workspace/lab2-persistence.txt    preservado
/tmp/lab2-ephemeral.txt           ausente

O comportamento mostrou uma distinção importante entre storage durável associado ao Actor e filesystem temporário da execução.

Mais tarde repetimos o mesmo experimento com um repositório Git completo.

O Actor estava inicialmente no Worker:

10.244.0.25

Depois do suspend/resume:

10.244.0.26

Mesmo assim:

Git HEAD:
7358c4e49fe8d45c04418aeefdf4ef46c90bb207

foi preservado.

Também criamos um arquivo com checksum SHA-256 antes da suspensão.

Depois do restore:

.lab2-workspace-persistence.txt: OK

Portanto:

Actor
   ↓
DATA snapshot
   ↓
suspend
   ↓
Worker liberado
   ↓
resume
   ↓
outro Worker
   ↓
Workspace restaurado

Esse foi um dos resultados mais fortes do laboratório.

Golden snapshot + estado específico do Actor

O ActorTemplate possuía também um golden snapshot FULL.

Ao retomar um Actor com snapshot DATA, o Substrate pôde combinar:

Golden snapshot
        +
Actor DATA

Conceitualmente:

Golden
  └── estado base da execução

Actor DATA
  └── estado durável específico daquela instância

Isso permitiu restaurar o ambiente de execução e, simultaneamente, recuperar o Workspace específico do Actor.

A arquitetura abre possibilidades interessantes para workloads agentic que passam longos períodos ociosos.

Em vez de manter cada agente permanentemente ativo em um Pod, o sistema pode preservar seu estado e reativá-lo quando necessário.

Essa é justamente uma das ideias centrais do Agent Substrate: multiplexar um conjunto potencialmente muito maior de Actors sobre um conjunto menor de Workers.

Gateway: intenção declarativa não é necessariamente enforcement

Outro experimento envolveu Gateway.

Declaramos uma allowlist permitindo apenas:

example.com:443

AX reconciliou corretamente a configuração e criou a EgressPolicy correspondente.

O tráfego também passou pelo dataplane autenticado do Agent Substrate.

Conseguimos observar a identidade do ator sendo utilizada no egress.

Porém, os testes mostraram que destinos fora da allowlist continuavam acessíveis.

Além disso, na baseline utilizada, o campo de porta presente na declaração AX não era propagado integralmente para a política resultante.

A conclusão precisa ser cuidadosa:

Na baseline utilizada, Gateway representou intenção declarativa de egress e participou do dataplane autenticado, mas não entregou enforcement de destino e porta equivalente ao que a API declarativa sugeria.

Esse é um exemplo importante de engenharia de plataforma:

API declarativa
       ≠
estado reconciliado
       ≠
enforcement efetivo

Essas três camadas precisam ser testadas separadamente.

O problema mais interessante: Workspace Git e readiness

O experimento com Workspace provavelmente revelou o achado arquitetural mais interessante do Lab 02.

A documentação atual descreve Workspace como uma abstração capaz de materializar repositórios Git e outras dependências antes de liberar a Task para execução.

Declaramos:

kind: Workspace

spec:
  git:
    - repo: https://github.com/gomesrocha/br-financial-ai.git
      branch: main

Esperávamos:

Actor inicia
   ↓
Git clone/fetch
   ↓
Workspace pronto
   ↓
readyz
   ↓
Task executa

Mas o que aconteceu foi diferente.

O Git falhou repetidamente com:

GnuTLS, handshake failed:
The TLS connection was non-properly terminated.

Inicialmente isso parecia um problema comum de TLS.

Não era.

Ao investigar o código da baseline do Agent Substrate, encontramos a sequência real:

preparar identidade/certificado
        ↓
configurar redirect de rede
        ↓
iniciar workload
        ↓
runner prepara Workspace
        ↓
aguardar /readyz
        ↓
ativar egress

O problema fica evidente:

Workspace Git precisa de rede
        ↓
readiness depende do Workspace
        ↓
egress depende do readiness

Ou, resumindo:

Workspace
   ↓
readyz
   ↓
egress
   ↓
Workspace

Um ciclo de bootstrap.

Antes da ativação do egress, o tráfego já era redirecionado para o túnel local, mas a ativação ainda não havia ocorrido.

A conexão era encerrada localmente.

Do ponto de vista do Git, isso aparecia como uma conexão TLS encerrada incorretamente.

Depois que o Actor finalmente chegava ao estado Ready, o mesmo:

git fetch

Executado manualmente, funcionava normalmente. A partir daí formulamos uma regra arquitetural simples:

Readiness pode depender de egress. Portanto, egress não pode depender do readiness.

WorkspaceReady=True, mas Workspace incompleto

Havia ainda outro problema.

Mesmo depois de falharem as tentativas de Git, o runner tratava aquela falha como não fatal.

Resultado:

WorkspaceReady=True
Ready=True
TaskRunning

mesmo sem o repositório estar materializado corretamente.

A command da Task também havia falhado.

Mesmo assim, a Task continuava aparecendo como Running.

Isso nos levou a outra distinção:

Task Running
     ≠
command executada com sucesso

WorkspaceReady
     ≠
Workspace semanticamente válido

E apareceu algo ainda mais sutil.

O ActorTemplate conseguiu produzir um golden snapshot daquele ambiente.

Ou seja:

snapshot tecnicamente válido
        ≠
estado semanticamente correto

Esse tipo de diferença é particularmente relevante em arquiteturas de agentes, pois checkpoints e snapshots podem preservar perfeitamente um estado já incorreto.

Corrigindo o Workspace depois do readiness

Para isolar o problema, mantivemos o mesmo Actor e materializamos o repositório somente depois que ele estava Ready.

Funcionou imediatamente.

O commit utilizado foi:

7358c4e49fe8d45c04418aeefdf4ef46c90bb207

Depois criamos evidências dentro do próprio Workspace, suspendemos a Task e produzimos um novo snapshot DATA.

Ao retomar:

Worker anterior: 10.244.0.25
Worker novo:     10.244.0.26

E mesmo assim:

HEAD preservado       ✅
arquivo preservado    ✅
SHA-256 preservado    ✅

Portanto, havia duas conclusões diferentes:

Materialização Git declarativa no bootstrap
❌ falhou nessa baseline

Persistência do Workspace depois de materializado
✅ funcionou

É importante não misturar as duas.

Um workload real de IA

Depois de validar Task, Actor, Workspace, snapshots e rede, faltava uma coisa.

Executar algo realmente útil.

Usei um projeto real de estudo:

br-financial-ai

O Actor leu o README.md diretamente do Workspace persistente e enviou um trecho de 6.000 caracteres para um servidor Ollama local utilizando:

host.docker.internal:11434

O caminho foi aproximadamente:

AX Task
   ↓
Actor
   ↓
gVisor
   ↓
atunnel
   ↓
egress autenticado
   ↓
Ollama
   ↓
LLM

A resposta foi então persistida novamente no /workspace.

Ou seja, não estávamos mais executando apenas um teste sintético.

Tínhamos:

dados reais
   ↓
Workspace persistente
   ↓
Actor isolado
   ↓
modelo de IA
   ↓
resultado persistido

Infraestrutura funcionando não significa IA funcionando bem

O primeiro modelo utilizado foi:

llama3.2:latest

Ele concluiu a inferência.

Tempo observado:

~23,96 segundos

A infraestrutura funcionou perfeitamente.

Porém, havia uma regra extremamente simples no prompt:

Liste exatamente três componentes.

O modelo retornou cinco.

Além disso, introduziu, na resposta, uma afirmação sobre “aprendizado de máquina” que não constava dos 6.000 caracteres fornecidos como contexto.

Portanto:

infraestrutura       PASS
inferência           PASS
persistência         PASS
instruction-following FAIL
grounding probe       FAIL

Essa talvez seja uma das lições mais importantes deste laboratório:

Sucesso operacional de um agente não implica sucesso semântico.

Llama 3.2 3B versus Llama 3.1 8B

Para verificar se o problema estava relacionado apenas à infraestrutura, mantivemos praticamente tudo constante:

• mesmo Actor;
• mesmo Workspace;
• mesmo commit;
• mesmos 6.000 caracteres;
• mesmo prompt;
• mesma temperatura;
• mesmo limite de geração;
• mesmo Ollama.

Mudamos o modelo.

Segundo teste:

llama3.1:latest

Resultado:

Llama 3.2 3B

tempo: ~23,96 s
componentes pedidos: 3
componentes retornados: 5
contrato: FAIL
grounding probe: FAIL

Contra:

Llama 3.1 8B

tempo: ~85,25 s
componentes pedidos: 3
componentes retornados: 3
contrato: PASS
grounding probe: PASS

Isso não demonstra que modelos maiores sejam sempre melhores.

Também não é um benchmark de desempenho entre Llama 3.1 e 3.2. Os estados de carregamento e as características dos modelos não eram idênticos. Mas demonstra algo arquiteturalmente relevante:

Mantendo a infraestrutura constante, mudar o modelo mudou materialmente o comportamento da aplicação.

Portanto, em sistemas agentic:

modelo

Não é apenas uma dependência externa.

Ele é parte da arquitetura, a escolha afeta:

• latência;
• consumo de recursos;
• instruction following;
• grounding;
• confiabilidade;
• custo;
• experiência do usuário.

Então AX é o Kubernetes dos agentes?

Depois destes dois laboratórios, minha resposta está ficando mais precisa.

Não considero correto afirmar que AX substitui Kubernetes.

Ele depende de Kubernetes.

Uma representação melhor seria:

Aplicação / Agente
        ↓
Framework agentic
        ↓
AX
        ↓
Agent Substrate
        ↓
Kubernetes
        ↓
Infraestrutura

Kubernetes continua cuidando da infraestrutura computacional e dos Workers.

Agent Substrate introduz abstrações específicas para workloads stateful e frequentemente ociosos.

AX adiciona uma experiência declarativa de alto nível, com primitivas como Tasks, Workspaces, Gateways e Models.

A analogia “Kubernetes dos agentes” é, portanto, útil para suscitar a discussão.

Mas tecnicamente eu prefiro outra formulação:

AX parece caminhar para uma camada declarativa de orquestração de workloads agentic construída sobre uma infraestrutura Kubernetes especializada pelo Agent Substrate.

Essa diferença é importante.

O que o Lab 02 demonstrou

Ao final dos experimentos:

Task orchestration             ✅
Actor lifecycle                ✅
suspend/resume                 ✅
DATA snapshots                 ✅
Workspace persistence          ✅
Worker migration               ✅
gVisor isolation               ✅
authenticated egress           ✅
Ollama local                   ✅
workload real de IA            ✅
avaliação determinística       ✅

Mas também encontramos:

Gateway allowlist enforcement       ⚠️
Git Workspace bootstrap             ⚠️
WorkspaceReady sem materialização   ⚠️
TaskRunning sem command bem-sucedida⚠️
golden snapshot de estado degradado ⚠️
SSH interativo para workload longo  ⚠️
qualidade dependente do modelo      ⚠️

E talvez essa seja justamente a parte mais interessante de estudar tecnologias ainda jovens.

A documentação nos mostra a abstração desejada.

O laboratório mostra o comportamento real.

E arquitetura acontece justamente no espaço entre os dois.

Próximo passo

Na terceira parte quero avançar para uma primitive que deliberadamente deixei de fora deste laboratório:

Model.

Até aqui, o Ollama funcionou como um serviço externo consumido pela Task.

No próximo laboratório, a ideia é trabalhar com a integração nativa do AX e um modelo Gemini, investigando:

• Model como recurso declarativo;
• secrets;
• parâmetros de inferência;
• consumo do modelo por Tasks;
• lifecycle do agente;
• chamadas a ferramentas;
• estado persistente;
• falhas e retries;
• e o que muda quando deixamos de executar apenas uma inferência e passamos a executar um agente propriamente dito.

A documentação atual descreve Model como uma configuração nomeada contendo provider, identificador do modelo, parâmetros e referência ao Secret do Kubernetes.

Será o próximo passo da pergunta que iniciou esta série:

Até onde AX realmente consegue funcionar como uma plataforma operacional para agentes autônomos?