Google AX: O Orquestrador de Agentes que Quer Substituir o Kubernetes

O Google acabou de abrir o código de um projeto que trata agentes de IA como cidadãos de primeira classe na infraestrutura. Chama-se AX, e se você já usou kubectl alguma vez na vida, vai se sentir em casa. A diferença é que, em vez de orquestrar containers, você orquestra agentes autônomos que pensam, erram, travam e precisam voltar exatamente de onde pararam.

Eu sei o que você está pensando: “mais um framework de agentes?”. Justo. Mas o AX não é um LangChain com logo novo. É uma camada de infraestrutura que roda em cima do Kubernetes e foi construída internamente no Google DeepMind antes de virar open source. A proposta é resolver os problemas que aparecem quando você tenta rodar milhões de agentes em produção, não apenas um chatbot que chama três ferramentas.

O problema que ninguém quer resolver

Frameworks como LangChain, CrewAI e AutoGen resolvem bem a parte do “como eu conecto um LLM a ferramentas”. O problema começa quando você coloca isso em produção. Agentes são fundamentalmente diferentes de APIs tradicionais:

• Eles são stateful: mantêm contexto entre chamadas
• São bursty: ficam ociosos por segundos e depois explodem em chamadas paralelas
• São long-running: uma tarefa pode durar minutos ou horas
• E o pior: são imprevisíveis: você não sabe qual ferramenta o agente vai chamar nem quando

Tenta encaixar isso num Deployment do Kubernetes com readiness probes e autoscaling baseado em CPU. Boa sorte.

O time da Jaana Dogan (a famosa @rakyll, engenheira do Google conhecida por contribuições ao Go e observabilidade) percebeu que precisava de primitivas novas. Não bastava colocar agentes dentro de containers. Era preciso repensar como o runtime lida com estado, suspensão e retomada de processos.

O que é o AX, na prática

AX significa Agent Executor. É um orquestrador declarativo, open source (Apache 2.0), que roda em cima de uma camada chamada Agent Substrate. Pense no Substrate como um runtime otimizado para criar e destruir sandboxes leves a uma velocidade absurda, e no AX como a interface que você usa para gerenciar tudo isso.

O projeto define quatro primitivas fundamentais:

1. Task

A unidade básica de execução. Cada Task roda código de agente dentro de um sandbox isolado com limites de CPU e memória. Tasks são baratas e descartáveis: o sistema foi projetado para criar e destruir milhões delas por cluster.

apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: code-review-agent
spec:
  workspaces:
    - name: my-repo
      goal: "Review pull request #42 for security issues"
  resources:
    cpu: "500m"
    memory: "1Gi"
  debug: true

2. Workspace

Configura o ambiente de trabalho do agente automaticamente. Você lista repositórios Git, servidores MCP ou simplesmente descreve em linguagem natural o que o agente precisa, e o sistema monta tudo antes da Task iniciar.

apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: my-repo
spec:
  git:
    - repo: https://github.com/empresa/backend.git
      branch: "main"
  mcp:
    - name: database-tools
      url: "http://mcp-db:8080"

3. Gateway

Controla o acesso de rede do agente. Toda comunicação externa passa por um allowlist explícito. Se o agente tentar acessar um domínio que não está na lista, é bloqueado. Isso é essencial quando você roda código não confiável (e convenhamos, código gerado por LLM sempre é “não confiável”).

4. Model

Centraliza a configuração dos modelos de IA. Em vez de cada agente carregar suas próprias credenciais e parâmetros, o Model define isso uma vez e referencia via Kubernetes Secrets. Troca de provider? Muda o Model, não o código.

O CLI que parece kubectl (de propósito)

Se você já usou Kubernetes, o AX é deliberadamente familiar:

# Instalar
go install github.com/google/ax/cmd/ax@latest

# Criar uma task
ax apply -f task.yaml

# Listar tasks rodando
ax get tasks

# Assistir o status em tempo real
ax watch task code-review-agent

