Patrones de sistemas multiagente

Cuando un solo agente se atasca en una tarea grande, la respuesta no siempre es un prompt más largo: a veces es repartir el trabajo entre varios agentes coordinados por un patrón de diseño. Un sistema multiagente organiza a varios agentes especializados para que resuelvan juntos un problema que a uno solo se le hace cuesta arriba. En esta guía verás cuándo compensa dar el salto, los tres patrones que dominan la práctica (orquestador-trabajadores, jerárquico y en red), cómo se comunican los agentes mediante el traspaso o handoff, y qué cuesta todo esto en tokens y en modos de fallo. Es una guía de patrones, no de herramientas: si buscas la comparativa de frameworks concretos, la tienes en LangGraph frente a CrewAI y Autogen. La misma explicación está disponible en inglés.

Puntos clave

• Un sistema multiagente reparte una tarea entre varios agentes de IA especializados; la coordinación la impone un patrón de diseño, no el modelo.
• El patrón orquestador-trabajadores (un agente líder que delega en subagentes paralelos) mejoró un 90,2 % los resultados de un sistema de un solo agente en la evaluación interna de investigación de Anthropic.
• El patrón jerárquico anida orquestadores en equipos de equipos; el patrón en red deja que cualquier agente ceda el control a cualquier otro mediante un traspaso.
• El coste es real: un agente consume unas 4 veces más tokens que un chat normal, y un sistema multiagente unas 15 veces más; el gasto de tokens explica por sí solo el 80 % de la variación en el rendimiento.
• Empieza siempre por un agente. Da el salto a varios solo ante paralelismo pesado, información que no cabe en una ventana de contexto o muchas herramientas complejas.

¿Cuándo conviene usar más de un agente?

La regla práctica es empezar por lo simple: un solo agente con buenas herramientas resuelve más de lo que parece. Añadir agentes multiplica el coste y las formas de romperse, así que el salto debe justificarse. Hay tres señales claras de que un agente único se queda corto.

La primera es el paralelismo pesado: la tarea se descompone en subtareas independientes que pueden avanzar a la vez, como investigar cinco fuentes distintas o analizar veinte archivos. La segunda es la información que no cabe en una sola ventana de contexto: si el trabajo exige leer más de lo que entra en el contexto del modelo, repartir la lectura entre subagentes que resumen cada uno su parte evita el desbordamiento. La tercera es el exceso de herramientas: un agente con cuarenta herramientas se distrae eligiendo; varios agentes con un catálogo acotado cada uno aciertan más.

Anthropic lo resume así en su ingeniería del sistema de investigación multiagente: estos sistemas «destacan en tareas valiosas que implican mucha paralelización, información que supera una sola ventana de contexto e interacción con numerosas herramientas complejas». Si tu tarea no encaja en ninguno de esos tres moldes, casi siempre gana el agente único: es más barato, más fácil de depurar y más predecible. La decisión de repartir el trabajo se apoya en la misma disciplina de planificación y descomposición de tareas que usa un agente por dentro, solo que ahora cada subtarea la lleva un agente aparte.

¿Qué es el patrón orquestador-trabajadores?

Es el patrón multiagente más común y el más fácil de razonar. Un agente orquestador (o líder) recibe la tarea, la divide en subtareas y lanza varios agentes trabajadores que resuelven cada pieza en paralelo; después, el orquestador recoge los resultados y los sintetiza en una respuesta final. El orquestador no hace el trabajo pesado: planifica, delega y une.

Anthropic construyó su función de investigación con este patrón exacto, usando Claude Opus 4 como agente líder y varios Claude Sonnet 4 como subagentes. El resultado fue contundente: la versión multiagente superó en un 90,2 % a un sistema de un solo agente basado en Opus 4 en su evaluación interna de investigación. La clave es que cada subagente explora una dirección con su propia ventana de contexto, y el líder solo ve los resúmenes, no el ruido.

En pseudocódigo, la forma del patrón es siempre la misma, independientemente del framework:

