Google abre o código do AX, orquestrador de agentes de IA inspirado no Kubernetes

O Google abriu o código do AX, um orquestrador e runtime declarativo licenciado em Apache 2.0 voltado para executar cargas de trabalho de agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → autônomos em escala. O projeto está hospedado em agentexecutor.io e no repositório google/ax, e roda sobre uma camada chamada Agent Substrate, segundo o anúncio cobreto pelo InfoQ. A proposta central é simples de enunciar e difícil de resolver bem: agentes autônomos não se comportam como microsserviços↳Microsserviços24 conteúdosArquitetura de Microsserviços em Node com o MoleculerJSDev (Back & Front) · jun 2025Segurança das APIs: como proteger seu ecossistema de microsserviçosDev (Back & Front) · dez 2023Você provavelmente não precisa de microsserviços (ainda)Dev (Back & Front) · mar 2026Ver tudo em Dev (Back & Front) → nem como jobs em lote, e a infraestrutura tradicional de containers cobra caro por essa diferença.

O problema: agente não é microsserviço nem batch job

Um microsserviço clássico responde a uma requisição e devolve resposta em milissegundos. Um job em lote roda até o fim de forma determinística. Um agente de IA autônomo faz outra coisa: ele tem estado, é "bursty" (picos intensos de CPU durante raciocínio, execução de ferramentas e avaliação local de código) intercalados com longos períodos ocioso enquanto espera resposta de um modelo, retorno de uma API externa ou intervenção humana.

Em um cluster Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → convencional, manter um sandbox dedicado ativo durante essas esperas desperdiça capacidade computacional. Por outro lado, se você derruba o sandbox para economizar, o cold start de um runtime de container comum introduz latência que quebra o loop interativo do agente. É exatamente esse ponto de atrito operacional, segundo o material do Google, que motivou o desenho do AX.

Como funciona: atores com estado e quatro primitivos declarativos

O AX roda sobre o Agent Substrate, um runtime de execução construído especificamente para multiplexação densa de atores. Cada sessão de agente vira um sandbox de ator isolado, com limites estritos de CPU e memória. Quando o agente entra em estado ocioso (esperando um provedor de inferência ou uma chamada de ferramenta), a plataforma faz checkpoint da execução e suspende o processo. O AX promete retomar atores suspensos em intervalos sub-segundo, sem cold start, multiplexando dezenas de tarefas nos mesmos workers para conservar recursos.

O plano de controle expõe quatro primitivos declarativos no estilo Kubernetes, definidos sob o grupo de API ax.io/v1alpha1:

• Task: define o ciclo de vida de execução, os limites de recurso do sandbox e as referências à infraestrutura de suporte.
• Workspace: monta o ambiente antes da execução. Dá para declarar repositórios Git, servidores MCP (Model Context Protocol), instalar pacotes de skills ou até fornecer objetivos em linguagem natural que um agente de inicialização executa para preparar toolchain e dependências antes da tarefa começar.
• Gateway: gerencia políticas de segurança de rede de saída, restringindo agentes em sandbox a allowlists explícitas de hostnames e portas, além de injetar credenciais nas requisições de saída.
• Model: centraliza parâmetros de provedores de LLM, configurações de runtime e segredos armazenados no próprio Kubernetes.

Quem já escreveu um Deployment ou uma NetworkPolicy vai reconhecer o padrão imediatamente: são CRDs (Custom Resource Definitions) aplicadas com kubectl apply (ou, no caso do AX, com sua própria ferramenta de linha de comando).

A CLI e o deploy: ax, ko, Redis e kubectx

A interação com o sistema é feita pela ferramenta ax, escrita em Go. Operadores de plataforma implantam o plano de controle no Kubernetes usando ko e Redis, dentro do namespace ax-system, conectando-se via contextos já existentes do kubectx.

No dia a dia, o desenvolvedor usa comandos como:

• ax apply para registrar manifests (Task, Workspace, Gateway, Model);
• ax watch para acompanhar em tempo real mudanças de fase e condição das tarefas;
• ax ssh para acessar ambientes de sandbox interativamente e depurar;
• ax suspend e ax resume para controlar manualmente o estado de execução da tarefa.

O projeto é posicionado tanto para deployment de agentes em produção quanto para ambientes de pesquisa que precisam rodar trajetórias em sandbox, loops de aprendizado por reforço e avaliações de benchmark de agentes em escala.

A recepção dividida da comunidade

O material reportado pelo InfoQ traz um retrato de recepção mista, colhido em discussões no Hacker News e no Reddit. De um lado, engenheiros de infraestrutura elogiam o AX por resolver o custo proibitivo de agentes ociosos esperando resposta de API de modelo ou input humano, que em clusters convencionais significa pagar por sandbox parado. De outro, desenvolvedores criticaram a promessa de "fluxos de trabalho ergonômicos" alegando que o overhead operacional de manter clusters Kubernetes, registries de container e CRDs customizadas via ko é tudo menos simples para quem só quer rodar um agente.

No Reddit, a discussão cruzada reforça um ponto de posicionamento: o AX é um runtime de execução fundacional, não um orquestrador de aplicação de alto nível como LangGraph ou CrewAI. Ou seja, ele não compete diretamente com frameworks que definem o fluxo lógico de um agente; ele resolve a camada de baixo, de onde e como esse agente roda.

Em canais de segurança e sistemas, praticantes destacaram o valor da contenção de raio de explosão ("blast-radius") dos sandboxes isolados por gVisor, mas também apontaram problemas de maturidade típicos de projeto recém-aberto: conexões derrubadas no proxy de egress e um gerenciamento de segredos ainda rudimentar. A conclusão que emerge dessas discussões, segundo o InfoQ, é que o AX não é um framework de início rápido para quem está sozinho testando um hack, e sim um primitivo de infraestrutura pensado para empresas gerenciando frotas de agentes de longa duração em grande escala.

O que isso muda para quem constrói

Para equipes de plataforma que já operam Kubernetes e estão tentando colocar agentes autônomos em produção, o AX oferece um vocabulário declarativo específico para um problema que hoje normalmente é resolvido na marra: filas customizadas, VMs dedicadas ou soluções caseiras de checkpoint. Ter Task, Workspace, Gateway e Model como CRDs padronizadas significa menos código de cola e mais superfície auditável, algo relevante para quem lida com governança de custo de nuvem e segurança de rede de saída (o Gateway resolve, de forma declarativa, um problema que muita gente hoje trata com regras de firewall soltas).

Por outro lado, o próprio debate da comunidade já sinaliza o filtro de adoção: se seu time não opera Kubernetes hoje, adotar o AX significa importar toda a complexidade operacional de cluster, ko e CRDs só para ganhar suspensão sub-segundo de agentes. Para quem já tem essa base, ou para empresas com frotas de agentes rodando 24/7 e uma conta de nuvem que sofre com sandboxes ociosos, o cálculo é diferente. Vale acompanhar o repositório no GitHub para ver como a comunidade resolve os problemas de maturidade já relatados, como o gerenciamento de segredos e a estabilidade do proxy de egress, antes de colocar isso em um pipeline crítico.

Fonte: InfoQ