AX – O Orquestrador Agêntico Aberto do Google
O novo projeto AX do Google pretende fornecer um “orquestrador agêntico” open source baseado em Kubernetes para executar grandes quantidades de agentes de IA em ambientes seguros e isolados, com recursos como snapshot/retomada rápida e controles rígidos de rede e permissões. Os comentaristas estão divididos: alguns veem isso como uma ferramenta séria, em nível de infraestrutura, adequada para laboratórios de pesquisa ou empresas que precisam gerenciar cargas de trabalho agênticas não confiáveis e em rajadas, em escala; outros o consideram um “Kubernetes para agentes” superengenheirado e desnecessário para o uso típico em desenvolvimento. O ceticismo é agravado pelo histórico irregular do Google em sustentar tanto produtos quanto projetos open source, levando muitos a tratar o AX como experimental e possivelmente de curta duração, apesar de sua ambição técnica.
O que o AX é e o que não é
- Muitos leitores tiveram dificuldade em entender o propósito do AX pela página de apresentação; “orquestrador” pareceu vago.
- Alguns esclareceram como: uma control plane baseada em k8s para executar agentes de LLM em sandboxes isoladas fora da máquina do usuário, com controles de egress, limites de recursos e suspensão/retomada rápidas.
- É uma camada de infraestrutura, não um framework de agentes em nível de aplicação como LangChain; trata mais de “onde e como os agentes rodam” do que de “como pensam”.
Kubernetes, YAML e Complexidade
- Crítica forte de que o AX é “Kubernetes para agentes”: exige um cluster k8s, registry de contêineres, Agent Substrate API, configurações YAML.
- Alguns veem isso como um overengineering desnecessário e nada “ergonômico”, apesar das alegações de marketing.
- Outros argumentam que, em ambientes corporativos ou já baseados em k8s, isso é natural: primitivas familiares, fácil de adicionar se você já tem clusters, e alinhado aos padrões de infraestrutura da indústria.
Segurança, Sandboxing e Escala
- Reações positivas ao forte isolamento: microVM/gVisor, allowlists de egress em zero trust, gateway MITM, retomada rápida de tarefas, persistência do workspace.
- Vários observam que isso atende a necessidades reais para executar código não confiável de agentes, especialmente em escala ou em fluxos de trabalho sensíveis a segurança.
- Debate sobre tecnologias de microVM e o quanto diferentes abordagens (Firecracker, qemu, smolvm, etc.) realmente fornecem isolamento.
- O AX é visto como mais relevante para cargas de trabalho agênticas grandes e em rajadas (evals, RL, training) do que para pequenas equipes de desenvolvimento.
Comparação com outros esforços do Google e com o ecossistema
- O AX se baseia no Agent Substrate, que está sendo levado para a CNCF; foi contrastado com outro projeto do Google, Scion, que encapsula harnesses existentes e é visto por alguns como mais integrador.
- Alguns preferem Scion ou outros orquestradores que executam “cargas de trabalho normais” e harnesses existentes em vez de exigir uma nova stack.
- Muitos observam que “todo mundo e a avó” está construindo frameworks/sandboxes para agentes; ainda não existe um claro “React dos agentes”.
Confiança no Google e longevidade
- Ceticismo recorrente sobre a longevidade de produtos e open source do Google, citando a história de “morto pelo Google” e ferramentas abandonadas rapidamente.
- Outros contra-argumentam com exemplos de OSS do Google de longa duração (Kubernetes, Go, Chromium, etc.), mas o sentimento geral é: trate o AX como experimental e evite dependência profunda em produção.
Utilidade e exagero
- Alguns veem fortes méritos técnicos e estão animados para estudar seu design.
- Outros argumentam que pouquíssimos usuários realmente precisam de “bilhões de agentes” ou de uma infraestrutura tão pesada; para muitos, VMs simples, contêineres ou ferramentas locais continuam suficientes.