# Orquestador-trabajadores (pseudocódigo agnóstico del framework)
def orquestador(tarea):
    subtareas = lider.planificar(tarea)          # divide el problema
    resultados = ejecutar_en_paralelo(            # lanza subagentes a la vez
        [trabajador(sub) for sub in subtareas]
    )
    return lider.sintetizar(resultados)           # une los hallazgos

def trabajador(subtarea):
    return agente_especializado.resolver(subtarea)  # su propio contexto

La diferencia con una simple descomposición de tareas dentro de un agente es que aquí cada trabajador es un agente completo, con su propio bucle de razonamiento y su propio contexto aislado. Eso es lo que permite la paralelización real y evita que la lectura de una fuente contamine la de otra.

¿Cómo funcionan el patrón jerárquico y el patrón en red?

Cuando un solo orquestador se queda corto porque coordina demasiados trabajadores, el patrón jerárquico anida el orquestador dentro de otro nivel. En lugar de un líder con veinte trabajadores, tienes un líder que coordina a varios supervisores, y cada supervisor dirige su propio equipo de trabajadores. Es el mismo principio de orquestador-trabajadores aplicado en capas: equipos de equipos. La documentación de LangGraph lo llama arquitectura jerárquica y lo recomienda cuando el número de agentes crece hasta hacer inmanejable un único supervisor.

El patrón en red (o de malla) elimina la figura central. Cada agente puede pasar el control a cualquier otro según lo que descubra, sin un jefe que lo dirija todo. Es la topología más flexible y la más difícil de controlar: sirve cuando el flujo no se conoce de antemano y depende de lo que vaya apareciendo, pero es fácil que los agentes entren en bucles o se pisen. La siguiente tabla resume los tres patrones:

La regla es subir de complejidad solo cuando duele: empieza con orquestador-trabajadores, pasa a jerárquico cuando un solo orquestador no da abasto, y reserva la red para los casos en los que ningún plan fijo sirve.

¿Cómo se comunican los agentes: el traspaso o handoff?

Los agentes de un sistema multiagente se coordinan de dos maneras, y la elección define el carácter del sistema. La primera es el traspaso (handoff): un agente cede el control a otro, que se convierte en el agente activo durante el resto del turno. El OpenAI Agents SDK lo implementa como una primitiva de primera clase: un agente de triaje decide qué especialista debe responder y le pasa la conversación entera. Es un modelo descentralizado, natural para el patrón en red, en el que el especialista responde directamente al usuario.

La segunda es el patrón gestor (o agentes como herramientas): un agente gestor mantiene el control y llama a los especialistas como si fueran herramientas, mediante algo como Agent.as_tool(). El gestor recibe cada resultado, lo combina y produce la respuesta final. Es un modelo centralizado, la forma natural del orquestador-trabajadores. El propio SDK aconseja usar el traspaso «cuando quieres que el especialista responda directamente», y el patrón gestor «cuando quieres que un solo agente sea el dueño de la respuesta final».

# Traspaso (descentralizado) frente a gestor (centralizado)

  # Traspaso: el triaje cede el control al especialista
  triaje = Agente(nombre="triaje", handoffs=[soporte, ventas])
  # a partir del handoff, el especialista responde por su cuenta

  # Gestor: el gestor llama a los especialistas como herramientas
  gestor = Agente(
      nombre="gestor",
      tools=[investigador.as_tool(), redactor.as_tool()],
  )
  # el gestor recoge cada salida y redacta la respuesta final

Elegir entre ambos no es un detalle técnico: define quién habla con el usuario, dónde se aplican las barreras de seguridad y cómo se depura el sistema. El patrón gestor concentra el control y la auditoría en un punto; el traspaso reparte la responsabilidad y gana flexibilidad a cambio de claridad. Frameworks como CrewAI construyen sus equipos de roles sobre estas mismas dos ideas.

¿Cuánto cuestan y cómo fallan los sistemas multiagente?

