Se lanzó agent-pool para Google AI y Gemini CLI con pipelines, cron y bounce-back

Google AI y Gemini CLI ahora cuentan con una nueva capa de orquestación de agentes de código abierto. El servidor agent-pool MCP recopila delegaciones dispersas en pipelines, puede devolver tareas para revisión, ejecutarlas según programación y descargar la ejecución en máquinas remotas.

Orquestación Automática

El problema que enfrenta casi todo escenario multiagente es simple: el agente principal dedica demasiado tiempo a no trabajar, sino a despacho. Si los pasos dependen unos de otros—análisis, refactorización, pruebas, deploy—el orquestrador debe sondear estados, analizar respuestas e iniciar manualmente el siguiente ejecutor. Agent-pool traslada esta lógica a un daemon de fondo.

A través de create_pipeline, los pasos y dependencias se describen con anticipación, y el proceso en sí permanece vivo incluso después de reiniciar el IDE. La idea clave no es simplemente ejecutar un worker, sino dar a los agentes un lenguaje de coordinación. Después de completar una etapa, el ejecutor envía una señal de disposición, y si faltan datos, la tarea puede devolverse para revisión con una explicación.

Este bounce-back es similar a Request Changes en code review: el paso anterior complementa el artefacto y lo devuelve a la cadena. Esto convierte el pipeline no en un script lineal, sino en un bucle gestionado con límite en el número de devoluciones.

"Un worker puede delegar tareas por su cuenta—en esto se construye

toda la orquestación fractal."

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

• on_complete—inicia el siguiente paso después de que se complete un worker específico
• on_complete_all—espera todo el grupo y realiza un fan-in antes de la siguiente etapa
• on_file—reacciona a la aparición de un archivo en el disco
• signal_step_complete—informa al daemon que el paso se completó verdaderamente
• bounce_back—devuelve la tarea, y maxBounces limita el número de ciclos

Cron y SSH

La programación se maneja por separado. La herramienta schedule_task utiliza formato cron estándar, por lo que un agente puede configurarse para ejecutarse diariamente u cada hora sin un programador separado. Importante: el daemon establece bloqueos de archivo atómicos: incluso si abre múltiples ventanas del IDE simultáneamente, la misma tarea se ejecutará una sola vez.

Los resultados se almacenan en una carpeta scheduled-results, por lo que el escenario puede usarse tanto para verificaciones rutinarias de servidores como para compilación periódica de reportes semanales. Si una máquina local no es suficiente, los workers pueden enviarse a un servidor remoto a través de SSH. El runner se describe en la configuración agent-pool, después de lo cual tareas específicas comienzan a ejecutarse en una máquina dedicada con Gemini CLI instalado.

El valor práctico es claro: las pruebas, refactorización o análisis masivo de código continúan incluso después de cerrar el portátil. El autor describe un flujo de trabajo típico: los agentes trabajan en una rama separada, hacen commits, envían resultados, y por la mañana el desarrollador simplemente abre un pull request y revisa el resultado.

Contexto y Control

Otro detalle útil es pasar contexto entre agentes a través de las sesiones integradas de Gemini CLI. Un worker puede terminar una investigación, guardar la session_id, y el siguiente puede retomar la misma conversación y continuar sin repetir lo encontrado. Para cadenas largas, esto ahorra tokens y reduce errores en los límites entre etapas: el segundo agente ve no un resumen seco, sino el historial completo de análisis.

Las sesiones activas pueden verse por separado y conectarse manualmente si es necesario. También hay una capa de restricciones necesaria para trabajo real en equipo. A través de policy, puede darse a un agente modo de solo lectura o edición segura sin derecho a ejecutar comandos.

Si eso no es suficiente, las reglas se establecen con más precisión a través de un archivo YAML separado. El parámetro include_dirs complementa este modelo: por defecto un worker ve solo el directorio de trabajo, y el acceso a configuraciones externas o carpetas adicionales debe habilitarse explícitamente. Este enfoque hace la automatización significativamente más segura que el acceso total incondicional a todo el proyecto.

Finalmente, agent-pool introduce grupos—esencialmente plantillas para equipos fractales. Puede registrar un runner, skill, policy y límite max_agents en un grupo una vez, luego enviar múltiplos ejecutores desde él sin duplicar configuraciones. Estos grupos se guardan entre reinicios del IDE y se conectan directamente a los pipelines.

Si un paso debe ejecutarse en paralelo, el daemon levantará múltiplos agentes, distribuirá índices entre ellos y esperará un resultado común. Fail-fast se aplica: si un worker falla con error o envía un bounce-back, otros procesos se cancelan inmediatamente para evitar desperdiciar tiempo y recursos.

Lo Que Esto Significa

Para desarrolladores, esta es una señal de que AgentOps está pasando del nivel de experimentos al nivel de herramientas cotidianas. Cuando pipelines, programador, runners remotos y control de acceso se reúnen alrededor de una única suscripción a Google AI, los escenarios multiagente se convierten no en una demostración, sino en infraestructura funcional para código, pruebas y automatización rutinaria.