agent-pool para Google AI e Gemini CLI traz pipelines, cron e bounce-back

Surgiu uma nova camada open source de orquestração de agentes para Google AI e Gemini CLI. O servidor MCP agent-pool reúne delegações soltas em pipelines, consegue devolver tarefas para ajuste, executá-las em horários programados e levar a execução para máquinas remotas.

Orquestração automática

O problema que quase todos os cenários multiagente enfrentam é simples: o agente principal gasta tempo demais não trabalhando, mas despachando. Se as etapas dependem umas das outras (análise, refatoração, testes, deploy), o orquestrador precisa consultar status, interpretar respostas e disparar manualmente o próximo executor. O agent-pool leva essa lógica para um daemon em segundo plano. Com create_pipeline, etapas e dependências são descritas antecipadamente, e o processo continua vivo mesmo depois de reiniciar a IDE.

A ideia central não é só iniciar um worker, mas dar aos agentes uma linguagem de coordenação. Ao concluir uma etapa, o executor envia um sinal de conclusão, e, se faltarem dados, a tarefa pode voltar para ajuste com uma explicação do motivo. Esse bounce-back lembra o Request Changes de um code review: a etapa anterior complementa o artefato e o devolve à cadeia. Assim, o pipeline deixa de ser um script linear e vira um ciclo controlado, com limite no número de devoluções.

"O worker pode delegar tarefas adiante por conta própria — toda a

orquestração fractal se baseia nisso".

O artigo descreve os principais mecanismos desse esquema:

• on_complete — inicia a próxima etapa após a conclusão de um worker específico
• on_complete_all — espera o grupo inteiro e faz fan-in antes da próxima etapa
• on_file — reage ao aparecimento de um arquivo no disco
• signal_step_complete — informa ao daemon que a etapa realmente terminou
• bounce_back — devolve a tarefa, e maxBounces limita o número de ciclos

Cron e SSH

O agendamento é um recurso à parte. A ferramenta schedule_task usa o formato cron comum, então é possível colocar o agente para rodar todo dia ou toda hora sem um agendador separado. O daemon aplica bloqueios atômicos de arquivo: mesmo que várias janelas da IDE sejam abertas ao mesmo tempo, a mesma tarefa é executada uma única vez. Os resultados vão para a pasta scheduled-results, e o cenário serve tanto para verificações rotineiras de servidores quanto para a montagem periódica de relatórios semanais.

Se a máquina local não dá conta, os workers podem ser enviados a um servidor remoto por SSH. O runner é descrito na configuração do agent-pool, e a partir daí tarefas específicas passam a rodar em uma máquina dedicada com o Gemini CLI instalado. O sentido prático é claro: testes, refatoração ou análise em massa de código continuam mesmo depois que o notebook é fechado. O autor descreve um fluxo típico assim: os agentes trabalham em uma branch separada, fazem commits e enviam o resultado, e de manhã o desenvolvedor apenas abre um pull request e revisa o resultado.

Contexto e controle

Outro detalhe útil é a passagem de contexto entre agentes pelas sessões integradas do Gemini CLI. Um worker pode terminar a pesquisa e salvar um session_id, e o seguinte retoma a mesma conversa e continua sem precisar que lhe recontem o que foi encontrado. Em cadeias longas, isso economiza tokens e reduz erros nas emendas entre etapas: o segundo agente vê não um resumo seco, mas o histórico completo da análise. As sessões ativas podem ser consultadas separadamente e, se necessário, acessadas manualmente.

Há também uma camada de restrições necessária para o trabalho real em equipe. Pela policy, é possível dar ao agente um modo somente leitura ou de edição segura, sem direito de executar comandos. Se isso não bastar, as regras são definidas com mais precisão em um arquivo YAML separado. O parâmetro include_dirs complementa esse modelo: por padrão, o worker enxerga apenas o diretório de trabalho, e o acesso a configurações externas ou pastas adicionais precisa ser habilitado explicitamente. Essa abordagem deixa a automação bem mais segura do que um acesso total e incondicional a todo o projeto.

Por fim, o agent-pool introduz grupos, basicamente modelos de equipes fractais. Em um grupo é possível registrar uma só vez o runner, a skill, a política e o limite max_agents, e depois enviar vários executores a partir dele sem duplicar configurações. Esses grupos persistem entre reinícios da IDE e se conectam diretamente aos pipelines. Se uma etapa precisa rodar em paralelo, o daemon sobe vários agentes, distribui índices e aguarda o resultado conjunto. Vale o fail-fast: se um worker falhar com erro ou enviar um bounce-back, os demais processos são cancelados imediatamente, para não queimar tempo e recursos à toa.

O que isso significa

Para os desenvolvedores, é um sinal de que o AgentOps começa a descer do nível dos experimentos para o das ferramentas do dia a dia. Quando pipelines, agendador, runners remotos e controle de permissões se reúnem em torno de uma única assinatura do Google AI, os cenários multiagente deixam de ser demonstração e viram infraestrutura de trabalho para código, testes e automação de rotina.