El coste es el gran contrapeso. Según las mediciones de Anthropic, un agente consume alrededor de 4 veces más tokens que una interacción de chat normal, y un sistema multiagente unas 15 veces más. No es un detalle: en su evaluación BrowseComp, el gasto de tokens explicaba por sí solo el 80 % de la variación en el rendimiento. Dicho de otro modo, buena parte de lo que gana un sistema multiagente lo gana porque gasta más, así que solo tiene sentido cuando el valor de la tarea justifica ese gasto.

Los modos de fallo son característicos y conviene conocerlos antes de sufrirlos. Anthropic relata que sus primeras versiones llegaron a «lanzar 50 subagentes para consultas simples, rastrear la web sin fin en busca de fuentes inexistentes y distraerse entre sí con actualizaciones excesivas». A esa lista se suman los clásicos: agentes que entran en bucle pasándose el control una y otra vez, subtareas que se solapan y duplican trabajo, y errores que se propagan cuando un trabajador entrega un resultado malo que el orquestador da por bueno. La defensa pasa por límites explícitos (número máximo de subagentes, de pasos y de coste), por supervisión humana en los puntos críticos y por observabilidad que deje ver qué hizo cada agente. Un sistema multiagente no es un agente mejor: es un sistema distribuido, con todo lo que eso implica.

Preguntas frecuentes

¿En qué se diferencia un sistema multiagente de un solo agente con muchas herramientas?

Un solo agente con muchas herramientas comparte un único bucle de razonamiento y una única ventana de contexto: toda la tarea vive en la misma cabeza. Un sistema multiagente reparte el trabajo entre agentes con contextos separados, cada uno con su propio razonamiento. Esa separación permite paralelismo real y aísla la información, pero añade coordinación, coste en tokens y nuevos modos de fallo. Por eso conviene empezar por el agente único y dar el salto solo cuando la tarea lo pide.

¿Qué patrón multiagente debería elegir primero?

Empieza por orquestador-trabajadores. Es el más fácil de razonar y depurar: un líder que planifica, delega en subagentes paralelos y sintetiza. Pasa al patrón jerárquico cuando un único orquestador coordina demasiados agentes y se convierte en cuello de botella. Reserva el patrón en red para flujos impredecibles en los que ningún plan fijo sirve, asumiendo que ganarás flexibilidad a cambio de un control mucho más difícil.

¿El traspaso y el patrón gestor son excluyentes?

No. Muchos sistemas reales combinan ambos: un gestor central que llama a especialistas como herramientas para la mayoría del trabajo y traspasos puntuales cuando conviene que un especialista se quede con la conversación. Lo importante es decidir de forma consciente quién es el dueño de la respuesta final y dónde se aplican las barreras de seguridad, porque de eso dependen la auditoría y la depuración del sistema.

Conclusión

Los patrones de sistemas multiagente son, en el fondo, tres formas de repartir una tarea: un líder que delega (orquestador-trabajadores), equipos de equipos (jerárquico) o una malla sin jefe (en red), comunicados mediante traspasos o llamadas de un gestor. No son magia: un sistema multiagente bien montado supera con holgura a un agente único en tareas paralelas y amplias, pero gasta mucho más y falla de formas nuevas. El siguiente paso sensato es quedarte con el agente único mientras te baste y, cuando de verdad necesites repartir, empezar por orquestador-trabajadores y comparar frameworks en la guía de LangGraph frente a CrewAI y Autogen.

Fuentes: [1] Anthropic, cómo construimos nuestro sistema de investigación multiagente^[1], [2] OpenAI Agents SDK, orquestación de varios agentes^[2], [3] LangGraph, arquitecturas multiagente^[3], [4] Anthropic, cómo construir agentes eficaces^[4].

Fuentes

1. Anthropic, cómo construimos nuestro sistema de investigación multiagente
2. OpenAI Agents SDK, orquestación de varios agentes
3. LangGraph, arquitecturas multiagente
4. Anthropic, cómo construir agentes eficaces

Ruta: Fundamentos de los agentes de IA