Por qué construimos un orquestador, no más reglas de enrutamiento
Las reglas estáticas de disparador/transformación escalan mal cuando tu lienzo crece más allá de un par de agentes. Aquí va por qué MadoHub ahora enruta a través de un bucle real de llamada a herramientas — y cuándo todavía deberías usar reglas.
Durante la mayor parte de la vida de MadoHub, el enrutamiento entre agentes fue un motor de reglas. Una conexión tenía un disparador (on-idle, on-complete, on-keyword, always), una transformación (AI routing, prompt-wrap, full-output, raw, summary) y knobs de protección de bucle. La configurabas una vez y se disparaba igual cada vez. Ese modelo sigue existiendo — es lo que documentan Enrutamiento de agentes y Flows, y sigue siendo la forma más rápida de cablear dos tiles para un patrón conocido como peer review. Pero tiene un problema de escalado del que vale la pena ser específico.
El problema no es ninguna regla concreta. Es la cuenta.
Una conexión con "on idle → prompt-wrap" es fácil de razonar: ¿terminó la fuente? Si sí, reenvíalo. El problema empieza cuando el lienzo crece más allá de un par de tiles y las conexiones dejan de ser independientes.
Con cinco agentes y ocho conexiones, cada regla interactúa con cada otra regla. ¿La salida de A cuenta como coincidencia de palabra clave para el disparador on-keyword de B? ¿Debería C esperar al cooldown de D para que el mismo objetivo no se golpe dos veces en un segundo? Ninguna tiene respuestas incorrectas — puedes resolver cualquiera añadiendo otro tipo de disparador, transformación o flag de prioridad. Pero cada respuesta es una regla nueva, y las reglas no se componen, se multiplican. Una topología con N agentes no necesita N reglas, necesita algo más cercano a N² de manejo de casos extremos, porque una regla no tiene modelo de lo que está pasando en el resto del lienzo — compara patrones sobre el texto de salida y se dispara a ciegas.
Ese es el argumento real para un orquestador: no que las reglas sean malas, sino que una regla fija no puede mirar al resto del espacio de trabajo antes de decidir qué hacer, y un espacio de trabajo con más de un par de agentes necesita cada vez más exactamente eso.
Cómo lo gestiona MadoHub
Un bucle de herramientas, no una regla más grande
La alternativa no es "añade una transformación de IA" — MadoHub ya tenía eso. Es darle al decisión de enrutamiento acceso al espacio de trabajo. Por defecto, una conexión disparada ahora abre un sub-turn de MadoAgent: un bucle real de llamada a herramientas que mira una instantánea de tu lienzo — cada tile, el disparador y transformación y estado de ronda de cada conexión, salida reciente — y toma una decisión de enrutamiento, y luego para.
Esa decisión es estrecha a propósito: puede leer archivos, comprobar git status, listar conexiones, inspeccionar el historial de enrutamiento, buscar sesiones y recuperar memoria, más tomar exactamente una acción — reenviar el mensaje, o saltarlo. No puede reescribir tu lienzo, mutar conexiones ni correr workflows. La instrucción es simple: reenviar cuando hay contenido sustantivo (un plan, código, una revisión), saltar cuando la salida de la fuente es solo una pregunta al usuario o charla vacía. Una juicio contra la conversación real, no una coincidencia de patrones.
La protección de bucle sigue aplicándose, independientemente de la ruta
Sustituir un dispatcher determinista por una llamada a un modelo no es un cambio que haces con confianza total el primer día, así que las salvaguardas del sistema basado en reglas se mantienen sin cambios. La protección de bucle limita cuántos ciclos corre una conexión antes de auto-desactivarse (predeterminado 5), impone un hueco mínimo entre disparadores (predeterminado 3 segundos) y puede terminar el bucle en el momento en que aparece una stop keyword como LGTM. Un sub-turn que decide reenviar en cada ronda sigue sin poder descontrolarse — el límite y el cooldown se aplican de forma independiente a su decisión.
Modo shadow, para construir confianza
Si quieres probar la ruta nueva sin cambiar el comportamiento, el modo shadow corre el router legacy en vivo y su decisión es lo que se reenvía — el comportamiento orientado al usuario no cambia — mientras un sub-turn de MadoAgent corre en paralelo sobre el mismo disparador, puramente como señal de comparación. Puedes ver dónde la ruta nueva coincide con la vieja en tráfico real antes de confiarle la llamada en vivo. La ruta legacy sigue seleccionable en Configuración durante el tiempo que haga falta para construir esa confianza.
Guía práctica
- Usa Flows para formas buenas conocidas. Los tres integrados (Peer review, Pipeline, Watcher) siguen siendo conjuntos fijos de reglas, porque una plantilla soltada para un patrón repetible no debería ser segunda-guessada por un modelo en cada disparo.
- Usa el orquestador para topologías a medida o grandes. Cuando ningún conjunto fijo de reglas describe bien tu lienzo, un bucle de llamada a herramientas que puede mirar el resto del espacio de trabajo antes de decidir generaliza mejor que otra regla.
- Usa cableado manual para precisión puntual. Arrastrar una conexión entre dos tiles sigue siendo el camino más rápido cuando quieres control total sobre un único enlace y no necesitas plantilla ni conversación.
- Mantén la protección de bucle activada. Un LLM en el bucle de enrutamiento puede juzgar mal si la salida es sustantiva, saltar algo que una regla habría reenviado, y añadir un round-trip de latencia y tokens que una coincidencia de plantilla no tiene. La protección de bucle y la puerta de entrega garantizan que una decisión equivocada no pueda en espiral hacia un bucle sin límite, y que un reenvío no pueda ser tragado en silencio por un tile que ya no está para recibirlo.