# Abrir um shell dentro do sandbox do agente
ax ssh code-review-agent -- ls -la /workspace

# Suspender o agente (salva estado completo)
ax suspend task code-review-agent

# Retomar exatamente de onde parou
ax resume task code-review-agent

Aquele ax suspend e ax resume é onde a mágica acontece. O sistema faz um checkpoint completo do estado do agente (incluindo memória, arquivos modificados, conexões abertas) e consegue retomar em sub-segundo. Zero cold start. Isso significa que você pode manter milhares de agentes “dormindo” sem consumir recursos e acordá-los instantaneamente quando precisar.

AX vs LangChain vs CrewAI: onde cada um brilha

Eu já vi muita gente confundindo AX com mais um framework de prompt chaining. Não é. Para deixar claro onde cada ferramenta se encaixa:

A sacada é que AX e LangChain não são concorrentes diretos. Você pode rodar um agente construído com LangGraph dentro de uma Task do AX. O AX cuida da infraestrutura (isolamento, rede, estado, escala) enquanto o LangGraph cuida da lógica do agente (grafo de decisão, ferramentas, memória conversacional).

Pense assim: LangGraph é o framework do seu app. AX é o Kubernetes do seu agente.

A arquitetura por baixo dos panos

Na versão 0.3.0, o AX foi dividido em três serviços independentes:

1. API Frontend: recebe os manifests YAML e expõe a interface kubectl-like
2. Reconciler: observa o estado desejado e reconcilia com o estado real (exatamente como um controller do Kubernetes)
3. Task Runner: executa o código do agente em sandboxes isolados via Agent Substrate

O estado das tasks migrou de Custom Resources do Kubernetes para Redis Streams. Isso foi fundamental para escalar: CRDs do K8s não foram feitos para milhões de objetos efêmeros. Redis Streams dá a throughput necessária sem sobrecarregar o etcd.

[API Frontend] → [Redis Streams] → [Reconciler] → [Agent Substrate]
                                                          ↓
                                                   [Sandbox Pool]
                                                   ┌─────────────┐
                                                   │ Task 1      │
                                                   │ Task 2      │
                                                   │ Task N...   │
                                                   └─────────────┘

O Agent Substrate é o molho secreto. Ele consegue empacotar 10 a 20 vezes mais sandboxes no mesmo hardware comparado a containers tradicionais. Isso porque agentes passam a maior parte do tempo esperando (chamadas de API, respostas de LLM), então o Substrate faz multiplexing denso dos recursos ociosos.

Casos de uso reais (e quando NÃO usar)

O AX brilha em cenários específicos:

Onde usar:

• Pipelines multi-step com efeitos colaterais reais (pagamentos, booking, deploys)
• Sistemas que precisam de audit trail e SLAs
• Ambientes onde agentes executam código não confiável
• Escala massiva: milhares ou milhões de agentes concorrentes
• Cenários onde falha e retomada são inevitáveis

Onde NÃO usar:

• Chatbots simples de pergunta e resposta
• RAG básico (busca + resposta)
• Prototipagem rápida de prompts
• Projetos sem Kubernetes

Esse último ponto é importante. O AX requer um cluster Kubernetes rodando. Se seu projeto é um MVP com três endpoints, o AX vai adicionar mais complexidade do que valor. Use LangChain, use CrewAI, use o que funcionar. O AX é para quando esses frameworks param de escalar.

Quem está por trás disso

O projeto nasceu dentro do Google DeepMind, liderado pela Jaana Dogan e sua equipe. Jaana é conhecida na comunidade Go e de observabilidade (ela criou ferramentas como o opencensus e contribuiu extensivamente para o ecossistema de tracing distribuído).

No anúncio, ela foi direta: “Decidimos reinventar o Kubernetes para workloads agenticos com statefulness e resumption rápido”. Não é uma frase pequena. Reinventar o Kubernetes é basicamente dizer “a abstração atual não serve para esse problema”.

