Orquestación multi-agente, varios servidores juntos

Un agente con un MCP server es el caso simple. El trabajo serio normalmente necesita varios roles a la vez. Un Research busca, un Critic discrepa, un Analyst contrasta con lo conocido. Un coordinador (a menudo "CEO Agent") sintetiza. Esta lección muestra cómo se monta técnicamente.

Los tres workers clásicos, otra vez

En el Nivel 5 conociste los tres workers: Research, Critic, Analyst. Los roles no son invento mío, surgen solos cuando construyes suficientes sistemas multi-agente. Ahora se trata de cómo implementarlos, no de qué hacen.

El patrón base

Por worker construyes un script propio / una llamada a server propia. Cada uno tiene:

• un rol claro como system prompt
• acceso a las mismas tools (MCP servers) o subconjuntos específicos
• un input definido (la pregunta / el tema)
• un output definido (un fichero Markdown, una fila en BD, un informe)

El CEO llama los tres en paralelo, espera a que estén los tres informes y los sintetiza en una recomendación.

En pseudocódigo:

async function runAgents(topic) {
  const [researchReport, criticReport, analystReport] = await Promise.all([
    runResearchAgent(topic),
    runCriticAgent(topic),
    runAnalystAgent(topic),
  ]);
  return synthesize(researchReport, criticReport, analystReport);
}

Esa es la arquitectura. Simple. Casi todo lo que ves en setups multi-agente es una variación.

Los seis patrones comunes

Cuando empieces a leer código multi-agente, verás siempre los mismos seis patrones. El mapa:

| Patrón | Agentes | Mecánica núcleo | Dónde vive típicamente | |---------|:-:|---------------|---------------| | Sequential pipeline | 1-3 | Cadena lineal A → B → C, cada uno depende del output anterior | Todos los frameworks de forma nativa | | Flat supervisor | 3-5 | Orchestrator central delega en workers, sintetiza outputs | LangGraph supervisor node, CrewAI Process.hierarchical, AutoGen GroupChatManager | | Hierarchical | 10-20+ | Supervisor recursivo con varios niveles, contexto gestionado por capas | LangGraph nested subgraphs, AutoGen SocietyOfMind | | Parallel fan-out | 4+ independientes | Varios agents en subtasks en paralelo, aggregator hace merge | Patrón manual, casi todos los frameworks | | Swarm | 5-15 | Descentralizado, cada agent puede pasar a cualquier otro | OpenAI Swarm (deprecated), LangGraph handoffs | | Blackboard | Variable | Estado compartido, los agents leen + escriben schema tipado | Rara vez nativo de framework, mayormente manual |

El umbral práctico es claro: 1-3 agentes corren mejor como sequential pipeline, sin overhead de orchestrator. 3-5 quieren un supervisor, ese es el sweet spot. A partir de 10 necesitas hierarchical, si no, el contexto del orchestrator se mata a sí mismo porque su histórico está dominado por todos los round-trips de los sub-agents.

Paralelo vs secuencial

Paralelo cuando el trabajo es independiente. Research no necesita saber qué piensa Critic, ven el mismo tema desde lados distintos. Es rápido y honesto.

Secuencial merece la pena cuando el agent B necesita realmente el input del agent A. Ejemplo: el agent A escribe un post de blog, el agent B lo edita. Ahí no hay paralelizar, B necesita el output de A como input.

La mayoría de tareas de análisis son paralelas. La mayoría de pipelines de producción son secuenciales. Combinaciones son normales: primero tres agents en paralelo (research), después un agent que sintetiza sus outputs (secuencial).

En segundos concretos, para que tengas sensación de las cifras. Una sequential chain con cinco agents y tres segundos por agent dura quince segundos mínimo, porque cada uno espera al anterior. Un setup hierarchical con tres niveles y dos segundos de coordination por nivel necesita seis segundos antes de que arranque siquiera un worker, cuatro niveles ocho. Con parallel fan-out con cuatro agents independientes, el tiempo total es el máximo de un agent más el aggregator, no la suma. Esa es la verdadera ventaja del paralelo: sin efecto suma.

El Neutrality Guard

Uno de los errores más importantes en setup multi-agent: el Critic ve los éxitos previos y empieza a confirmarlos en lugar de criticarlos. Eso mata todo el valor del Critic.

La solución es el Neutrality Guard: el Critic solo recibe "Mistakes" y "Warnings" del shared memory, nunca "Confirmations". Es un filtro en la llamada a la tool de memoria. El agent en sí no lo nota, simplemente no ve confirmaciones positivas en su histórico.

En la práctica significa: si tienes un shared memory store, implementas una vista por agent, no el store entero. El Researcher ve hallazgos de research, el Critic ve histórico de crítica, el Analyst ve patterns. Sin cross-contamination.

El CEO agent

El coordinador es también un agent. Su system prompt es distinto:

• Tiene los tres informes como input.
• Su tarea es síntesis, no duplicación.
• Puede discrepar si los tres informes son contradictorios.
• Da una recomendación con justificación, no solo un resumen.

Buenos prompts de CEO contienen frases como: "Cuando Research y Critic se contradigan, eso es oro, hazlo visible y pondéralo."

Budget de tokens por agent

Los setups multi-agent se ponen caros si no cuidas. Cada agent hace sus propias llamadas a modelo, lee sus propios ficheros, tiene sus propias llamadas a tool. Un setup con cuatro agents y 25 turnos por agent llega rápido a 400.000 tokens por corrida.

Contramedidas:

• Max-turns por agent limitado duro.
• Sonnet en lugar de Opus para agents simples (Critic suele ir bien con Sonnet).
• Budget de contexto, no se mete el histórico completo de informes en cada agent.
• Selección de tools. Research recibe tools de research, Critic de critic, no todos lo mismo.

