Construir flujos de trabajo multiagente con MadoHub

Ejecutar un solo agente de IA es sencillo. Ejecutar cinco agentes que dependen de la salida de los demás es donde las cosas se ponen interesantes, y donde la mayoría de las herramientas se quedan cortas.

Esta entrada explica cómo construir un flujo de trabajo multiagente en MadoHub, desde la disposición de tiles hasta la configuración de reglas de enrutamiento.

Empieza por la salida

Antes de colocar ninguna tile en el canvas, decide cuál debe ser la salida final. Trabajar hacia atrás desde el resultado te obliga a pensar qué pasos intermedios hacen falta.

Por ejemplo, supón que quieres generar un endpoint de API probado y documentado. La salida final es un pull request con la implementación, las pruebas y la documentación. Trabajando hacia atrás:

• Un agente compositor de PR ensambla la salida final
• Un agente escritor de pruebas produce los archivos de prueba
• Un agente escritor de documentación genera la documentación de la API
• Un agente generador de código escribe la implementación
• Un agente parser de especificación extrae requisitos de una descripción en lenguaje natural

Colocar tiles en el canvas

Cada agente recibe una tile. En MadoHub, las tiles son entornos de ejecución independientes: cada una funciona en su propio contexto con su propia configuración de modelo y su propio prompt del sistema.

Coloca el parser de especificación a la izquierda del canvas y el compositor de PR a la derecha. Los agentes intermedios van entre medias, aproximadamente en el orden de ejecución. Este diseño de izquierda a derecha refleja cómo fluye la información por el sistema.

Definir conexiones

Las conexiones son aristas dirigidas entre tiles. Cuando dibujas una conexión desde el puerto de salida del parser de especificación al puerto de entrada del generador de código, le estás diciendo a MadoHub que lleve la especificación analizada al prompt de generación de código.

Una tile puede tener varias entradas. El escritor de pruebas podría recibir tanto la especificación analizada como el código generado, de modo que pueda escribir pruebas que coincidan con la especificación y ejerciten la implementación real.

Estrategias de enrutamiento

No todas las conexiones deben dispararse en el momento en que aparece la salida del agente upstream. Cada conexión en MadoHub tiene un trigger:

• on-complete: se dispara cuando se detecta que la sesión del agente upstream se ha completado
• on-idle: se dispara cuando el terminal del agente upstream queda inactivo
• on-keyword: se dispara cuando aparece una palabra clave configurada en la salida upstream
• always: se dispara con cada nuevo fragmento de salida, sin necesidad de ninguna señal de finalización

Por debajo, on-complete y on-idle se gestionan de la misma manera: ambos esperan un breve temporizador de inactividad (unos 8 segundos) tras su señal desencadenante antes de enrutar. Piensa en ellos como la misma pausa con dos motivos distintos para iniciarla, no como dos estrategias independientes.

Cada conexión también tiene un transform, que controla lo que realmente se envía downstream: raw (las últimas líneas tal cual), summary (un resumen generado por IA), full-output (una ventana reciente más amplia), prompt-wrap (tu propia plantilla con variables como {output} y {round}), o ai-routing (un prompt generado por IA y consciente del contexto, que requiere tener configurada una API key).

Para nuestro flujo de trabajo de API, podrías configurar la conexión del parser de especificación al generador de código como on-complete con un transform full-output, y luego configurar las conexiones del generador de código hacia el escritor de pruebas y el de documentación como on-complete con un transform raw: ambos agentes downstream arrancan en cuanto la sesión del generador de código se reporta como terminada, trabajando sobre la misma salida reciente.

Gestionar fallos

Los agentes fallan. Los modelos alucinan. Las salidas no siempre coinciden con lo esperado. Un flujo multiagente robusto necesita barreras de protección para que un bucle enrutado no se ejecute indefinidamente.

La protección contra bucles de MadoHub funciona por rondas en lugar de validar la salida: cada conexión enrutada tiene un límite maxRounds (5 por defecto, configurable de 1 a 20) y un cooldown entre rondas (3 segundos por defecto, configurable hasta 30) para que un agente downstream no pueda volver a dispararse más rápido de lo que realmente puede responder. También puedes definir un stopKeyword —cualquier subcadena que no distingue mayúsculas de minúsculas, como "LGTM"— y el bucle se detiene en cuanto la salida de un agente lo contiene.

Así es exactamente como funciona el flujo integrado Peer review de MadoHub: un autor Claude Code y un revisor Codex están conectados en un bucle con el stopKeyword configurado como "LGTM" —el revisor sigue enviando feedback hasta que lo dice, y ahí se detiene el bucle. El flujo integrado Pipeline es más simple: un traspaso de dos etapas en el que el full-output del primer agente alimenta al segundo al completarse. El flujo integrado Watcher está impulsado por palabras clave de principio a fin, usando el transform ai-routing para convertir una frase coincidente en un prompt de seguimiento consciente del contexto.

La iteración es la clave

La verdadera ventaja de los flujos multiagente basados en canvas es la velocidad de iteración. Añadir un nuevo agente - por ejemplo, un revisor de seguridad entre el generador de código y el compositor de PR - lleva segundos. Colocas un tile, dibujas dos conexiones y el flujo se actualiza.

Pruébalo en un sistema de pipeline como código. Tendrías que editar archivos de configuración, reiniciar procesos y confiar en que el esquema sigue validando. En el canvas, el bucle de feedback es inmediato.