6 patrones de orquestación multiagente que realmente funcionan en producción

Gartner ha informado de un aumento del 1.445% en las consultas sobre sistemas multi-agente entre el primer trimestre de 2024 y el segundo de 2025. Las organizaciones ya utilizan una media de 12 agentes, y se prevé que esa cifra aumente un 67% en un plazo de dos años.

Sin embargo, el 40% de los pilotos multi-agente fracasan en los seis meses siguientes a su despliegue en producción. El problema no es que los sistemas multi-agente no funcionen. Es que los equipos eligen el patrón de orquestación incorrecto para su problema, o eligen el adecuado sin comprender cómo puede fallar.

Presentamos seis patrones que funcionan con éxito en producción, junto con las formas específicas en que cada uno de ellos falla cuando no se implementa correctamente.

1. Orquestador-trabajador (Orchestrator-worker)

Un agente recibe la tarea, la divide en subtareas, delega cada una de ellas en un trabajador especialista y unifica los resultados. El orquestador utiliza un modelo de alta capacidad mientras que los trabajadores emplean modelos más económicos y específicos, reduciendo costes entre un 40% y un 60%.

Cuándo utilizarlo: Flujos de trabajo multifuncionales con una descomposición de tareas clara. Enrutamiento de atención al cliente entre especialistas de facturación, técnicos y de producto. Cualquier proceso en el que se necesite un único punto de responsabilidad.

Wells Fargo utiliza este patrón para que 35.000 banqueros accedan a 1.700 procedimientos en 30 segundos, frente a los 10 minutos anteriores. Agentforce 2.0 de Salesforce lo implementa a través de su motor Atlas Reasoning Engine.

Por qué falla

El orquestador es un punto único de fallo. Si clasifica incorrectamente una tarea, el trabajador equivocado la recibe, y las tasas de clasificación errónea se multiplican a gran escala.

El desbordamiento de la ventana de contexto es un problema más sutil. El orquestador acumula el contexto de cada trabajador. Con cuatro o más trabajadores, el contexto supera con frecuencia los límites de la ventana. Flujos de trabajo que cuestan 0,50 $ en fase de pruebas pueden alcanzar los 50.000 $/mes con 100.000 ejecuciones, ya que el orquestador realiza múltiples llamadas de LLM para la descomposición y agregación, además de las llamadas de cada trabajador.

2. Pipeline secuencial (Sequential pipeline)

Los agentes se ejecutan en una cadena lineal predefinida. Cada uno procesa la salida del agente anterior a través de un estado compartido. El orden es determinista y se define en el momento del diseño.

Cuándo utilizarlo: Procesamiento de documentos (análisis, extracción, validación, resumen). Generación de contratos. Moderación de contenidos. Cualquier proceso de varias etapas con dependencias lineales claras.

El Centro de Arquitectura de Azure de Microsoft documenta el caso de un bufete de abogados que utiliza esto para la generación de contratos: selección de plantillas, personalización de cláusulas, revisión de cumplimiento y evaluación de riesgos, cada uno gestionado por un agente de IA independiente.

Por qué falla

Propagación de errores. Un resultado incorrecto en la etapa 1 se transmite en cascada a través de todas las etapas posteriores sin posibilidad de retroceso.

El inconveniente menos evidente es la sobrecarga. Una pipeline de cuatro agentes acumula aproximadamente 950 ms de sobrecarga de coordinación, mientras que el procesamiento real tarda 500 ms. Una pipeline de tres agentes consume 29.000 tokens en comparación con los 10.000 de un enfoque equivalente de un solo agente. Si su flujo de trabajo no necesita esa especialización, estará pagando tres veces más por el mismo resultado.

3. Distribución / Concentración (Fan-out / fan-in)

Múltiples agentes se ejecutan simultáneamente sobre la misma entrada o sobre subtareas independientes. Un despachador distribuye el trabajo y un recopilador unifica los resultados mediante votación, fusión ponderada o síntesis basada en LLM.

Cuándo utilizarlo: Análisis multiperspectiva (análisis financiero con agentes fundamentales, técnicos, de sentimiento y ESG ejecutándose en paralelo). Revisión concurrente de código en aspectos de seguridad, estilo y rendimiento. Cualquier escenario con cuatro o más tareas independientes en el que se necesite reducir el tiempo de ejecución en un 75%.

Por qué falla

Límites de tasa de API. Quince agentes concurrentes consumiendo 150 solicitudes por segundo cuando su límite es de 100. Cada agente se mantiene dentro de los límites de forma individual, pero la carga colectiva supera la capacidad.

Las condiciones de carrera en el estado compartido escalan de forma cuadrática. Un sistema con N agentes tiene N(N-1)/2 interacciones concurrentes potenciales. Con cinco agentes, son 10 conflictos potenciales. Con diez, son 45.

El propio paso de agregación introduce errores. La síntesis basada en LLM puede alucinar un consenso que no existe en los resultados subyacentes. Si sus agentes paralelos no están de acuerdo (el de sentimiento dice comprar, el de análisis fundamental dice vender), necesita una estrategia de resolución de conflictos explícita, no solo un "resumen de los resultados".

4. Debate multi-agente (Multi-agent debate)

Varios agentes participan en una conversación compartida, aportando perspectivas, desafiándose mutuamente y refinando posturas a lo largo de varias rondas. Incluye bucles de creador-verificador (maker-checker), en los que un agente genera y otro valida hasta que se aprueba.

