Construir un solo agente de IA es relativamente sencillo. Le das un prompt, le conectas unas herramientas y listo. Pero cuando necesitas que múltiples agentes colaboren para resolver un problema complejo —un proceso de onboarding, un pipeline de análisis de datos, un sistema de atención al cliente con escalamiento automático— la arquitectura se vuelve el factor crítico.

Los equipos de ingeniería caen una y otra vez en los mismos errores: acoplamiento excesivo entre agentes, estado compartido que se corrompe, bucles infinitos de llamadas entre sí, timeouts que no están contemplados. La solución no es un mejor prompt. Es una arquitectura bien pensada.

“Cuando un solo agente basta, úsalo. Cuando necesites más de uno, diseña como si estuvieras construyendo un sistema distribuido, porque eso es exactamente lo que estás haciendo.”

¿Cuándo necesitas una arquitectura multi-agente?

Antes de llegar a los patrones, hay una pregunta que todo equipo debería responderse primero: ¿realmente necesitas varios agentes?

La respuesta es sí cuando:

  • El problema tiene dominios claramente separados: autenticación, facturación y soporte no deberían vivir en el mismo agente.
  • Hay pasos que requieren aprobación humana: un agente propone, otro ejecuta solo si hay validación externa.
  • La escalabilidad horizontal es necesaria: distintos agentes pueden escalar de forma independiente según la carga.
  • Las herramientas son conflictivas: un agente con acceso a escritura en base de datos y a envío de emails puede causar estragos si no está bien acotado.

Si tu caso no encaja en ninguna de estas, probablemente un solo agente bien diseñado sea suficiente.

Patrón 1: Supervisor-Operario (Supervisor-Worker)

Este es el patrón más usado en producción. Un agente supervisor recibe la solicitud de alto nivel, la descompone en subtareas y las delega a agentes operarios especializados. Cada operario ejecuta su tarea con herramientas propias y reporta resultados al supervisor, que consolida la respuesta final.

Cuándo usarlo: tareas complejas con múltiples pasos bien definidos como generación de informes, análisis de datos multi-fuente o procesamiento de documentos.

Implementación práctica:

  • El supervisor mantiene una cola de tareas pendientes y un registro de resultados.
  • Los operarios son stateless: reciben una tarea, la ejecutan, devuelven el resultado.
  • El supervisor decide si el resultado es suficiente o necesita otra iteración.
  • Timeout global: si un operario no responde en N segundos, el supervisor reasigna o falla gracefully.

Patrón 2: Pipeline Secuencial con Handoff

Los agentes se organizan en una cadena donde cada uno recibe el output del anterior. Este patrón es ideal para procesos lineales como moderación de contenido, transformación de datos o pipelines editoriales.

Ejemplo concreto: Un pipeline de publicación de contenido podría tener:

  1. Agente escritor: genera el borrador inicial.
  2. Agente revisor: verifica hechos, tono y coherencia.
  3. Agente SEO: optimiza keywords y metadescripción.
  4. Agente publicador: sube el contenido y notifica.

Peligro común: el error se propaga. Si el escritor produce algo incorrecto, los agentes subsiguientes lo heredan. La solución es que cada agente valide su entrada antes de procesarla, y que exista un mecanismo de rollback.

Patrón 3: Enrutador Inteligente (Router-Orchestrator)

Un agente enrutador analiza la solicitud entrante y la dirige al agente especializado correspondiente. Este patrón es el estándar para sistemas de atención al cliente, motores de búsqueda verticales y asistentes multi-dominio.

La clave del enrutador:

  • Clasifica la intención con alta precisión.
  • Define criterios claros de routing: si hay ambigüedad, pregunta al usuario antes de asignar.
  • Cada agente especializado tiene un subconjunto reducido de herramientas, lo que mejora la precisión y reduce costos de inferencia.

En producción: el enrutador debe tener un fallback —un agente “generalista”— para cuando la clasificación tiene baja confianza.

Patrón 4: Pizarra Compartida (Shared Blackboard)

Los agentes no se comunican directamente. En su lugar, leen y escriben en un espacio de estado compartido. Este patrón es menos común pero extremadamente útil cuando los agentes trabajan en paralelo sobre el mismo problema.

Cómo implementarlo:

  • Una estructura de datos centralizada (Redis, una base de datos en memoria o incluso un archivo JSON para prototipos).
  • Cada agente monitorea la pizarra en busca de tareas o datos que pueda procesar.
  • Cuando un agente completa su trabajo, escribe el resultado y actualiza el estado.
  • Un coordinador ligero detecta cuándo el problema está resuelto y consolida el resultado.

Ventaja: desacoplamiento total. Puedes agregar o quitar agentes sin modificar a los demás. Desventaja: el estado compartido es el cuello de botella y un punto único de fallo.

Errores comunes al llevar multi-agente a producción

1. Confundir paralelismo con concurrencia. Que dos agentes puedan trabajar al mismo tiempo no significa que deban hacerlo siempre. La coordinación tiene un costo. Mide antes de paralelizar.

2. Ignorar los límites de rate (rate limiting). Si todos tus agentes comparten la misma API key de OpenAI o Anthropic, las llamadas simultáneas pueden saturar el rate limit. Cada agente debería tener su propia lógica de throttling.

3. Manejo de errores insuficiente. En un sistema multi-agente, un error en un agente no debería colapsar el sistema completo. Implementa circuit breakers, reintentos con backoff exponencial y colas de mensajes muertos (dead letter queues).

4. Ausencia de observabilidad. Si no puedes responder preguntas como “¿qué agente procesó este paso?”, “¿cuánto tiempo tomó?” y “¿dónde falló?”, no tienes un sistema multi-agente en producción. Tienes una caja negra.

Recomendaciones finales

  1. Empieza con un solo agente. Añade complejidad solo cuando el problema lo exija.
  2. Define contratos claros entre agentes. Cada interacción debe tener un formato esperado de entrada y salida. Typed interfaces > prompts sueltos.
  3. Prueba cada agente de forma aislada. Unit tests para agentes individuales, integration tests para el flujo completo.
  4. Mide antes de optimizar. El patrón Supervisor-Operario introduce latencia. A veces un Pipeline Secuencial es más rápido aunque suene menos elegante.
  5. Siempre ten un kill switch. Un mecanismo para detener todos los agentes de forma segura ante comportamientos inesperados.

La arquitectura de sistemas multi-agente está evolucionando rápido. Lo que hoy consideramos un patrón avanzado, mañana será un componente estándar en cualquier stack de IA. Mantenerse al día con estas prácticas no es opcional si quieres construir sistemas que realmente funcionen en producción.

Sigue explorando estos temas en el blog de DojoFullStack, donde compartimos experiencias reales de ingeniería con agentes de IA, automatización inteligente y desarrollo de software moderno.