En StudioMeyer una corrida full de 3-agent en Opus cuesta unos 3-5 dólares. Con Sonnet y budget limpio más cerca de 1 dólar. Manejable, pero solo si se calibra activamente.

Cuándo multi-agent es la solución equivocada

Si un buen single-agent con buen prompt entrega el mismo resultado, no construyas multi-agent. La complejidad cuesta tiempo, dinero, debugging. Multi-agent merece la pena cuando:

• Los roles tienen formas de pensar realmente distintas (lógica de critic vs lógica de research).
• El trabajo en paralelo aumenta significativamente el throughput.
• La tarea es demasiado grande para un contexto y la puedes dividir con sentido.

Si no, basta un single-agent con system prompts claros y chain-of-thought.

En junio 2025 Anthropic publicó para su propio research system que un setup con Claude Opus 4 (orchestrator) más varios Claude Sonnet 4 (sub-agents) batió al single-agent Opus en tareas de research en un 90,2 por ciento. No es hype, está medido. El truco no fue "más agents = mejor", sino límites duros de turnos, reglas explícitas de contribución y criterios de convergencia. Sin esos límites, las primeras variantes spawneaban 50+ sub-agents y quemaban tokens sin resultado.

Panorama de frameworks 2026

Si empiezas a comparar frameworks te abruma la cantidad de opciones que suenan iguales. Categorización honesta a abril 2026, ya que el mercado se ha consolidado fuerte desde finales de 2025.

Los production survivors son LangGraph (Uber, LinkedIn, Klarna, Replit, Cisco y Elastic lo usan productivamente), CrewAI (bueno para rapid prototyping con buenos defaults), Microsoft Agent Framework v1.0 del 7 de abril 2026 (el merge de AutoGen y Semantic Kernel), OpenAI Agents SDK y Claude Agent SDK de Anthropic. Esos son los cinco que puedes considerar en serio.

Deprecated y no recomendados: OpenAI Swarm está oficialmente muerto. El README del repo dice expresamente que ha sido reemplazado por el OpenAI Agents SDK. AutoGen corre solo en mantenimiento de bug-fix tras absorberse en Microsoft Agent Framework. Si encuentras una guía que recomiende estos dos, es vieja.

Notable también: LangChain mismo recomienda LangGraph para todos los workflows de agent en LangChain 1.0 y ha deprecado initialize_agent y AgentExecutor. Desde septiembre 2025, los LangChain agents internamente corren en LangGraph.

El benchmark independiente de aimultiple con 2000 corridas sobre 5 tasks dio este orden: LangChain es el más eficiente en tokens, AutoGen tiene la latencia más baja, LangGraph va pegado a LangChain en token y latencia, y CrewAI es el perfil más pesado con unas tres veces el coste de token y latencia comparado con LangChain en single tool calls. El overhead de CrewAI viene del "managerial deliberation" que el agent hace unos cinco segundos antes de cada acción. Útil en multi-step complejas, puro overhead en llamadas simples.

Aviso honesto sobre marketing: el README de CrewAI afirma "5.76x más rápido que LangGraph" y eso es self-reported. El benchmark de aimultiple encontró LangGraph 2.2x más rápido. Ambos llevan razón en dimensiones distintas. El 5.76x de CrewAI se refiere a development speed (cuán rápido construyes el prototipo), no a execution speed (cuán rápido corre luego). Cuando alguien tira "X veces más rápido", pregunta qué se midió: setup, token, runtime o escala.

Ejemplo real de StudioMeyer

Nex HQ (el repo interno de orquestación) tiene 9 agents + un Conductor. El Conductor no es un CEO agent clásico sino un cron scheduler que dispara agents a horas fijas (Guardian cada 30 minutos, Daily Research una vez al día, etc.). Research/Critic/Analyst se llaman on-demand en paralelo cuando Matthias dice "/agent-research X".

Los informes acaban en research/YYYY-MM-DD-{agent}-{topic}.md. Humanos revisan, los hallazgos van al sistema de memoria. En la siguiente corrida los agents ven el contexto histórico (con Neutrality Guard donde aplica).

Es un sistema multi-agent productivo desde febrero 2026, sin downtime, con coste manejable. Si quieres construir el tuyo, oriéntate ahí. El código no es público pero los patterns están documentados en esta lección y se mencionan en el Nivel 5.

Los primeros tres pasos para tu propio stack multi-agent

1. Empieza con dos agents, no tres. Research + Critic bastan para arrancar. Analyst entra cuando necesites contexto histórico.

2. Usa el mismo stack MCP para todos. No configurar servers por agent. Misma memoria, misma búsqueda web, misma code-intelligence si aplica.

3. Los informes acaban como ficheros Markdown. No directos a una BD, no directos a una API JSON. Markdown es el formato correcto porque los humanos lo leen y los agents en la siguiente corrida lo leen como contexto.

Fuentes para profundizar

Si quieres meterte más, las fuentes primarias de las cifras de esta lección:

• Anthropic Engineering Blog: anthropic.com/engineering/built-multi-agent-research-system (junio 2025, el paper del 90,2 por ciento)
• LangChain Blog: blog.langchain.com/building-langgraph (docs de arquitectura)
• Microsoft DevBlogs: devblogs.microsoft.com/semantic-kernel (Agent Framework v1.0 anuncio, abril 2026)
• AIMultiple Benchmark: aimultiple.com/agentic-frameworks (2000 corridas, 5 tasks, independiente)
• Augment Code Pattern Guide: augmentcode.com/guides/swarm-vs-supervisor (umbrales de patterns)

Sigue

La Lección 4 del Nivel 6 Deployment muestra cómo despliegas esta arquitectura de agents como servicio. Y el playbook "Memory portable" es la base para que tus agents puedan compartir memoria.