Orquestación multi-agente: cuándo y cómo coordinar múltiples agentes de IA

Los sistemas multi-agente generan mucho entusiasmo y, a menudo, mucha sobreingeniería innecesaria. Un sistema con 5 agentes coordinados no es automáticamente mejor que un agente bien diseñado. A veces es más caro, más frágil y más difícil de depurar.

Esta guía explica cuándo los sistemas multi-agente tienen sentido real, cómo funcionan los patrones principales y qué herramientas se usan en producción.

Cuándo usar múltiples agentes

La pregunta correcta no es "¿puedo usar múltiples agentes?" sino "¿qué problema resuelve tener varios agentes que uno no resuelve?"

Razones válidas para sistemas multi-agente:

1. Especialización genuina por dominio Si una tarea requiere expertise en áreas muy distintas que no caben bien juntas en un solo system prompt, los agentes especializados producen mejores resultados. Ejemplo: un sistema de análisis de contratos donde un agente se especializa en cláusulas legales, otro en implicaciones financieras y otro en riesgos operativos.

2. Contextos demasiado grandes para una sola llamada Si el flujo de trabajo requiere manejar volúmenes de información que superan la context window de cualquier modelo, los agentes paralelos que procesan partes distintas y luego se coordinan son la solución natural.

3. Paralelización genuina Cuando el tiempo de respuesta importa y las subtareas son independientes. Tres agentes en paralelo que cada uno investiga un aspecto distinto terminan antes que un agente que los hace en secuencia.

4. Separación de responsabilidades por seguridad En sistemas donde diferentes roles tienen distintos niveles de acceso, separar los agentes permite controlar qué herramientas y datos tiene disponibles cada uno.

Razones que NO justifican múltiples agentes:

• "Así parece más avanzado"
• "Quiero que cada agente tenga una personalidad"
• El problema puede resolverse con un sistema prompt bien estructurado
• El equipo no tiene capacidad para mantener la complejidad adicional

Los 4 patrones de coordinación

Patrón 1: Orchestrator-Worker

Un agente orquestador recibe la tarea, la descompone en subtareas y las delega a agentes worker especializados. Los workers devuelven sus resultados al orquestador, que los combina en el output final.

Tarea → Orquestador
           ├→ Worker A (especialista en X)
           ├→ Worker B (especialista en Y)
           └→ Worker C (especialista en Z)
        → Combinar resultados → Output

Cuándo usarlo: Tareas complejas que se descomponen naturalmente en subtareas especializadas.

Ejemplo: Sistema de due diligence

• Orquestador: recibe la empresa objetivo, decide qué investigar
• Worker financiero: analiza estados financieros
• Worker legal: revisa registros públicos y litigios
• Worker mercado: analiza la competencia y el sector
• Orquestador: combina en informe final

Riesgo principal: Si el orquestador no descompone bien la tarea, o si los workers no coordinan correctamente la información de contexto, el resultado puede ser peor que un agente único con buenas herramientas.

Patrón 2: Agentes en paralelo

Múltiples agentes independientes reciben el mismo input (o partes del mismo input) y trabajan simultáneamente. No se comunican entre sí durante la ejecución.

Input → [Agente 1] ─┐
Input → [Agente 2] ─┼→ Combinar → Output
Input → [Agente 3] ─┘

Cuándo usarlo: Cuando necesitas múltiples perspectivas sobre el mismo problema, o cuando tienes que procesar muchos items independientes con rapidez.

Ejemplo: Evaluación de propuestas

• 3 agentes evalúan la misma propuesta con criterios distintos (técnico, económico, estratégico)
• Sus evaluaciones se combinan en una puntuación ponderada

Variante: Ensemble + votación En clasificación o decisiones binarias, lanzar 3 agentes con el mismo prompt (o variaciones) y tomar la respuesta mayoritaria reduce los errores.

Patrón 3: Handoff secuencial

Los agentes trabajan en secuencia, cada uno recibiendo el output del anterior como contexto adicional. Especialización encadenada.

