agent-pool para Google AI e Gemini CLI lançado com pipelines, cron e bounce-back

Google AI e Gemini CLI agora contam com uma nova camada de orquestração de agentes de código aberto. O servidor agent-pool MCP coleta delegações espalhadas em pipelines, consegue devolver tarefas para revisão, executá-las conforme agendamento e descarregar a execução para máquinas remotas.

Orquestração Automática

O problema que quase todo cenário multi-agente enfrenta é simples: o agente principal gasta muito tempo não trabalhando, mas despachando. Se os passos dependem um do outro—análise, refatoração, testes, deploy—o orquestrador precisa consultar status, analisar respostas e lançar manualmente o próximo executor. Agent-pool move essa lógica para um daemon em background.

Através de create_pipeline, os passos e dependências são descritos antecipadamente, e o processo em si permanece vivo mesmo após reiniciar a IDE. A ideia chave não é apenas executar um worker, mas dar aos agentes uma linguagem de coordenação. Após um estágio ser concluído, o executor envia um sinal de prontidão, e se dados estiverem faltando, a tarefa pode ser devolvida para revisão com uma explicação.

Esse bounce-back é semelhante a Request Changes em code review: o passo anterior complementa o artefato e o retorna à cadeia. Isso torna o pipeline não um script linear, mas um loop gerenciado com limite no número de devoluções.

"Um worker pode delegar tarefas adiante por conta própria—é assim que

toda orquestração fractal é construída."

O artigo descreve os principais mecanismos de tal esquema:

• on_complete—inicia o próximo passo após um worker específico ser concluído
• on_complete_all—aguarda o grupo inteiro e faz um fan-in antes do próximo estágio
• on_file—reage ao aparecimento de um arquivo no disco
• signal_step_complete—informa ao daemon que o passo foi verdadeiramente concluído
• bounce_back—devolve a tarefa para trás, e maxBounces limita o número de ciclos

Cron e SSH

O agendamento é tratado separadamente. A ferramenta schedule_task usa formato cron padrão, então um agente pode ser configurado para ser executado diariamente ou a cada hora sem um agendador separado. Importante: o daemon define bloqueios de arquivo atômicos: mesmo se abrir múltiplas janelas da IDE simultaneamente, a mesma tarefa será executada apenas uma vez.

Os resultados são armazenados em uma pasta scheduled-results, portanto o cenário pode ser usado tanto para verificações rotineiras de servidores quanto para montagem periódica de relatórios semanais. Se uma máquina local não for suficiente, workers podem ser enviados para um servidor remoto via SSH. O runner é descrito na configuração agent-pool, após o qual tarefas específicas começam a ser executadas em uma máquina dedicada com Gemini CLI instalado.

O valor prático é claro: testes, refatoração ou análise em massa de código continuam mesmo após o laptop ser fechado. O autor descreve um fluxo de trabalho típico: agentes trabalham em uma branch separada, fazem commits, fazem push dos resultados, e pela manhã o desenvolvedor simplesmente abre um pull request e revisa o resultado.

Contexto e Controle

Outro detalhe útil é passar contexto entre agentes através das sessões integradas do Gemini CLI. Um worker pode terminar uma pesquisa, salvar a session_id, e o próximo pode pegar a mesma conversa e continuar sem recontar o que foi encontrado. Para cadeias longas, isso economiza tokens e reduz erros nos limites entre estágios: o segundo agente vê não um resumo seco, mas o histórico completo de análise.

Sessões ativas podem ser visualizadas separadamente e conectadas manualmente se necessário. Há também uma camada de restrições necessária para trabalho real em equipe. Através de policy, você pode dar a um agente modo somente leitura ou edição segura sem direito de executar comandos.

Se isso não for suficiente, as regras são definidas com mais precisão através de um arquivo YAML separado. O parâmetro include_dirs complementa este modelo: por padrão um worker vê apenas o diretório de trabalho, e o acesso a configurações externas ou pastas adicionais deve ser habilitado explicitamente. Esta abordagem torna a automação significativamente mais segura do que acesso total incondicional a todo o projeto.

Finalmente, agent-pool introduz grupos—essencialmente templates para equipes fractais. Você pode registrar um runner, skill, policy e limite max_agents em um grupo uma vez, então enviar múltiplos executores a partir dele sem duplicar configurações. Esses grupos são salvos entre reinicializações da IDE e conectados diretamente aos pipelines.

Se um passo deve ser executado em paralelo, o daemon acionará múltiplos agentes, distribuirá índices a eles e aguardará um resultado comum. Fail-fast se aplica: se um worker cair com erro ou enviar um bounce-back, outros processos são imediatamente cancelados para evitar desperdiçar tempo e recursos.

O Que Isto Significa

Para desenvolvedores, este é um sinal de que AgentOps está se movendo do nível de experimentos para o nível de ferramentas do dia a dia. Quando pipelines, agendador, runners remotos e controle de acesso se reúnem em torno de uma única assinatura Google AI, cenários multi-agente se tornam não uma demonstração, mas infraestrutura funcional para código, testes e automação rotineira.