Agent Swarm 1.169 encadena flujos hijos

Cuando una tarea no cabe en un único agente

Un agente aislado resuelve bien una petición concreta, pero se queda corto cuando el trabajo tiene dependencias. En un proyecto Laravel puedo necesitar revisar una incidencia, preparar un cambio, ejecutar la batería de pruebas, abrir una PR y esperar una validación antes de desplegar. Si cada parte se lanza por separado, el control acaba repartido entre conversaciones, scripts y tareas difíciles de reconstruir.

Agent Swarm ya dispone de un motor de workflows basado en DAGs, con nodos que se encadenan mediante next. Eso permite ejecutar pasos en paralelo, esperar convergencias y conservar checkpoints después de cada paso. El enfoque es más útil que pedir a un agente que improvise todo el proceso dentro de una única sesión.

La novedad de la versión 1.169.0 es el nodo sub-workflow. Su función es ejecutar otro workflow como ejecución hija y esperar a que termine antes de continuar. Si el flujo hijo falla o se cancela, también falla el nodo que lo invocó.

Un flujo principal para coordinar piezas pequeñas

La utilidad real está en dividir la automatización por responsabilidades. Un workflow principal puede encargarse de recibir un evento de GitHub o una ejecución programada, mientras que otros flujos se ocupan de tareas acotadas: revisar una PR, lanzar una comprobación de infraestructura o preparar una actualización de un servicio del homelab. El resultado es una composición de flujos que puedo leer y modificar sin convertir cada automatización en un prompt enorme.

Para Laravel, por ejemplo, separaría el pipeline de validación del pipeline de despliegue. El primero puede concentrar pruebas, análisis estático y revisión de cambios; el segundo puede depender de que esas comprobaciones terminen correctamente y detenerse ante una aprobación humana. No es que el sistema haga mágicamente mejores pruebas, sino que deja más claro qué se ejecuta, en qué orden y qué condición bloquea el siguiente paso.

Los workflows también admiten disparadores manuales, webhooks y referencias a tareas programadas. Las ejecuciones se guardan con sus pasos y contexto, y el motor puede reanudar desde el último checkpoint tras una caída. Esa persistencia es importante si el proceso toca repositorios, servicios internos o tareas que no conviene repetir a ciegas.

Workers en contenedores y no solo una API remota

Agent Swarm está planteado para ejecutar workers en Docker. La documentación oficial contempla Claude Code como proveedor por defecto y también soporta Codex, opencode, pi-mono, Devin, Claude Managed Agents y agentes compatibles con ACP. Cada worker usa un harness que gestiona la sesión y las credenciales del proveedor elegido.

La configuración con Docker Compose permite levantar la API y varios workers. Cuando varias réplicas comparten un mismo AGENT_ID, el sistema las trata como un único agente lógico para el enrutamiento de tareas y la política de capacidad. Si esos workers necesitan continuar trabajo sobre el mismo repositorio o los mismos ficheros generados, deben compartir un volumen persistente.

Este fragmento procede del patrón oficial de Compose para un agente con varias réplicas. Fija la imagen mediante AGENT_SWARM_VERSION, configura tres workers y monta un workspace compartido en /workspace/personal.

services:
  worker:
    image: ghcr.io/desplega-ai/agent-swarm-worker:${AGENT_SWARM_VERSION:-latest}
    depends_on:
      api:
        condition: service_healthy
    deploy:
      replicas: 3
    environment:
      API_KEY: ${API_KEY:?Set API_KEY in .env}
      AGENT_ID: ${AGENT_ID:?Set AGENT_ID in .env}
      AGENT_ROLE: worker
      CLAUDE_CODE_OAUTH_TOKEN: ${CLAUDE_CODE_OAUTH_TOKEN:?Set CLAUDE_CODE_OAUTH_TOKEN in .env}
      MCP_BASE_URL: http://api:3013
      TEMPLATE_ID: official/coder
    volumes:
      - shared_agent_workspace:/workspace/personal

Para una instalación propia, usaría una versión concreta en AGENT_SWARM_VERSION en lugar de seguir latest. Es una decisión básica, pero especialmente necesaria si el sistema participa en CI, despliegues o mantenimiento del homelab. Un cambio de imagen no debería modificar un pipeline nocturno sin que alguien lo haya probado antes.

Programar flujos y pedir confirmación

Las tareas programadas pueden crear tareas para agentes, disparar un workflow directamente o ejecutar un script guardado. Si lo que quiero iniciar ya está modelado como DAG, tiene sentido programar el workflow en lugar de abrir una tarea cuyo único texto sea “ejecuta tal flujo”. Así la programación queda separada del trabajo que realmente se ejecuta.

También hay nodos human-in-the-loop para pausar un workflow y pedir aprobación o información desde el dashboard. Esto encaja bien en operaciones que cambian el estado de un sistema: aplicar una migración, reiniciar una máquina, actualizar un contenedor o desplegar una release. La automatización puede preparar todo lo anterior, pero la decisión de ejecutar el paso sensible sigue siendo explícita.

En un homelab, ese punto de control evita que una tarea periódica convierta una detección en una acción destructiva. En CI, sirve para distinguir entre validar una rama y promover un cambio a producción. Son casos donde un agente puede reducir trabajo mecánico sin recibir carta blanca sobre la infraestructura.

La letra pequeña

Un sub-workflow no convierte un diseño confuso en un proceso fiable. Si los flujos hijo comparten recursos sin una política clara —un mismo entorno, una base de datos o un repositorio con cambios locales— el DAG solo hará más visible el problema. Hay que definir qué pasos pueden ir en paralelo, cuáles necesitan exclusión y qué salida produce cada uno.

Compartir AGENT_ID entre réplicas tampoco sincroniza automáticamente los archivos de los contenedores. La documentación advierte de que hay que montar un workspace persistente compartido cuando la continuación de una tarea depende del estado local. Si no puedo hacerlo, el trabajo debe poder reconstruirse desde el repositorio, el plano de control o los adjuntos de la tarea.

Tampoco usaría este sistema como sustituto de pruebas deterministas, copias de seguridad o revisiones de seguridad. Un worker aislado en Docker reduce el acoplamiento operativo, pero sigue manejando credenciales, código y potencialmente acceso a servicios internos. Conviene limitar permisos por worker, mantener secretos fuera de los prompts y reservar las aprobaciones humanas para acciones que realmente cambian producción.

Una forma más mantenible de usar agentes

La parte interesante de esta versión no es tener otro nodo más en un editor visual. Es poder tratar a los agentes como una parte de un proceso definido: uno hace una tarea acotada, un workflow hijo agrupa una fase y el flujo principal decide cuándo seguir. Eso se parece más a operar software que a lanzar asistentes independientes y esperar que coordinen bien.

Para proyectos con Laravel, CI y servicios autoalojados, ese modelo permite empezar por algo pequeño y medible. Un workflow para validar una PR, otro para revisar el estado de contenedores y un tercero que los coordine cuando haga falta. Si el proceso no se entiende sin pedir explicaciones al agente, todavía no está listo para automatizarse.

Fuente: https://github.com/desplega-ai/agent-swarm/releases Documentación oficial: https://docs.agent-swarm.dev/docs