5 patrones multiagente que realmente funcionan

Después de meses construyendo y usando flujos de trabajo multiagente, ciertos patrones siguen demostrando su valor. No son teóricos: son patrones que usamos a diario y que vemos adoptar a otros desarrolladores de forma consistente.

Aquí van cinco que realmente funcionan en la práctica.

1. El pipeline de revisión de código

Configuración: dos tiles de terminal, conectados en una sola dirección.

Agente escritor → Agente revisor

Cómo funciona: el agente escritor implementa una funcionalidad o una corrección. Cuando termina, la salida se enruta al agente revisor con un prompt como "Revisa los cambios en src/auth/ por corrección, problemas de seguridad y casos límite."

Por qué funciona: los agentes de IA detectan cosas distintas según el contexto de su prompt. Un agente escritor optimiza la corrección y la finalización. Un agente revisor, con criterios de revisión explícitos, detecta problemas que la visión en túnel del escritor pasó por alto.

Consejo: usa el trigger on-idle con una ventana de silencio de 8 segundos. Así te aseguras de que el escritor ha terminado de verdad antes de que empiece la revisión. Define una palabra de parada como "LGTM" para que el bucle se termine cuando el revisor apruebe.

Ciclo típico: 1 pasada de escritura + 1 o 2 rondas de revisión. Suele converger en menos de 10 minutos para un cambio focalizado.

2. El generador de pruebas

Configuración: un agente de implementación y un agente de escritura de pruebas.

Agente de implementación → Agente de pruebas

Cómo funciona: el agente de implementación construye o modifica una funcionalidad. Al terminar, el sistema de enrutamiento envía los cambios de archivos y un prompt al agente de pruebas: "Escribe pruebas unitarias para los cambios hechos en el middleware de autenticación. Cubre el camino feliz, los casos de error y los casos límite."

Por qué funciona: escribir pruebas justo después de implementar, cuando el código sigue fresco, detecta errores en el momento más barato posible. El agente de pruebas tiene el contexto completo de qué cambió y por qué.

Variación: invierte la dirección: escribe primero las pruebas (estilo TDD) y luego enruta las especificaciones de prueba al agente de implementación.

3. El constructor paralelo de módulos

Configuración: varios tiles de terminal, sin conexiones. Una tile de notas en el centro para coordinar.

Agente A (auth)    Agente B (api)    Agente C (database)
      \               |               /
       \              |              /
        Nota: Architecture Plan

Cómo funciona: divides una tarea grande en módulos independientes. Cada agente recibe un módulo específico con fronteras de interfaz claras. La tile de notas contiene el plan de arquitectura compartido y los contratos de interfaz que todos los agentes consultan.

Por qué funciona: este es el patrón de mayor rendimiento. Tres agentes trabajando en módulos independientes terminan 3 veces más rápido que uno trabajando en secuencia. La clave es definir interfaces limpias desde el principio para que los módulos encajen sin fricción.

Cuándo evitarlo: si los módulos tienen acoplamiento fuerte o estado compartido, los agentes se pisarán entre sí. Reserva este patrón para trabajos realmente independientes con interfaces bien definidas.

4. El bucle de refinamiento iterativo

Configuración: dos agentes conectados bidireccionalmente con límites de rondas.

Agente A ⇄ Agente B (max 3 rounds)

Cómo funciona: el Agente A hace un primer intento. El Agente B lo critica y sugiere mejoras. El Agente A revisa en función del feedback. Y así sucesivamente durante un número fijo de rondas, normalmente 2 o 3.

Por qué funciona: cada ronda aprieta un poco más la solución. La primera pasada consigue la estructura. La segunda detecta errores y casos límite. La tercera pule. A partir de 3 rondas, la mejora marginal cae en picado: ajusta el máximo en consecuencia.

Configuración: usa la transformación ai-routing para que el feedback de cada agente se reformule como una instrucción accionable, no como salida cruda. Define maxRounds: 3 y cooldownMs: 5000 para darle a cada agente tiempo suficiente de producir una respuesta completa.

Ejemplos de prompts:

• Ronda 1 (A→B): "Revisa esta implementación del limitador de tasa en cuanto a corrección y rendimiento."
• Ronda 2 (B→A): "Aplica estas correcciones: [problemas específicos]. Luego verifica que la corrección maneja el caso de acceso concurrente."
• Ronda 3 (A→B): "Revisión final del limitador de tasa revisado. Aprueba con LGTM si está listo para producción."

5. El explorador y el constructor

Configuración: un agente ligero y rápido explora la base de código; un agente más capaz construye.

Agente explorador → Agente constructor

Cómo funciona: el agente explorador (usando un modelo más pequeño, más rápido o prompts más simples) explora la base de código para responder preguntas preliminares: "¿Qué archivos intervienen en el flujo de pagos? ¿Qué patrones usa la base de código para el manejo de errores? ¿Qué pruebas existen para el módulo de facturación?"

Una vez que el explorador ha reunido contexto, sus hallazgos se enrutan al constructor con la tarea real de implementación, ya enriquecida con contexto específico de la base de código.

Por qué funciona: las tareas grandes de implementación suelen fallar porque el agente no tiene suficiente contexto sobre la base de código existente. La fase de exploración es barata (modelo rápido, operaciones de solo lectura) y produce el mapa de contexto que hace precisa la tarea del constructor.

Consejo: usa la transformación full-output para este patrón. La salida del explorador ya es información estructurada (listas de archivos, descripción de patrones) que el constructor puede consumir directamente sin reformulación por IA.

Elegir el patrón adecuado

Estos patrones se combinan. Un flujo real podría usar el Explorador y constructor para reunir contexto, el Constructor paralelo de módulos para implementar y el Pipeline de revisión de código para validar, todo en el mismo canvas.

Antipatrones que debes evitar

El bucle infinito: dos agentes enroutados entre sí sin límites de rondas ni palabras de parada. Acabarán generando meta-comentarios cada vez más abstractos. Define siempre maxRounds.

La ensalada de conexiones: enrutar la salida de todos los agentes a todos los demás. Demasiada información. Cada conexión debe tener un propósito claro.

El enrutador prematuro: montar un enrutamiento complejo para una tarea que se resuelve en 2 minutos con un solo agente. La sobrecarga de configurar conexiones no merece la pena para tareas simples y autocontenidas.

Los mejores flujos multiagente parecen sin esfuerzo: agentes trabajando en paralelo, salidas fluyendo hacia donde se necesitan y tú tomando las decisiones estratégicas mientras la ejecución ocurre a tu alrededor.