Patrones de diseño de sistemas multi-agente en producción

Un sistema multi-agente es una arquitectura de IA en la que dos o más agentes LLM se coordinan para resolver una tarea que un solo agente maneja mal, dividiendo roles, ejecutándose en paralelo o pasando estado a través de un grafo explícito. El patrón funciona cuando el problema es descomponible, el valor de la respuesta cubre el coste en tokens y el equipo tiene una forma de depurar fallos entre agentes. Se rompe cuando esas tres condiciones no se cumplen.

La mayoría de los equipos lo descubre por la vía cara. La medición propia de Anthropic es que los sistemas multi-agente consumen aproximadamente 15 veces más tokens que una interacción de chat, con una mejora del 90,2% en evaluaciones internas de research. Esa proporción solo tiene sentido para tareas de alto valor donde la respuesta vale el gasto. Para un chatbot que responde solicitudes de reembolso, es malpractice.

Por qué los setups multi-agente ingenuos fallan en producción

El Sky Computing Lab de Berkeley publicó MAST, una Multi-Agent Systems Failure Taxonomy, tras analizar más de 1.600 trazas en siete frameworks open source populares. Encontraron 14 modos de fallo distintos agrupados en tres categorías: problemas de system design, desalineación inter-agente y huecos de verificación de tarea. El número titular: ChatDev, uno de los frameworks más citados en la literatura académica, obtuvo un 33,33% de corrección en su propio benchmark ProgramDev.

Los datos de la industria apuntan en la misma dirección. Aproximadamente el 40% de los pilotos multi-agente fallan dentro de los seis meses tras el despliegue en producción, normalmente porque el equipo eligió una forma de orquestación que no encajaba con el problema y solo se dio cuenta cuando llegó la factura.

El modo de fallo ingenuo es consistente. Un equipo lee un blog post sobre colaboración entre agentes, elige CrewAI o LangGraph porque estaba en lo alto de los resultados de búsqueda, envuelve cuatro roles alrededor del mismo modelo y lo llama sistema multi-agente. Los agentes entonces gastan tokens discutiendo entre ellos, repiten el trabajo del otro, pierden estado cuando la conversación crece más allá de la context window y fallan en silencio porque nadie cableó la observability en el grafo. Cada arreglo individual parece pequeño. El coste acumulado es el proyecto.

Por qué "añadir más agentes" lo empeora

El instinto, cuando un agente lucha, es generar ayudantes. Es incorrecto por defecto. Cada nuevo agente multiplica el coste de coordinación, expande la superficie para la desalineación inter-agente (categoría MAST 2) y añade otro candidato a que el orquestador gestione mal. Cada paper y cada retrospectiva de producción converge en el mismo consejo: empieza con un solo agente, añade especialización solo cuando un cuello de botella medible lo exija, y nunca dividas una tarea que un agente podría completar en un solo paso.

El otro instinto es el debate. El multi-agent debate parece elegante sobre el papel y produce mejores respuestas en ciertos benchmarks de reasoning, pero en producción consume tokens linealmente por turno, a menudo sin converger. Resérvalo para tareas donde la ganancia marginal de precisión es auditable y el presupuesto de latencia es generoso.

Los cinco patrones que sobreviven en producción

1. Orchestrator-Worker

Un agente líder descompone una consulta en subtareas, las despacha a agentes worker especializados y ensambla el resultado. Esa es la forma que usa la feature Research de Anthropic, con Claude Opus 4 como orquestador y Claude Sonnet 4 como workers, cada uno con su propia context window y su propio set de herramientas. El patrón es correcto cuando las subtareas son genuinamente independientes (busca el subgrafo A mientras corre el subgrafo B), cuando cada worker tiene un objetivo claramente delimitado y cuando el orquestador puede describir la tarea en un prompt estructurado que nombra el formato de salida.

Úsalo para: síntesis de research, recolección de datos en paralelo, generación de código en varios módulos. Evítalo para: chat, flujos de reembolso, cualquier cosa secuencial por naturaleza. El orquestador delega herramientas a través de una interfaz estándar, que es una de las razones por las que un servidor MCP normalmente se paga solo en el momento en que más de un agente comparte las mismas herramientas.

2. Pipeline secuencial

