Capítulo 6 — Estrategias fundamentales de orquestación
Sexta entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. Un sistema multi-agente es un sistema distribuido — una vez aceptado ese marco, la mayoría de las decisiones de diseño de este capítulo se vuelven familiares, y la mayoría de los fallos caros de 2024 y 2025 dejan de ser misteriosos.
Por qué existe este capítulo
El lenguaje de marketing alrededor de los sistemas agénticos sugiere que más agentes son intrínsecamente mejor — más caballos de potencia cognitiva, más especialización, más capacidad emergente. La realidad de ingeniería es la opuesta en la mayoría de los casos. Cada agente adicional añade un viaje de ida y vuelta, un punto de serialización, un sitio donde la salida de un agente se convierte en la entrada de otro y una oportunidad nueva para que la conversación se desvíe. La pregunta correcta no es "¿cómo distribuyo esto entre agentes?" sino "¿puede un único modelo con las herramientas adecuadas hacer esto en una llamada?".
Este capítulo recorre las dos formas más simples de orquestación — secuencial y concurrente — y la pregunta previa que debería precederlas. Muchos de los fallos más caros en producción de los dos últimos años no fueron fallos de orquestación. Fueron sistemas construidos como multi-agente cuando un único agente bien herramentado habría hecho el trabajo con una décima parte de la latencia y ninguno de los bugs de coordinación.
6.1 Cuándo varios agentes realmente ayudan
El caso para un único agente con herramientas es más fuerte cuando la tarea se descompone en un pequeño número de operaciones bien definidas contra fuentes de datos bien definidas. Un asistente de revisión de código que lee un diff, ejecuta un linter, mira convenciones y escribe un comentario se puede construir como una invocación de modelo con cuatro herramientas. Añadir un segundo agente introduce latencia sin añadir capacidad — el modelo ya está planificando; un segundo modelo planificando de otra manera es un coste de coordinación, no una mejora.
Tres propiedades hacen que varios agentes salgan a cuenta. Heterogeneidad de contexto — cuando dos fases necesitan system prompts, herramientas o material de referencia dramáticamente distintos, meterlas a la fuerza en una sola ventana diluye la atención del modelo. Investigar-y-luego-escribir es el caso canónico: la recuperación quiere amplitud y herramientas de búsqueda, escribir quiere prosa y nada de herramientas. Refinamiento iterativo contra un control externo — si la salida hay que revisarla y posiblemente reescribirla, el creador y el verificador quieren cada uno su contexto y su prompt. Paralelismo sobre subtareas independientes — cinco fuentes documentales que resumir, tres perspectivas que recoger, diez ficheros que analizar — correrlas en serie desperdicia tiempo de reloj en trabajo sin dependencia causal.
Antes de comprometerse con multi-agente, un ingeniero debería poder nombrar la propiedad que lo motiva. Una retrospectiva de 2025 de una gran empresa de logística sustituyó una orquestación de soporte de siete agentes por un único agente Claude más seis herramientas MCP; la versión de un solo agente fue más rápida, más barata y obtuvo mejor puntuación en calidad de resolución. "¿Podemos colapsar esto?" debería ser una pregunta de pie en cualquier revisión de orquestación.
6.2 Orquestación secuencial: pipelines y refinamiento progresivo
La orquestación secuencial es la forma multi-agente más simple. La salida de un agente se convierte en la entrada del siguiente. La mayoría de los sistemas "multi-agente" en producción son pipelines secuenciales disfrazados. La fortaleza es la legibilidad: el pipeline se puede dibujar en una pizarra, probarse etapa a etapa y razonarse como una serie de contratos de entrada-salida. El contrato entre etapas es el artefacto clave — cada etapa declara su esquema de entrada, el orquestador lo impone con código en vez de con confianza, y los fallos de validación disparan reintentos o caminos alternativos en vez de propagarse en silencio.
El caso canónico es investigar-y-luego-escribir. Un agente investigador con búsqueda web y recuperación produce un brief estructurado; un agente escritor sin herramientas y con prompt de prosa convierte el brief en un artículo. El escritor no ve los falsos comienzos, las fuentes descartadas ni las largas cadenas de razonamiento. Ve el brief. Las dos etapas pueden usar modelos distintos — razonamiento fuerte para investigar, prosa fuerte para escribir — y los costes se acumulan sólo donde cada uno hace falta. El refinamiento progresivo es un primo cercano: borrador, edición, verificación de hechos, reformateo. Operadores especializados baten a un generalista intentando hacerlo todo en una pasada.
Los costes honestos son tres. Latencia — un pipeline de N etapas tiene un suelo igual a la suma de los tiempos de etapa. Los pipelines largos se descartan a sí mismos de la latencia conversacional por definición. Amplificación de error — un pipeline de cuatro etapas al 95% por etapa es 81% de extremo a extremo; uno de ocho es 66%. Validación por etapa con reintentos acotados es lo que mantiene la aritmética operable. Pérdida de información entre etapas — cada salida es necesariamente más estrecha que su contexto de trabajo, y la información que el escritor luego descubre que necesita está perdida salvo que el esquema del brief fuera más rico de lo estrictamente requerido.
6.3 Orquestación concurrente: scatter, gather, multi-perspectiva
La orquestación concurrente corre varios agentes en paralelo y combina sus salidas. La propiedad definitoria es que no hay dependencia causal durante el trabajo — la dependencia sólo aparece en el paso de combinación. A veces se llama scatter-gather, a veces map-reduce para agentes; la topología es la misma.
Tres casos de uso motivan el patrón. Paralelismo sobre subtareas independientes — cinco fuentes leídas en paralelo, luego un sintetizador. El tiempo de reloj es el lector más lento más el sintetizador, no la suma. Análisis multi-perspectiva — la misma entrada dada a un prompt de analista financiero, uno de revisor legal y uno de estratega de producto, con encuadres lo bastante distintos como para que las salidas no sean variantes cosméticas. Ensembling por fiabilidad — el mismo prompt a varios agentes, salidas votadas o promediadas, defendible cuando las respuestas erróneas cuestan mucho más que una factura de tokens tres veces mayor.
El paso de combinación es donde paga el esfuerzo de ingeniería. Los sintetizadores ingenuos a los que se entregan entradas largas y contradictorias se vuelven cuellos de botella. Tres patrones lo mejoran: salidas intermedias estructuradas para que el sintetizador fusione campos de manera determinista en vez de releer prosa; reducción jerárquica para que cada agente combinador vea un número acotado de entradas a medida que el fan-out crece; y afloramiento de conflictos para que el sintetizador etiquete los desacuerdos en vez de elegir bando en silencio.
La pregunta diagnóstica para saber si scatter-gather es el patrón correcto: si le dijera a un agente paralelo lo que otro está produciendo ahora mismo, ¿cambiaría su salida? Si la respuesta es sí, el trabajo no era independiente y el patrón está mal — necesitas o dependencias secuenciales o los patrones dinámicos del Capítulo 7.
6.4 La aritmética honesta de la coordinación
Toda orquestación es, en tiempo de ejecución, un flujo de trabajo distribuido sobre trabajadores poco fiables. Tasas de fallo por llamada del 1 al 5% son típicas incluso en modelos de calidad — fallos de parseo de JSON, violaciones de contrato, nombres de herramienta alucinados, saltos silenciosos. Multiplicadas a lo largo de un pipeline, una tasa del 2% por etapa en ocho etapas es 85% de extremo a extremo. Las mitigaciones son estructurales: validación por etapa que dispara reintentos acotados; observabilidad por etapa que registra entradas, salidas, latencia, gasto de tokens y qué puertas de validación pasaron; y degradación elegante para que un presupuesto de reintentos agotado degrade en vez de colapsar el flujo entero.
Los presupuestos de latencia necesitan techo, no sólo suelo — al usuario no le importa la media, le importa la cola larga. Los presupuestos de coste necesitan un modelo de entrada: un pipeline de dos etapas cuesta unas 1,5 veces el equivalente de una etapa, scatter-gather sobre cinco ramas cuesta de 5 a 8 veces, las mesas redondas 10 veces o más. Algunos sistemas no son viables a escala porque su coste por interacción supera el valor de la interacción. Haz la aritmética en tiempo de diseño, no cuando llegue la factura.
Lo que prepara el Capítulo 6
Secuencial y concurrente son los bloques de construcción. Cubren la mayoría de los casos multi-agente cuando la topología de la tarea es conocida de antemano y los roles de los trabajadores son fijos. Comparten una asunción: alguien en tiempo de diseño decidió cuáles son los agentes y cómo se conectan. La orquestación es estática; el pipeline se dibuja antes de que llegue ninguna petición de usuario. El Capítulo 7 retira esa asunción.
Próximamente — Capítulo 7: Patrones colaborativos avanzados y dinámicos. Mesas redondas, enrutado por handoff y orquestación magéntica — qué pasa cuando la topología hay que construirla por petición en vez de por diseño, y los modos de fallo (no-terminación, mis-routing, planificación descontrolada) que los patrones más simples evitan.
