--- title: "Google libera orquestrador de código aberto para organizar agentes autônomos de IA" author: "Gustavo Ramos O. Klein" date: "2026-09-23 09:15:00-03" category: "Inteligência Artificial & Dados" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/23/google-libera-orquestrador-de-codigo-aberto-para-organizar-agentes-autonomos-de-ia/md" --- ## Resumo - O Google disponibilizou o AX em setembro de 2026 como um orquestrador de código aberto para agentes autônomos de IA sobre Kubernetes. - O AX usa o Agent Substrate e trata agentes como atores com estado, permitindo suspender e retomar tarefas em menos de um segundo. - A plataforma organiza a execução com quatro primitivas: Task, Workspace, Gateway e Model. - A versão 0.3.0 dividiu o sistema em ax-server, ax-controller e ax-task-runner. - O armazenamento de estado migrou de CRDs do Kubernetes para Redis Streams para suportar milhões de tarefas curtas. - O projeto mira pesquisa e produção, com multiplexação densa, isolamento por sandbox com gVisor e capacidade destacada de bilhões de tarefas por cluster. --- Em **setembro de 2026**, o Google disponibilizou o AX, um orquestrador de código aberto para agentes autônomos de inteligência artificial integrado ao Kubernetes. O projeto foi desenhado para organizar a execução de agentes que precisam realizar tarefas por períodos prolongados, mantendo informações de estado mesmo quando a atividade é interrompida. Esse detalhe resolve um problema prático: agentes podem passar parte do tempo aguardando respostas de modelos de linguagem ou intervenção humana, enquanto a infraestrutura continua alocada. O AX entra nessa conversa como uma camada de execução declarativa, capaz de separar a definição da tarefa dos recursos necessários para executá-la. Neste artigo, vamos desbugar como essa arquitetura funciona, o que mudou na versão 0.3.0 e por que a suspensão de tarefas altera a conta operacional de aplicações baseadas em IA. ## O AX transforma agentes em tarefas organizadas O primeiro movimento do AX é retirar do desenvolvedor parte do trabalho manual de coordenar a execução. O projeto usa o **Agent Substrate** como runtime, ou seja, como a camada responsável por executar os agentes, e trata cada agente como um ator com estado. Na prática, isso cria uma separação entre o agente que toma decisões e a infraestrutura que precisa mantê-lo ativo, conectá-lo a recursos e preservar sua continuidade. O [site oficial do AX](https://agentexecutor.io/) descreve a ferramenta como um plano de controle declarativo, no qual o usuário declara as partes necessárias para a execução sem administrar manualmente toda a infraestrutura subjacente. A analogia ajuda a entender a proposta: em vez de cada agente negociar sozinho com servidores, armazenamento e rede, o AX funciona como uma central que organiza esse diálogo. A primeira primitiva declarativa é a **Task**, responsável por concentrar informações sobre o ciclo de vida e os recursos de uma tarefa. Esse conceito dá ao AX uma unidade clara de organização, porque o sistema passa a acompanhar o que precisa ser executado e quais recursos estão associados àquela execução. O ciclo de vida indica que uma tarefa pode avançar, aguardar, ser suspensa e depois retomada, enquanto os recursos descrevem a infraestrutura necessária para que o agente cumpra seu trabalho. Para quem desenvolve, a mudança de perspectiva é relevante: a tarefa deixa de ser uma sequência isolada de comandos e passa a ser uma entidade que o orquestrador consegue acompanhar. Esse é o primeiro passo para administrar agentes como processos de longa duração, em vez de tratá-los como chamadas descartáveis. A segunda primitiva é o **Workspace**, usada para montar os ambientes em que os agentes trabalham. O termo pode ser entendido como o espaço operacional entregue à tarefa, reunindo as condições necessárias para que o agente execute suas ações. Essa separação evita que a definição do trabalho fique misturada à preparação do ambiente, uma distinção parecida com separar o roteiro de uma peça do palco onde ela será encenada. No desenho do AX, o workspace participa do contrato declarativo que conecta a tarefa à infraestrutura, permitindo que o agente receba um ambiente definido para sua execução. A consequência prática é uma organização mais clara entre o que o agente deve fazer e o lugar técnico onde esse trabalho acontece, relação que prepara o caminho para controlar também rede e modelos. O terceiro elemento é o **Gateway**, voltado às políticas de rede. Em termos simples, ele concentra as regras que definem como a execução deve se conectar a outros serviços, transformando a comunicação em uma parte declarada da tarefa. Essa camada importa porque agentes autônomos dependem de conversas com APIs, modelos e sistemas externos, e cada conexão precisa estar associada a uma política de rede. O AX não descreve o Gateway como um detalhe escondido dentro do código do agente; ele o apresenta como uma das primitivas que estruturam a operação. A rede, portanto, deixa de ser apenas um caminho invisível entre componentes e passa a fazer parte do acordo que organiza a execução, como uma ponte com regras de entrada, saída e circulação. O quarto componente é o **Model**, que administra parâmetros de modelos de linguagem de grande escala, conhecidos pela sigla LLM, além de segredos. Essa separação permite que a tarefa declare qual configuração de modelo precisa usar sem incorporar diretamente todos os detalhes de acesso e gerenciamento ao código do agente. O tratamento de segredos também coloca credenciais e informações sensíveis dentro da camada que coordena a execução, em vez de deixá-las dispersas entre diferentes tarefas. As quatro primitivas trabalham como peças de uma mesma conversa: a Task define o trabalho, o Workspace prepara o ambiente, o Gateway organiza a comunicação e o Model concentra os parâmetros e segredos relacionados à inteligência artificial. O valor do desenho aparece justamente nessa interoperabilidade entre responsabilidades diferentes. ## O estado preservado muda o custo da execução Essa divisão ganha sentido porque o AX trata agentes como **atores com estado**, e não como execuções que precisam recomeçar do zero a cada interrupção. Estado, nesse contexto, é o conjunto de informações que permite à tarefa continuar sua trajetória depois de uma pausa. O sistema permite suspender e retomar tarefas em menos de um segundo, segundo a descrição do projeto. A diferença é parecida com interromper uma conversa mantendo o histórico disponível para a próxima fala, em vez de apagar tudo e obrigar o interlocutor a explicar novamente o que já foi discutido. Para agentes que realizam trabalhos longos, essa capacidade conecta diretamente a lógica da aplicação à administração dos recursos, porque o orquestrador acompanha a continuidade da tarefa enquanto controla quando ela precisa estar efetivamente em execução. A suspensão também responde ao problema dos agentes que ficam ociosos enquanto aguardam uma resposta. A análise da versão 0.3.0 descreve o uso de checkpoint, isto é, o registro do estado do agente, antes de interromper a execução durante períodos de espera por APIs de modelos ou por intervenção humana. Quando a resposta chega ou a intervenção acontece, a tarefa pode ser retomada a partir daquele ponto. O objetivo técnico é resolver o custo operacional de manter agentes parados na nuvem, evitando que a infraestrutura permaneça ocupada durante todo o intervalo de espera. Essa lógica aproxima o gerenciamento de agentes da administração de uma fila inteligente: a execução ativa recebe recursos, a execução que aguarda preserva seu contexto e o sistema decide quando a conversa deve continuar. A integração com **Kubernetes** coloca o AX em uma camada conhecida de organização de cargas de trabalho, mas a proposta não se resume a oferecer mais uma interface para iniciar contêineres. O projeto foi apresentado como um orquestrador em estilo Kubernetes para agentes autônomos e como um runtime de infraestrutura. Isso significa que a preocupação central está na execução, no isolamento, na rede, nos recursos e na continuidade das tarefas. O desenvolvedor descreve o que precisa ser executado por meio das primitivas do AX, enquanto a ferramenta coordena as condições para que os agentes funcionem. A conexão com Kubernetes faz parte dessa estratégia de integração, porque permite posicionar o gerenciamento dos agentes ao lado da infraestrutura que já organiza cargas de trabalho em escala. Essa posição diferencia o AX de orquestradores de nível mais alto, como o **LangGraph**, porque o projeto se concentra na camada de infraestrutura que sustenta a execução. Um orquestrador de alto nível pode ajudar a definir fluxos e relações entre etapas, enquanto o AX lida com questões como sandbox, rede, modelos e suspensão do estado. Sandbox é um ambiente isolado, usado para separar a execução do agente de outras partes do sistema. A distinção ajuda a responder uma pergunta prática: onde termina a lógica do agente e começa a responsabilidade da plataforma? No desenho do Google, o AX ocupa o espaço entre o código que define o comportamento do agente e os recursos necessários para mantê-lo funcionando com controle, isolamento e capacidade de escala. ## A versão 0.3.0 reorganiza a arquitetura A evolução mais concreta chegou com a **versão 0.3.0**, lançada em 20 de setembro de 2026. De acordo com o repositório oficial, essa atualização introduziu mudanças na arquitetura e dividiu o projeto em três serviços: ax-server, ax-controller e ax-task-runner. A separação mostra que o Google está tratando a execução de agentes como uma cadeia de responsabilidades técnicas, em vez de concentrar todo o trabalho em um único componente. Para quem acompanha a evolução do projeto, a versão funciona como um marco porque conecta a proposta conceitual do AX a uma estrutura capaz de lidar com diferentes tipos de tarefa. A arquitetura passa a ser descrita por serviços distintos, enquanto o armazenamento do estado acompanha a necessidade de administrar execuções de curta duração em quantidade elevada. O primeiro nome apresentado nessa divisão é o **ax-server**, que passa a integrar a arquitetura de três serviços introduzida no AX 0.3.0. A existência de um serviço separado com essa função indica uma organização diferente daquela usada nas versões anteriores, quando o projeto mantinha mais responsabilidades concentradas. O ponto importante para o leitor não está em decorar os nomes, mas em entender que o runtime passou a ser estruturado em componentes identificáveis. Essa modularidade ajuda a ler o AX como uma plataforma de execução, e não como uma biblioteca isolada dentro do código de uma aplicação. A separação prepara o terreno para que o controle das tarefas e a execução efetiva sejam tratados em partes próprias, ligação que aparece nos outros dois serviços. O segundo componente é o **ax-controller**, também introduzido como parte da arquitetura do AX 0.3.0. O controlador aparece ao lado do servidor e do executor de tarefas na divisão oficial do projeto, formando uma estrutura com três serviços distintos. Mesmo sem transformar o artigo em um manual de implantação, essa mudança tem uma leitura direta: o Google está organizando o runtime em unidades que podem ser identificadas separadamente dentro da operação. Essa escolha combina com o objetivo de administrar agentes persistentes, porque tarefas de longa duração precisam ser acompanhadas enquanto aguardam recursos, respostas ou retomadas. A arquitetura deixa de ser descrita somente pelos conceitos de agente e tarefa e passa a incluir uma separação concreta entre os elementos que compõem a execução. O terceiro serviço é o **ax-task-runner**, nome que completa a divisão arquitetural apresentada na versão 0.3.0. Ele aparece como a terceira parte da estrutura ao lado de ax-server e ax-controller, sem que o projeto seja reduzido a um único processo responsável por todas as etapas. Essa organização conversa diretamente com a ideia de que tarefas podem ter ritmos diferentes: algumas estarão ativas, outras esperarão por respostas e outras precisarão retomar um estado salvo. O AX passa a oferecer uma forma mais explícita de separar a coordenação da execução, algo que interessa a equipes que precisam acompanhar agentes em grande quantidade. A arquitetura, portanto, acompanha o problema que o runtime pretende resolver: preservar o contexto sem deixar cada tarefa consumindo recursos de maneira contínua. A mudança de armazenamento é outro ponto decisivo da atualização. O AX migrou o estado das tarefas de **CRDs do Kubernetes** para Redis Streams, uma estrutura voltada ao registro e processamento de fluxos de eventos, com o objetivo de suportar milhões de tarefas de curta duração. Essa escolha está ligada ao tipo de carga que o projeto pretende administrar, formada por muitas execuções que podem nascer, aguardar, ser suspensas e terminar em intervalos diferentes. O armazenamento deixa de ser tratado somente como um detalhe de configuração e passa a acompanhar a escala do problema. Quando o número de tarefas cresce, preservar e recuperar o estado de cada uma exige uma camada capaz de lidar com esse fluxo, especialmente quando os agentes não permanecem ativos durante todo o tempo. A versão 0.3.0 também substituiu um harness Python incorporado por uma arquitetura com três serviços distintos, enquanto o sistema é escrito em **Go**. Harness é uma estrutura de suporte usada para conduzir e controlar a execução de uma aplicação. A troca indica uma mudança na forma de organizar o runtime, não apenas uma alteração superficial na linguagem do projeto. O objetivo descrito para essa evolução é lidar melhor com agentes ociosos, permitindo que seu estado seja salvo e que a tarefa seja suspensa durante a espera. A ligação entre código, serviços e armazenamento fica mais clara: o agente mantém seu contexto, a arquitetura distribui responsabilidades e o Redis Streams atende ao volume de tarefas curtas que a plataforma precisa acompanhar. ## Escala, isolamento e código aberto O AX foi apresentado para pesquisa e produção, com abstrações que reúnem tarefas, workspaces, políticas de rede e modelos sem exigir que o desenvolvedor administre manualmente a infraestrutura subjacente. Essa promessa é direcionada a frotas de agentes, expressão usada para descrever conjuntos de agentes executados em paralelo ou em sequência dentro de uma mesma operação. A plataforma também é descrita como compatível com multiplexação densa, ou seja, com a concentração de muitas execuções em uma infraestrutura compartilhada. A consequência prática é uma tentativa de aproximar a experiência de definir agentes da experiência de declarar serviços: o usuário informa as partes que compõem o trabalho, e o runtime coordena os recursos necessários para colocá-lo em funcionamento. O isolamento aparece por meio de **sandboxes com gVisor**. Nesse desenho, o sandbox funciona como uma área separada para a execução do agente, enquanto o gVisor fornece a tecnologia associada a esse isolamento. A separação é relevante porque agentes autônomos podem realizar tarefas com diferentes necessidades de ambiente, rede e modelo, e a plataforma precisa manter essas execuções organizadas. O AX coloca o isolamento ao lado da multiplexação, conectando dois objetivos que costumam entrar em tensão: acomodar muitos agentes na mesma infraestrutura e manter cada execução dentro de limites próprios. A proposta técnica ganha forma quando as primitivas declarativas, o gerenciamento de rede e a separação dos ambientes deixam de ser decisões espalhadas pelo código e passam a fazer parte da camada de execução. O repositório oficial do projeto destaca a capacidade de executar **bilhões de tarefas por cluster**. Essa afirmação descreve a ambição de escala do AX e ajuda a explicar por que a arquitetura passou a lidar de modo específico com tarefas de curta duração e estados que precisam ser preservados. Cluster é o conjunto de recursos computacionais tratado como uma unidade de execução; no caso do AX, ele aparece como a referência para medir o volume de tarefas que a plataforma pretende administrar. O número não significa que toda implantação atingirá essa marca, mas mostra o tipo de problema que o projeto quer endereçar. A mudança para Redis Streams e a separação em serviços fazem sentido dentro dessa busca por grande volume, sobretudo quando muitos agentes alternam entre atividade e espera. O código do AX foi disponibilizado sob a **licença Apache 2.0**, o que coloca o projeto na categoria de software de código aberto. A abertura combina com a proposta de oferecer um runtime para pesquisa e produção, permitindo que a estrutura declarativa seja examinada no repositório oficial e relacionada às necessidades de cada implantação. Para o leitor técnico, o ponto de partida é observar como as quatro primitivas conectam execução, ambiente, rede e modelo, em vez de avaliar o AX somente pelo rótulo de agente autônomo. A licença, a arquitetura e o foco em escala formam uma mesma mensagem: o Google está apresentando uma camada de infraestrutura para organizar agentes, não apenas mais uma interface de conversa com modelos de linguagem. ## O que o AX muda para quem executa agentes Para avaliar o AX, a pergunta mais útil é onde está o maior custo da operação: na criação do agente ou no tempo em que ele permanece aguardando uma resposta. Se o problema está em coordenar tarefas persistentes, o modelo de atores com estado e a retomada em menos de um segundo são os pontos a observar. Se a dificuldade está na conexão entre serviços, o Gateway oferece a referência para analisar políticas de rede. Se o desafio está em manter ambientes separados, o Workspace e o isolamento por sandbox entram na avaliação. Essa leitura transforma a plataforma em uma caixa de ferramentas técnica: Task para o ciclo de vida, Workspace para o ambiente, Gateway para a comunicação e Model para parâmetros e segredos. O próximo passo anunciado pelo próprio projeto já está concentrado na arquitetura da versão **0.3.0**: três serviços distintos, armazenamento por Redis Streams e uma abordagem voltada a milhões de tarefas curtas. Para equipes de pesquisa e produção, isso significa acompanhar como o AX equilibra estado persistente, suspensão, retomada, multiplexação e isolamento dentro de clusters Kubernetes. O ponto central permanece concreto: agentes autônomos precisam conversar com modelos, APIs e pessoas, mas não precisam manter todos os recursos ocupados durante cada pausa. Ao colocar essa negociação em um runtime declarativo de código aberto, o Google transforma a infraestrutura em uma ponte entre o comportamento do agente e a operação que sustenta sua execução.