Google abre código do AX, orquestrador de agentes em larga escala

O que é o AX

O Google abriu o código do AX, um orquestrador declarativo de alta taxa de processamento projetado para executar cargas de trabalho de agentes autônomos em escala - o README menciona bilhões de tarefas por cluster. O repositório está no GitHub sob licença Apache 2.0 e, no momento da captura, reunia cerca de 5,7 mil estrelas e 239 forks, com 625 commits.

A premissa do projeto é que agentes formam um novo tipo de carga de trabalho: não são microserviços sem estado nem tarefas batch de execução única. Eles acumulam estado, exigem isolamento rigoroso, chamam APIs de modelos e servidores de ferramentas e podem gastar dinheiro em loop se ninguém estiver supervisionando.

Primitivas declarativas

O AX oferece quatro primitivas principais, todas expressas como manifests ax.io/v1alpha1 e aplicadas com um único comando, num formato deliberadamente semelhante ao kubectl:

• Task: executa código de agente não confiável em um sandbox com limites de CPU e memória.
• Workspace: pré-configura repositórios Git, servidores MCP e pacotes de skills para que cada agente comece com o ambiente pronto.
• Gateway: restringe o tráfego de saída a uma lista explícita de hosts permitidos.
• Model: configura qual LLM a plataforma usa, com credenciais vindas de um secret do Kubernetes.

Além disso, comandos como ax suspend e ax resume permitem pausar um agente ocioso via checkpoint e retomar exatamente de onde parou, e ax ssh permite inspecionar o que um agente em execução está fazendo dentro do sandbox.

Arquitetura e operação

O AX roda sobre o Agent Substrate para execução em sandbox e requer um cluster Kubernetes, a ferramenta ko, um registro de contêineres e acesso a uma API de controle do Agent Substrate. O deploy leva Redis e as imagens do plano de controle para o namespace ax-system.

O fluxo de uso segue o padrão do Kubernetes: um arquivo YAML declara workspace e tarefa, ax apply aplica, ax watch acompanha fases e condições em tempo real e ax ssh acessa o sandbox. A CLI conversa com o plano de controle via gRPC e segue o contexto ativo do kubectl, permitindo alternar entre clusters com kubectx ou direcionar um contexto específico com a flag --context.

A documentação cobre conceitos, escrita de manifests, comportamento do sandbox, contrato entre plano de controle e contêineres de tarefa (com possibilidade de construir imagens de runner próprias), rede (acesso a tarefas via roteador atenet a partir do cluster, do laptop ou de clientes gRPC) e a arquitetura do plano de controle.

Estado e ressalvas

O projeto avisa que ainda está refinando ativamente conceitos, protocolos e especificações, e que mudanças significativas de quebra de compatibilidade são prováveis antes de uma versão estável. O README cita como modelo padrão o gemini-3.8-flash do provedor google e aponta o site agentexecutor.io como referência.