Cuándo utilizarlo: Revisiones de cumplimiento que requieren múltiples perspectivas de expertos. Control de calidad con revisiones estructuradas. Las investigaciones demuestran que el debate reduce las alucinaciones en comparación con las consultas de un solo modelo, ya que los agentes detectan los errores de los demás.

Una variante práctica: utilizar un modelo rápido y económico para el creador y un modelo de alta capacidad para el verificador. Obtendrá la mejora de calidad del debate a un coste entre un 40% y un 60% menor que si ejecutara ambos en modelos de alta capacidad.

Por qué falla

Bucles de conversación. Los agentes siguen debatiendo sin llegar a un acuerdo. Por esta razón, Microsoft recomienda limitar el chat de grupo a tres o menos agentes.

La cascada de adulación (sycophancy) es el problema más complejo. Los agentes tienden a alinearse con la postura de la mayoría incluso cuando es errónea, generando un falso consenso. Cinco rondas con tres agentes implican 15 llamadas de LLM por tarea, y el resultado puede seguir siendo incorrecto con total seguridad porque los agentes reforzaron mutuamente sus errores.

5. Traspaso dinámico (Dynamic handoff)

Cada agente evalúa la tarea actual y decide si la gestiona o transfiere el control a un especialista más adecuado. A diferencia del modelo orquestador-trabajador, no existe un coordinador central. Los agentes delegan entre sí en función del contexto de ejecución. Solo un agente está activo a la vez.

Cuándo utilizarlo: Soporte al cliente donde el especialista adecuado surge durante la conversación (un problema de facturación resulta ser en realidad un problema técnico). Tareas donde los requisitos de especialización no se conocen de antemano.

HCLTech informó de una resolución de casos un 40% más rápida mediante el traspaso dinámico de agentes. Este patrón funciona de manera excelente cuando realmente no se puede predecir al inicio qué especialista requerirá una interacción.

Por qué falla

Bucles de traspaso infinitos. El agente A pasa al B, el B pasa al C, el C vuelve a pasar al A. Este es el principal modo de fallo. Cada agente sigue planificando de nuevo porque nadie asume la propiedad de la tarea.

La pérdida de contexto se agrava con cada transferencia. O bien se pasa todo el contexto (costoso y eventualmente supera las ventanas de contexto) o se resume (con pérdida de información, y los errores de resumen acumulados degradan la calidad). Además, dado que el enrutamiento no es determinista, la misma entrada puede generar cadenas de agentes completamente diferentes, haciendo que la depuración sea casi imposible.

6. Planificación adaptativa (Adaptive planning)

Un agente administrador crea, refina y ejecuta dinámicamente un plan de tareas consultando a los especialistas. A diferencia del orquestador-trabajador, donde el plan se conoce de antemano, aquí el propio plan se descubre mediante la colaboración. El administrador itera, retrocede y delega según sea necesario, comprobando continuamente si se cumple el objetivo original.

Cuándo utilizarlo: Problemas abiertos sin una ruta de solución predeterminada. Respuesta a incidentes donde las medidas de solución surgen del diagnóstico. Migraciones complejas donde el alcance cambia durante la ejecución.

Microsoft documenta un ejemplo de SRE (Ingeniería de Fiabilidad del Sitio): el administrador crea un plan inicial, consulta a agentes de diagnóstico y de infraestructura, y cuando el diagnóstico revela un problema de base de datos en lugar de un problema de despliegue, todo el plan pivota en tiempo real.

Por qué falla

Convergencia lenta. Este patrón prioriza la precisión sobre la velocidad. No es adecuado para tareas donde el tiempo es un factor crítico.

La desviación del objetivo (goal drift) es el factor crítico en entornos de producción. A lo largo de múltiples iteraciones, el plan refinado del administrador puede desviarse significativamente de la intención original. El retroceso empeora la situación: cuando el administrador descubre un callejón sin salida, todo el trabajo de esa rama se convierte en capacidad de cómputo desperdiciada, y el coste es imposible de predecir de antemano. Si la solicitud original es imprecisa, el administrador puede entrar en un bucle indefinido intentando construir un plan "completo" que satisfaga un objetivo mal especificado.

Cómo elegir el patrón adecuado

Comience con el patrón más sencillo que se adapte a su problema. La mayoría de los equipos complican la arquitectura en exceso.

¿La descomposición de la tarea está clara? Orquestador-trabajador. Conoce las subtareas en el momento del diseño y desea un único punto de responsabilidad.

¿Pasos lineales fijos? Pipeline secuencial. El orden nunca cambia y cada paso depende de la salida anterior.

¿Trabajo paralelo independiente? Distribución/Concentración (Fan-out/fan-in). Cuatro o más tareas sin dependencias entre ellas.

¿Necesita verificación de calidad? Debate multi-agente. Especialmente bucles de creador-verificador donde la precisión es más importante que la velocidad.

¿Enrutamiento impredecible? Traspaso dinámico. No se puede saber qué especialista se necesita hasta que se desarrolla la conversación.

¿Problema abierto? Planificación adaptativa. El propio plan debe ser descubierto, no solo ejecutado.

Princeton NLP descubrió que un único agente igualaba o superaba a los sistemas multi-agente en el 64% de las tareas de referencia cuando disponía de las mismas herramientas y contexto. El enfoque multi-agente añade 2,1 puntos porcentuales de precisión prácticamente duplicando el coste. Ese equilibrio merece la pena para trabajos complejos que abarcan varios dominios. Para todo lo demás, un solo agente de IA bien estructurado es más sencillo, rápido y económico.

El mejor patrón de orquestación es el que se adapta a su problema real, no el más sofisticado que sea capaz de desarrollar.