Los agentes corren en un orden fijo. La salida del paso N es la entrada del paso N+1. La forma es aburrida, predecible y cubre la mayoría de los workloads de agentes que llegan a producción. Las pipelines tienen sentido cuando la tarea tiene una progresión natural (extract, transform, validate, write) y cuando el esquema de salida de cada paso es lo bastante estable para hacer type-check en el límite.

La trampa es usar una pipeline cuando la tarea es en realidad un grafo. Si el paso 3 a veces necesita revisar el paso 1, no tienes una pipeline. Tienes una state machine, que es lo que LangGraph modela bien.

3. Fan-out y fan-in en paralelo

Un orquestador despacha la misma variación de tarea entre N workers, luego agrega. Este patrón es lo que da a los sistemas multi-agente su ventaja medida en velocidad. Solo compensa cuando el trabajo es genuinamente paralelo, cuando el paso agregador no es trivial (de lo contrario estás pagando N veces por una sola respuesta) y cuando el presupuesto de tokens lo permite. El número del 90,2% de performance de Anthropic vive aquí.

4. Coreografía en lugar de orquestación (cuando los fallos son tolerables)

Los sistemas coreografiados dejan que los agentes declaren capacidades y un router los trae cuando hacen falta. CrewAI usa esa forma por defecto. La coreografía sobrevive al fallo de un agente mejor que la orquestación, porque no hay un coordinador único que crashee. El trade-off es la depurabilidad: cuando algo sale mal en una ejecución coreografiada, la traza parece un árbol telefónico y pasas horas reconstruyendo intención.

Elige coreografía para workloads críticos en resiliencia donde una respuesta degradada al 10% es mejor que una respuesta ausente. Elige orquestación para todo aquello donde tienes que explicarle a un cliente por qué una respuesta es errónea.

5. Model tiering

Usa un modelo barato (Haiku, Sonnet) para triage, clasificación y routing. Reserva el modelo caro (Opus, clase GPT-4) para el reasoning real y la síntesis final. Los equipos en producción reportan reducciones de coste del 40 al 60% por esta sola decisión, normalmente suficiente para hacer defendible el multiplicador de tokens de 15x del multi-agente. El tiering no es técnicamente un patrón multi-agente en el sentido de orquestación, pero ningún sistema multi-agente en producción sobrevive sin él.

Cómo se ve en un caso real

Un setup reciente que construimos sustituyó un agente de research con un solo prompt por una forma orchestrator-worker para inteligencia competitiva sobre empresas privadas. La versión de un solo prompt hacía una llamada a Claude, devolvía un párrafo y se perdía aproximadamente la mitad de la señal relevante. La versión multi-agente usa un orquestador (Sonnet 4) que descompone una consulta de empresa en cuatro pistas de research paralelas (funding, producto, liderazgo, hiring). Cada pista es un worker (Sonnet 4) con su propia herramienta de búsqueda y un esquema de salida estricto. El orquestador cose los cuatro artefactos en un brief.

El antes y después: la profundidad de research aproximadamente se triplicó, la latencia pasó de 6 segundos a 22 segundos, el coste en tokens subió 11 veces. Para un equipo de ventas que antes gastaba 40 minutos por empresa en research manual, el intercambio era fácil. Para un chatbot consumer habría sido ruinoso. El patrón solo funciona cuando los números cuadran.

Elige el framework después de elegir el patrón

La mayoría de los equipos invierte el orden. Eligen LangGraph o CrewAI primero, luego doblan el problema para que encaje. El orden honesto es: nombra el patrón (orchestrator-worker, pipeline, fan-out, coreografía, tiering), después elige el framework que expresa ese patrón con la menor ceremonia.

Para state machines en forma de grafo con ciclos explícitos, branching y requisitos de observability de producción, LangGraph sigue siendo la opción más battle-tested en 2026. Para crews basadas en roles con flujo lineal y un presupuesto de prototipo de un día, el modo Flows de CrewAI ya es aceptable en producción. AutoGen está efectivamente en maintenance mode mientras Microsoft consolida en torno a su Agent Framework más amplio, así que recurre a él solo si el debate conversacional es genuinamente tu primitiva.

El patrón que sobrevive en producción es el que encaja con el problema. El framework viene detrás de esa decisión, nunca por delante.