O repositório no GitHub já tem mais de 4.500 estrelas, 196 forks e 625+ commits. O projeto está sob Apache 2.0, mas vem com um aviso honesto: é pré-estável. Mudanças breaking vão acontecer.

Como testar agora

Se você quer experimentar, o caminho é:

# Prerequisitos: cluster K8s + ko (builder de containers)
brew install ko

# Instalar o CLI
go install github.com/google/ax/cmd/ax@latest

# Clonar e fazer deploy do control plane
git clone https://github.com/google/ax.git
cd ax
make deploy AX_IMAGE_REPO=seu-registry.io/ax

# Criar sua primeira task
cat > minha-task.yaml << 'EOF'
apiVersion: ax.io/v1alpha1
kind: Workspace
metadata:
  name: demo
spec:
  git:
    - repo: https://github.com/google/ax.git
      branch: "main"
---
apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: hello-agent
spec:
  workspaces:
    - name: demo
      goal: "List all Go files and summarize the project structure"
  debug: true
EOF

ax apply -f minha-task.yaml
ax watch task hello-agent

O debug: true permite que você faça ax ssh hello-agent para entrar no sandbox e ver exatamente o que o agente está fazendo. Essencial para debug em desenvolvimento.

Idempotência e compensação: o que faz diferença em produção

Um detalhe que passa batido na documentação mas é crucial: o AX tem garantias de idempotência por padrão. Se uma Task falha no meio e é retomada, ações já completadas não são re-executadas. Isso evita o pesadelo de cobranças duplicadas, emails enviados duas vezes ou deploys repetidos.

Além disso, o sistema suporta compensation hooks no padrão Saga. Se o passo 3 de um pipeline falha, os passos 1 e 2 podem ter handlers de compensação que desfazem suas ações. Para quem já trabalhou com microserviços, esse pattern é familiar, mas tê-lo built-in num orquestrador de agentes é novidade.

apiVersion: ax.io/v1alpha1
kind: Task
metadata:
  name: deploy-pipeline
spec:
  steps:
    - name: create-infra
      compensate: destroy-infra
    - name: deploy-app
      compensate: rollback-app
    - name: run-smoke-tests
  retryPolicy:
    maxRetries: 3
    backoff: exponential

O elefante na sala: vendor lock-in

Vamos falar do óbvio. É um projeto do Google. Open source, sim, Apache 2.0, sim. Mas a dependência do Agent Substrate (que não é open source no momento) cria uma questão legítima sobre portabilidade.

Se o Substrate for necessário para as funcionalidades core de suspend/resume e multiplexing denso, estamos falando de um ecossistema que funciona melhor (ou apenas funciona) no Google Cloud. O time não confirmou explicitamente se vai abrir o Substrate, mas a pressão da comunidade é forte.

Por enquanto, o AX funciona em qualquer cluster Kubernetes. As features de suspend/resume dependem do Substrate, mas o core de orquestração (tasks, workspaces, gateways) roda independente.

O que isso significa para o ecossistema

O lançamento do AX sinaliza algo maior: a indústria está migrando de “como construir um agente” para “como operar agentes em produção”. Frameworks de prompt chaining estão virando commodity. A guerra agora é na infraestrutura.

A Anthropic tem seu Agent SDK. A OpenAI tem o Agents SDK. A Microsoft tem o AutoGen com Azure. E agora o Google tem o AX. Cada big tech está apostando que a camada de runtime para agentes vai ser tão importante quanto o Kubernetes foi para containers.

Se essa aposta estiver certa, o AX pode ser para agentes o que o Kubernetes foi para microserviços: a abstração que todo mundo padroniza por cima. Se estiver errada, vai ser mais um repositório abandonado no GitHub do Google (e convenhamos, eles têm prática nisso).

4.500 estrelas em poucos dias sugerem que a comunidade está prestando atenção. Se você trabalha com agentes em produção ou está planejando ir nessa direção, vale colocar o AX no seu radar. Só não tenta usar pra aquele chatbot de FAQ do seu e-commerce. Para isso, um openai.chat.completions.create() ainda resolve.