Input → Agente A → [output A] → Agente B → [output B] → Agente C → Output

Cuándo usarlo: Cuando la tarea tiene fases claramente diferenciadas donde el contexto se acumula y enriquece en cada paso.

Ejemplo: Pipeline editorial

1. Agente investigador: busca fuentes, extrae hechos relevantes
2. Agente redactor: escribe el artículo basado en la investigación
3. Agente editor: revisa y mejora el artículo del redactor

Cada agente tiene un rol claro y recibe el trabajo de su predecesor.

Diferencia con pipeline secuencial: En el patrón de agentes en handoff, cada paso es un agente con herramientas propias y un system prompt especializado. En un pipeline simple, cada paso es solo un prompt diferente.

Patrón 4: Debate y crítica (Critic Agent)

Un agente genera una respuesta. Otro agente (el "crítico") evalúa esa respuesta y proporciona feedback. El proceso se repite hasta que el crítico aprueba o se alcanza el límite de iteraciones.

Input → Agente generador → Borrador
                              ↓
Agente crítico: ¿Es correcto? ← Revisar con feedback
      ↓ Sí
    Output final

Cuándo usarlo: Cuando la calidad importa más que la velocidad, y cuando el dominio tiene criterios objetivos de evaluación.

Ejemplo: Validación de código

1. Agente generador escribe el código
2. Agente crítico revisa: ¿hay bugs? ¿maneja los edge cases? ¿sigue el estilo?
3. Si hay problemas, el generador los corrige y vuelve a 2

Riesgo: Los dos agentes pueden entrar en un acuerdo sin resolver el problema real ("sycophancy"). El crítico necesita un prompt que lo incentive a ser genuinamente exigente.

Herramientas para sistemas multi-agente

LangGraph: El estándar para sistemas multi-agente en Python. Gestiona el estado compartido entre agentes, los handoffs y los puntos de human-in-the-loop. Curva de aprendizaje notable pero es la opción más madura para producción.

Anthropic Agent SDK: SDK nativo de Anthropic con soporte explícito para orquestación. Más ligero que LangGraph, ideal si ya usas Claude.

CrewAI: Framework de más alto nivel donde defines "crews" (equipos de agentes) con roles y objetivos. Más fácil de comenzar, menos control fino.

AutoGen (Microsoft): Permite conversaciones entre múltiples agentes con configuración flexible. Bueno para prototipado.

Código propio: Para sistemas con patrones simples (paralelo, handoff secuencial), implementarlo directamente en Python/TypeScript con asyncio es a menudo la solución más limpia y mantenible.

Los riesgos reales

Cascadas de errores: Un error en el agente A se propaga al agente B y se amplifica. En sistemas multi-agente, los errores son más difíciles de depurar porque el contexto del fallo puede estar distribuido entre varios agentes.

Costes descontrolados: Cada agente adicional multiplica el número de llamadas a la API. Un sistema de 5 agentes puede costar 5-10x más que un agente único equivalente.

Latencia acumulada: Los handoffs secuenciales acumulan la latencia de cada paso. Lo que parecía una optimización puede resultar en un sistema más lento para el usuario.

Dificultad de evaluación: ¿Cómo mides si el sistema multi-agente funciona bien? Las evals para sistemas distribuidos son más complejas que para un agente único.

Regla de oro

Empieza con un agente bien diseñado. Solo pasa a múltiples agentes cuando tengas evidencia concreta de que el agente único no puede resolver el problema — no por anticipación, sino por datos reales de producción.

Los mejores sistemas multi-agente que existen en producción son los más simples posibles para el problema que resuelven. No los más elaborados.

---

Recursos relacionados:

• Los 5 patrones de arquitectura de workflow de IA — patrones fundamentales antes de multi-agente
• Chatbot vs agente de IA — cuándo necesitas un agente vs un sistema más simple
• Cómo diseñar un agente de IA — dominar el agente único antes de escalar a varios
• Canvas de diseño de agente — herramienta para diseñar la arquitectura del sistema