Multi-Agent Coordination No es Añadir Más Agentes — Es Saber Cuándo No Usarlos
Multi-Agent Coordination en 2026: por qué 3 agentes mal coordinados son peores que 1. Patrones Supervisor, Router y Pipeline para construir AI agents que escalan de verdad.
El 90% de los Sistemas Multi-Agent en Producción No Son Multi-Agent
Abres el dashboard de tu agente. Ves tres "agentes" ejecutándose — análisis, redacción, revisión. Cada uno con su system prompt. Cada uno con su personalidad.
*El problema: son el mismo LLM con una máscara diferente. *
No hay coordinación real. No hay jerarquía. No hay validación cruzada. Lo que tienes no es un sistema multi-agente. Es un solo LLM instanciado tres veces con prompts distintos, lanzando mensajes al vacío y esperando que colaboren.
La industria te vende que más agentes = más capacidad.
La realidad: 3 agentes mal coordinados producen peores resultados que 1 agente bien diseñado.
Y el 90% de las implementaciones actuales — según datos del análisis interno del sector — son exactamente eso: un solo LLM disfrazado de múltiples agentes. La tasa de error compuesto — un agente que cascada su error sobre el siguiente — crece más rápido que cualquier ganancia de especialización.
Si estás buscando how to build ai agents 2026, el primer paso no es añadir más. Es quitarlos.
---
Por Qué Más Agentes No Escala Linealmente
Cada agente que añades introduce tres costes ocultos:
❌ Latencia compuesta: Cada llamada a un LLM suma ~1-3 segundos. Tres agentes en serie = 3-9 segundos por respuesta. El usuario espera.
❌ Desalineamiento de objetivos: Cada agente optimiza su sub-tarea. El agente de "análisis" quiere profundidad. El de "resumen" quiere brevedad. Se contradicen.
❌ Acoplamiento frágil: El output del agente A es el input del agente B. Si A alucina, B arrastra la alucinación. Y no hay quien reconcilie.
El mito: "Cada agente se especializa y el conjunto supera a la suma."
La realidad: La literatura emergente muestra que la tasa de error compuesto en sistemas multi-agente sin coordinación crece exponencialmente. No linealmente. Cada agente adicional no suma capacidad — suma riesgo de contradicción.
✅ Contraste: 1 agente con un prompt bien diseñado y un presupuesto de tokens equivalente rinde igual o mejor que 3 agentes peer-to-peer en el 80% de las tareas comunes.
La pregunta no es "¿cuántos agentes necesito?". Es "¿qué parte de esta tarea necesita realmente un LLM?".
---
Los 3 Patrones de Coordinación Que Sí Funcionan
Después de implementar sistemas multi-agente en producción — desde gestorías hasta emergencias médicas — he destilado los únicos 3 patrones que escalan sin romperse.
1. Patrón Supervisor: Jerarquía Real
El patrón más robusto. Un agente supervisor recibe la tarea, la descompone en subpasos, delega a subagentes especializados, y — esto es clave — valida y reconcilia los resultados antes de devolverlos.
```python
import asyncio
from openai import AsyncOpenAI
client = AsyncOpenAI()
class SupervisorAgent:
def __init__(self):
self.subagents = {
"analyst": {"model": "gpt-4o", "system": "Eres un analista de datos. Devuelve JSON con {findings, confidence, sources}"},
"writer": {"model": "gpt-4o", "system": "Eres un redactor técnico. Devuelve JSON con {draft, word_count, tone}"},
"reviewer": {"model": "gpt-4o", "system": "Eres un revisor crítico. Devuelve JSON con {issues, suggestions, score}"}
}
async def decompose(self, task: str) -> list[str]:
"""El supervisor decide los subpasos necesarios"""
response = await client.chat.completions.create(
model="gpt-4o",
messages=[{
"role": "system",
"content": "Descompón esta tarea en subtareas. Devuelve array JSON de strings."
}, {
"role": "user",
"content": task
}]
)
return eval(response.choices[0].message.content)
async def execute_subtask(self, agent_key: str, subtask: str) -> dict:
config = self.subagents[agent_key]
response = await client.chat.completions.create(
model=config["model"],
messages=[
{"role": "system", "content": config["system"]},
{"role": "user", "content": subtask}
],
response_format={"type": "json_object"}
)
return eval(response.choices[0].message.content)
async def validate_and_reconcile(self, task: str, results: list[dict]) -> dict:
"""Paso crítico: el supervisor detecta inconsistencias"""
response = await client.chat.completions.create(
model="gpt-4o",
messages=[{
"role": "system",
"content": "Eres un supervisor. Revisa estos resultados de subagentes. "
"Identifica contradicciones. Produce un output final consolidado. "
"Devuelve JSON con {final_output, contradictions_resolved, confidence}"
}, {
"role": "user",
"content": f"Tarea original: {task}\nResultados: {results}"
}],
response_format={"type": "json_object"}
)
return eval(response.choices[0].message.content)
async def run(self, task: str) -> dict:
subtasks = await self.decompose(task)
results = []
for i, subtask in enumerate(subtasks):
agent_key = list(self.subagents.keys())[i % len(self.subagents)]
result = await self.execute_subtask(agent_key, subtask)
results.append(result)
return await self.validate_and_reconcile(task, results)
```
Por qué funciona: El supervisor no solo delega. Valida. Si el analyst devuelve un hallazgo que contradice al reviewer, el supervisor lo detecta en el paso de reconciliación y pide una segunda opinión antes de devolver el resultado.
2. Patrón Orquestador-Enrutador: Múltiples Tipos de Consulta
No todas las consultas necesitan el mismo pipeline. Algunas requieren búsqueda. Otras, cálculo. Otras, simple formateo.
El patrón Router usa un agente orquestador que clasifica la consulta y la enruta al subagente correcto — o a una función determinista.
```python
import re
from enum import Enum
class TaskType(Enum):
SEARCH = "search"
CALCULATION = "calculation"
FORMATTING = "formatting"
COMPLEX_REASONING = "complex_reasoning"
class RouterAgent:
def __init__(self):
self.deterministic_routes = {
TaskType.FORMATTING: self.format_output,
TaskType.CALCULATION: self.calculate
}
self.llm_routes = {
TaskType.SEARCH: self.search_agent,
TaskType.COMPLEX_REASONING: self.reasoning_agent
}
def classify(self, query: str) -> TaskType:
"""Clasificación determinista — no necesita LLM"""
Regex y reglas: más barato y fiable que otro agente
if re.search(r"formatea|convierte|parsea", query.lower()):
return TaskType.FORMATTING
if re.search(r"calcula|suma|resta|promedio", query.lower()):
return TaskType.CALCULATION
if "busca" in query.lower() or "encuentra" in query.lower():
return TaskType.SEARCH
return TaskType.COMPLEX_REASONING
def format_output(self, data: str) -> str:
"""Función determinista — 0 coste de inferencia"""
import json
return json.dumps({"formatted": data, "method": "deterministic"})
def calculate(self, expression: str) -> str:
"""Cálculo exacto — un LLM aquí metería errores tontos"""
Safe eval con restricciones
allowed = re.findall(r"[\d+\-*/().]", expression)
return str(eval("".join(allowed)))
async def route(self, query: str, data: str = "") -> str:
task_type = self.classify(query)
if task_type in self.deterministic_routes:
Más barato, más rápido, más fiable
return self.deterministic_routestask_type
Solo aquí gastamos inferencia
agent = self.llm_routes[task_type]
return await agent(query)
```
La clave: el 40-60% de las rutas pueden resolverse con código determinista — regex, cálculos, búsquedas exactas. Cada una de esas rutas ahorra ~2 segundos de latencia y ~0.01€ en coste de inferencia. En 10.000 requests, eso es tiempo y dinero real.
3. Patrón Pipeline Secuencial: Transformaciones Lineales
Para tareas donde los pasos son estrictamente secuenciales — transformar datos, traducir, resumir — no necesitas un supervisor. Necesitas un pipeline con validación entre cada paso.
✅ Pipeline validado: Paso A → validación → Paso B → validación → output
❌ Coreografía peer-to-peer: Agente A → Agente B → Agente C (sin validación intermedia, errores en cascada)
El secreto del Pipeline es la validación post-ejecución. Cada paso verifica que el output del paso anterior es coherente antes de continuar. Si falla, reintenta con el paso anterior, no desde cero.
---
El Framework: Cómo Decidir Cuándo Usar Multi-Agent
Basado en implementaciones reales, aquí está el marco de decisión:
Paso 1: Audita tu sistema actual
Identifica cuántos de tus "agentes" son realmente necesarios. Mide la tasa de contradicción: ejecuta el mismo input contra tres agentes y cuenta cuántas veces sus outputs son incompatibles. Si es >15%, tienes un problema de coordinación, no de capacidad.
Paso 2: Elige el patrón según el caso
| Tipo de tarea | Patrón recomendado | Por qué |
|---|---|---|
| Tareas complejas con subpasos | Supervisor | Validación centralizada |
| Múltiples tipos de consulta | Router | Enrutamiento eficiente |
| Transformaciones lineales | Pipeline | Simplicidad + validación por paso |
| Tareas simples (1 paso) | 1 agente, no multi | Añadir agentes empeora el resultado |
Paso 3: Implementa un contrato de comunicación explícito
Cada subagente debe tener un formato de entrada y salida definido. JSON tipado. Esquemas. Sin "devuélveme lo que creas correcto". El orquestador no puede reconciliar outputs que no entiende.
```python
Contrato de comunicación para subagentes
CONTRATO_SUBAGENTE = {
"input": {"type": "object", "properties": {"task": "string", "context": "object"}},
"output": {"type": "object", "properties": {
"result": "string",
"confidence": "number",
"warnings": "array"
}},
"fallback": {"type": "string", "enum": ["retry", "escalate", "skip"]}
}
```
Paso 4: Añade validación post-ejecución
El paso que casi nadie implementa. Después de que los subagentes devuelvan sus resultados, el orquestador debe:
1. Comparar outputs en busca de contradicciones
2. Calcular un score de confianza combinado
3. Decidir si el resultado es aceptable o necesita reintento
Paso 5: Mide contra un baseline justo
No compares tu sistema multi-agente contra "un solo agente sin prompt engineering". Compáralo contra un solo agente con el mismo presupuesto de tokens, el mismo prompt engineering y el mismo fine-tuning.
Cuando haces esa comparación controlada, las ventajas del multi-agente se reducen drásticamente. Se limitan a casos donde necesitas perspectivas verdaderamente ortogonales — no tres versiones del mismo modelo pensando igual.
---
El Anti-Patrón: Lo Que La Mayoría Hace Mal
Aquí está el código que veo en el 90% de los proyectos que audito:
```python
ANTI-PATRÓN: 3 agentes peer-to-peer sin coordinación
class BadMultiAgent:
async def run(self, task: str) -> str:
Cada agente recibe el mismo contexto y se pasa mensajes
agent_a = await self.call_llm(f"Analiza: {task}")
agent_b = await self.call_llm(f"Redacta basado en: {agent_a}")
agent_c = await self.call_llm(f"Revisa: {agent_b}")
Nadie valida. Nadie reconcilia. El error de A se arrastra a C.
return agent_c
```
Problemas:
El error de `agent_a` se arrastra a `agent_c` sin corrección
No hay validación intermedia
Cada agente gasta tokens en el contexto completo — coste 3x innecesario
Si `agent_b` alucina, `agent_c` asume que es verdad y empeora la salida
La solución: aplica el patrón Supervisor. Un solo agente que coordina, valida y decide.
---
Cuándo NO Usar un Agente (Sí, Leíste Bien)
El punto ciego más común: asumir que todo debe ser un LLM.
En producción, estas tareas no deberían ser agentes:
Formateo de datos: `json.dumps()` es más barato y no alucina
Validación de esquemas: Pydantic o Zod. No un prompt.
Búsqueda exacta: Índices vectoriales o SQL. No "busca en la base de datos" como tool call.
Transformaciones predecibles: Regex. Expresiones aritméticas. Mapeo de valores.
Un sistema multi-agente bien diseñado sabe cuándo llamar a una función en lugar de a otro agente. Cada llamada determinista que eliminas reduce costes de inferencia y latencia entre un 40-60% en tareas híbridas.
La decisión más inteligente que puedes tomar al aprender how to build ai agents 2026 no es qué framework usar. Es qué parte de tu pipeline no necesita un LLM.
---
Conclusión: Menos Agentes, Mejor Coordinación
El hype del multi-agente te está vendiendo complejidad innecesaria.
Microsoft, Google y Anthropic lanzan frameworks (AutoGen, CrewAI, etc.) que estandarizan la coordinación — pero ningún framework arregla el problema de fondo: añadir agentes sin un patrón de coordinación real empeora los resultados.
Los 3 patrones que realmente funcionan:
1. Supervisor: para tareas complejas con subpasos que requieren validación
2. Router: para múltiples tipos de consulta con enrutamiento eficiente
3. Pipeline: para transformaciones lineales con validación por paso
Y el patrón más importante de todos: no usar un agente cuando una función determinista sirve.
La próxima vez que alguien te diga "necesitamos más agentes", pregúntale: "¿Has probado con uno bien hecho, una función determinista, y un prompt mejor?"
La respuesta, casi siempre, será que no.
Y esa es la diferencia entre un sistema que escala y uno que colecciona agentes.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF