agent-pool para Google AI y Gemini CLI añade pipelines, cron y bounce-back

Ha aparecido una nueva capa open source de orquestación de agentes para Google AI y Gemini CLI. El servidor MCP agent-pool agrupa delegaciones dispersas en pipelines, puede devolver tareas para su corrección, ejecutarlas según un calendario y trasladar la ejecución a máquinas remotas.

Orquestación automática

El problema al que se enfrentan casi todos los escenarios multiagente es sencillo: el agente principal dedica demasiado tiempo no a trabajar, sino a despachar. Si los pasos dependen unos de otros (análisis, refactorización, pruebas, despliegue), el orquestador debe consultar estados, interpretar respuestas y lanzar manualmente al siguiente ejecutor. agent-pool traslada esa lógica a un demonio en segundo plano. Con create_pipeline se describen de antemano los pasos y las dependencias, y el proceso sigue vivo incluso tras reiniciar el IDE.

La idea clave no es solo lanzar un worker, sino dar a los agentes un lenguaje de coordinación. Al terminar una etapa, el ejecutor envía una señal de finalización, y si faltan datos, la tarea puede volver para corregirse con una explicación del motivo. Este bounce-back se parece a Request Changes en una revisión de código: el paso anterior completa el artefacto y lo devuelve a la cadena. Así el pipeline deja de ser un script lineal y pasa a ser un ciclo controlado con un límite de devoluciones.

«Un worker puede delegar tareas por su cuenta a otros: toda la

orquestación fractal se construye sobre esto».

El artículo describe los mecanismos principales de este esquema:

• on_complete — lanza el siguiente paso al terminar un worker concreto
• on_complete_all — espera a todo el grupo y hace fan-in antes de la siguiente etapa
• on_file — reacciona a la aparición de un archivo en disco
• signal_step_complete — informa al demonio de que el paso ha terminado de verdad
• bounce_back — devuelve la tarea, y maxBounces limita el número de ciclos

Cron y SSH

La programación es una función aparte. La herramienta schedule_task usa el formato cron habitual, de modo que se puede ejecutar un agente a diario o cada hora sin un planificador independiente. Un detalle importante: el demonio aplica bloqueos atómicos de archivos, así que, aunque se abran varias ventanas del IDE a la vez, una misma tarea se ejecuta una sola vez. Los resultados se guardan en la carpeta scheduled-results, por lo que el escenario sirve tanto para revisiones rutinarias de servidores como para generar informes semanales periódicos.

Si la máquina local se queda corta, los workers pueden enviarse a un servidor remoto por SSH. El runner se define en la configuración de agent-pool y, a partir de ahí, las tareas concretas se ejecutan en una máquina dedicada con Gemini CLI instalado. El sentido práctico es claro: las pruebas, la refactorización o el análisis masivo de código continúan aunque se cierre el portátil. El autor describe un flujo de trabajo típico así: los agentes trabajan en una rama aparte, hacen commits y suben el resultado, y por la mañana el desarrollador solo abre un pull request y revisa el resultado.

Contexto y control

Otro detalle útil es el traspaso de contexto entre agentes mediante las sesiones integradas de Gemini CLI. Un worker puede terminar una investigación y guardar un session_id, y el siguiente retoma la misma conversación y continúa sin que se le repita lo encontrado. En cadenas largas esto ahorra tokens y reduce los errores en las uniones entre etapas: el segundo agente ve no un resumen seco, sino el historial completo del análisis. Las sesiones activas pueden consultarse aparte y, si hace falta, conectarse a ellas manualmente.

También hay una capa de restricciones pensada para el trabajo real en equipo. Mediante policy se puede dar al agente un modo de solo lectura o de edición segura sin permiso para ejecutar comandos. Si no basta, las reglas se definen con más precisión en un archivo YAML aparte. El parámetro include_dirs completa este modelo: por defecto el worker solo ve el directorio de trabajo, y el acceso a configuraciones externas o carpetas adicionales debe activarse de forma explícita. Este enfoque hace la automatización bastante más segura que un acceso total e incondicional a todo el proyecto.

Por último, agent-pool introduce grupos, básicamente plantillas de equipos fractales. En un grupo se pueden guardar una sola vez el runner, la skill, la política y el límite max_agents, y luego enviar desde él varios ejecutores a la vez sin duplicar ajustes. Estos grupos persisten entre reinicios del IDE y se conectan directamente a los pipelines. Si un paso debe ejecutarse en paralelo, el demonio levanta varios agentes, les asigna índices y espera el resultado conjunto. Rige además el fail-fast: si un worker falla con un error o envía un bounce-back, el resto de procesos se cancela de inmediato para no gastar tiempo ni recursos en vano.

Qué significa

Para los desarrolladores, es una señal de que AgentOps empieza a pasar de los experimentos a las herramientas cotidianas. Cuando pipelines, planificador, runners remotos y control de permisos se reúnen en torno a una sola suscripción de Google AI, los escenarios multiagente dejan de ser una demostración y se convierten en infraestructura de trabajo para código, pruebas y automatización rutinaria.