Capítulo 7 — Patrones colaborativos avanzados y dinámicos
Séptima entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. Cuando la topología no puede dibujarse en tiempo de diseño — cuando el siguiente paso correcto depende de lo que el paso anterior haya encontrado — los patrones del Capítulo 6 dejan de bastar.
Por qué existe este capítulo
Los patrones del Capítulo 6 comparten una propiedad arquitectónica que se vuelve un lastre para tareas más duras: la topología está fijada en tiempo de diseño. El ingeniero dibuja el pipeline, nombra las etapas, decide quién alimenta a quién, y el runtime no lo reconsidera. Para tareas cuya forma es conocida de antemano, esto es una fortaleza. Para tareas cuya forma es genuinamente emergente — donde el especialista correcto depende de lo que el usuario haya pedido en realidad, donde el plan mismo hay que construirlo a medida que el trabajo avanza — la topología fija se vuelve jaula.
Este capítulo recorre los patrones dinámicos: mesas redondas donde los agentes iteran hacia el consenso, enrutadores que delegan en especialistas elegidos en tiempo de ejecución, y orquestación magéntica que construye planes a medida que la tarea se desarrolla. Cada uno compra una capacidad que los patrones más simples no ofrecen. Cada uno introduce modos de fallo — no-terminación, mis-routing, planificación descontrolada — que los más simples evitan.
7.1 Chat de grupo y mesa redonda: maker-checker y consenso multi-participante
La orquestación en chat de grupo coloca a varios agentes en un contexto conversacional compartido y les deja hablar por turnos. La forma más simple es el bucle maker-checker con dos agentes: el maker produce un candidato, el checker lo evalúa contra una rúbrica, el maker revisa con la retroalimentación, y el bucle termina con aprobación o con un presupuesto de turnos agotado. Los modelos son medibles mejores evaluando que produciendo cuando ambas cosas se enmarcan correctamente — un modelo al que se le pide escribir y autoevaluarse en la misma llamada tiende a defender su primer intento; el mismo modelo, con la misma salida en un contexto fresco y una rúbrica clara, es notablemente más crítico.
Los modos de fallo honestos son tres. Colusión — cuando maker y checker comparten modelo y prompt, el checker aprueba cualquier cosa. La defensa es una diferenciación real de rol, idealmente con modelos distintos. No-terminación — un checker estricto rechaza todos los candidatos; el orquestador debe aceptar el mejor visto o escalar. Deriva del checker — en una mesa redonda con contexto compartido, el checker empieza a aprobar cosas que antes habría rechazado porque las justificaciones del maker se acumulan. Un hallazgo de campo de finales de 2025 es contraintuitivo: los sistemas maker-checker más fiables impiden que el checker vea cómo se produjo el candidato. Los checkers sin estado — a los que se les da sólo el candidato y la rúbrica — aumentan los rechazos correctos en un 30 a 50%. El contexto compartido es una herramienta, no un valor por defecto.
Las mesas redondas multi-participante extienden el patrón con varios especialistas y un moderador. El coste crece rápido: el gasto de tokens crece con el transcript compartido, la latencia crece con los turnos, y se observa en producción a agentes que se quedan atascados en tangentes. Las disciplinas que la hacen funcionar — tokens acotados por turno, salidas de turno estructuradas, rúbricas de terminación explícitas — son la diferencia entre una reunión productiva y una reunión que debería haber sido un correo.
7.2 Handoff y enrutado: delegación dinámica
La orquestación por handoff toma otro camino: un agente a la vez lleva la conversación, y el agente activo puede ceder cuando su trabajo termina o cuando la petición cambia a otra especialidad. El enrutador — habitualmente un LLM él mismo — lee el estado de la conversación y emite una decisión de enrutado: "quédate con el actual" o "cede a especialista X con este resumen de contexto". El resumen es el contrato entre la capa de enrutado y el especialista.
El problema de ingeniería más duro es reconocer cuándo hace falta un handoff. El mis-routing es el fallo más común: el enrutador manda una pregunta de facturación a soporte técnico, soporte hace lo que puede, y el usuario recibe una respuesta confusa que no aborda ninguna de sus preocupaciones. Las defensas se apilan: un umbral de confianza por debajo del cual el enrutador difiere a un humano, acciones explícitas de "esto no es mi área" que los especialistas pueden tomar, y logging de cada decisión de enrutado para revisión.
Otros dos modos de fallo dan forma al diseño de producción. Bucles de handoff — el especialista A manda al B, B manda de vuelta a A — defendidos detectando handoffs repetidos y forzando una resolución distinta. Pérdida de contexto — cada resumen de handoff es lossy, y el especialista siguiente puede pedir información que el usuario ya proporcionó — defendida guardando la conversación entera fuera del contexto de cualquier especialista, con el resumen como payload primario y el historial completo disponible bajo demanda. Cuando el número de especialistas crece, los enrutadores planos se vuelven frágiles; el patrón que surgió en 2025 es el enrutado jerárquico — un enrutador grueso elige categoría, un enrutador específico de categoría elige especialista. Dos niveles es el punto dulce en producción.
7.3 Orquestación magéntica: planes construidos a medida que el trabajo avanza
Para tareas cuya descomposición no se conoce al inicio — investiga por qué la base de datos va lenta, depura un sistema desconocido, investiga un tema complejo — ninguno de los patrones anteriores basta. La orquestación magéntica, llamada así por el framework Magentic-One de Microsoft, es la familia de patrones donde un agente mánager mantiene un ledger de tarea y lo actualiza a medida que el trabajo avanza. El ledger tiene huecos explícitos: el objetivo original, la comprensión actual (que puede refinarse), las subtareas abiertas con sus prioridades, las subtareas completadas con sus resultados, los descubrimientos que pueden exigir revisar el plan y la condición de parada. El mánager lee el ledger en cada paso, decide la próxima asignación e integra los resultados de vuelta.
La fortaleza es una apertura genuina. "Investiga por qué la base de datos va lenta" no se puede descomponer al inicio — la próxima subtarea depende de si el cuello de botella resulta ser red, plan de consulta o fila caliente. Ningún pipeline fijo podría manejarlo; ninguna topología estática de handoff podría enrutar correctamente sin saber de antemano cuáles serían las especialidades relevantes.
El coste es el más severo de este capítulo en cada dimensión: latencia, tokens, esfuerzo de ingeniería, riesgo operativo. El gasto de tokens crece superlinealmente porque el ledger se lee en cada turno. Los modos de fallo catalogados son agudos. Planificación descontrolada — el mánager abre subtareas más rápido de lo que las cierra, el ledger crece sin freno. Deriva de objetivo — a medida que el mánager aprende, reformula el objetivo lejos de la intención del usuario. Churn de plan — cada hallazgo nuevo dispara una revisión, ningún compromiso se mantiene el tiempo suficiente para progresar. El patrón emergente es el bucle magéntico acotado: presupuestos sobre subtareas abiertas, invocaciones totales de trabajador y tiempo de reloj, con escalada cuando se alcanza cualquiera de los topes. Los sistemas magénticos en producción sin topes a veces queman cientos de dólares en tokens en tareas que el mánager no podía resolver dentro de ningún presupuesto razonable.
7.4 Elegir entre los patrones
Tres preguntas seleccionan entre ellos. ¿Es la topología conocida de antemano? Si sí, quédate con los patrones estáticos del Capítulo 6. ¿Se beneficia el trabajo de iterar contra un control externo? Si sí, un bucle maker-checker es la adición correcta — encajable dentro de cualquier otro patrón. ¿Cómo de abierta es la planificación? Si los límites son claros, handoff o secuencial lo cubren; si es genuinamente emergente, magéntico es el patrón necesario, aceptado con sus costes.
Un caso de 2025 de una firma de servicios financieros es la fábula instructiva: un flujo de onboarding magéntico, elegido porque al equipo le entusiasmaba la flexibilidad del framework, fue reemplazado por un pipeline secuencial fijo. El coste por onboarding cayó de unos siete dólares a ochenta céntimos; las tasas de finalización mejoraron. El patrón de echar mano de la herramienta más general cuando una más específica bastaría no es nuevo en ingeniería de software, y se manifiesta agudamente en orquestación multi-agente porque la generalidad se paga en tokens.
Lo que prepara el Capítulo 7
Los Capítulos 6 y 7 especifican cómo se coordinan los agentes. No especifican dónde corren los agentes, cómo se co-localiza el modelo con las herramientas, ni cómo es la topología de despliegue al nivel de procesos, máquinas y fronteras de red. Dos sistemas con orquestación idéntica pueden desplegarse de formas dramáticamente distintas — perfiles de latencia distintos, estructuras de coste distintas, posturas de seguridad distintas. El Capítulo 8 cubre esa dimensión.
Próximamente — Capítulo 8: Distribuciones de despliegue. Tres maneras ampliamente distintas de desplegar MCP físicamente — modelo-con-servidor, modelo-en-cliente, híbrido — con los compromisos del mundo real en latencia, coste, complejidad operativa y los tipos de fallo que cada una hace más probables.
