El 90% de los Sistemas "Multi-Agente" en Producción Son el Mismo LLM con Prompts Distintos
Antes de añadir tu segundo agente, lee esto.
El 90% de los sistemas "multi-agente" que ves en producción no son multi-agente en absoluto. Son un solo LLM instanciado tres veces con prompts distintos. Sin jerarquía. Sin contrato de datos compartido. Sin validación cruzada.
*Y el resultado medible es que 3 agentes mal coordinados funcionan peor que 1 agente bien hecho. *
No es una opinión. Es lo que pasa cuando el acoplamiento entre agentes es frágil y cada handoff multiplica errores en lugar de cancelarlos.
El ecosistema te vende lo contrario. Frameworks, marketplaces y demos empujan la narrativa del "enjambre de agentes": más agentes = más capacidad. Añade un agente de investigación, otro de redacción, otro de revisión, y el resultado debería mejorar, ¿no?
No. No escala así. La capacidad no escala con el número de agentes. Escala el error compuesto — y eso va en tu contra.
El Problema Real No es el Número de Agentes. Es el Acoplamiento Frágil
La causa raíz del fallo en sistemas multi-agente no son los agentes. Es el acoplamiento entre ellos.
Piénsalo. En una cadena de N agentes, la salida de cada uno es la entrada del siguiente. Cada handoff es una oportunidad de amplificar una alucinación. Si el agente A produce un formato ligeramente distinto al que el agente B espera, todo se rompe. Si A inventa un dato, B lo toma como verdad y lo embellece, y C lo escribe en la respuesta final.
Por eso más agentes no escalan linealmente. Cada agente extra añade puntos de acoplamiento y rutas de propagación de errores. No es que los agentes sean malos. Es que cada uno multiplica la superficie de fallo.
Y aquí viene lo incómodo: si tu "multi-agente" es el mismo modelo con prompts distintos pasando texto libre entre sí, no tienes N agentes. Tienes N prompts, N puntos de fallo, y cero capacidad extra.
El problema es un problema de diseño de interfaces. Cada subagente debe tratar su entrada y salida como un contrato de API: esquemas tipados, validación, versionado. Si dejas los handoffs como texto libre, estás definiendo exactamente el acoplamiento frágil que mata a estos sistemas.
El Test de los 3 Elementos: ¿Tu Sistema es Real o es Role-Play?
Antes de tocar una línea de código, audita tu sistema actual contra el test de los 3 elementos. Un sistema multi-agente real tiene los tres:
1. Coordinación real: un planner o state machine que decide quién hace qué y cuándo.
2. Jerarquía: un orquestador que controla el flujo — los workers no hablan entre sí directamente.
3. Validación cruzada: un revisor o chequeo determinista que acepta o rechaza la salida de un worker antes de que propague.
❌ Anti-patrón (lo que hace el 90%): el mismo LLM con prompts distintos. Los agentes se pasan trozos de texto sin schema, sin estado, sin validación. Los errores se compilan a lo largo de la cadena.
✅ Patrón real: un orquestador que planea, despacha con contratos tipados, fusiona resultados, y decide cuándo re-ejecutar o rechazar la salida de un worker.
Si tu sistema no tiene los tres elementos, no tienes agentes. Tienes role-play con puntos de fallo extra.
Aquí tienes el anti-patrón para que lo reconozcas:
```python
ANTI-PATRÓN: el 90% de los "multi-agente" en producción
def mis_sistema_multiagente(tarea: str) -> str:
modelo = get_llm() # el MISMO modelo para todos
Agente "investigador" — solo cambia el system prompt
investigacion = modelo.complete(system="Eres un investigador.",
user=tarea)
Agente "redactor" — recibe texto libre, sin schema
borrador = modelo.complete(system="Eres un redactor.",
user=investigacion) # acoplamiento frágil
Agente "revisor" — valida... contra nada
final = modelo.complete(system="Eres un revisor.",
user=borrador)
return final
3 agentes, 0 jerarquía, 0 contrato, 3 sitios para amplificar errores
```
¿Ves el problema? Tres calls al mismo modelo. Cero esquemas. Cero validación. Si el "revisor" recibe un formato que no espera, falla silenciosamente. Si el "investigador" alucina, el "redactor" lo embellece y el "revisor" lo aprueba.
Ese es el acoplamiento frágil en su forma pura.
¿Los Benchmarks Publicados No Muestran que Multi-Agente Gana?
Sí. Y eso confirma la tesis en lugar de contradecirla.
Los benchmarks que muestran a sistemas multi-agente ganando a un solo agente vienen de setups meticulosamente orquestados: jerarquía, handoffs tipados, validación. Es decir, la coordinación real que los sistemas de producción no tienen.
El benchmark es la prueba. La calidad del resultado no la determina el número de agentes. La determina la calidad de la orquestación.
Y si tu equipo pregunta "¿diferentes prompts no crean efectivamente agentes distintos?" — no. La variación de prompts cambia el comportamiento, no la arquitectura. No hay jerarquía, no hay contrato de estado compartido, no hay loop de validación. Es un modelo haciendo role-play con puntos de fallo añadidos.
La especialización real requiere tres cosas que el role-play no tiene: herramientas distintas, contexto distinto, e una interfaz explícita.
El Marco de las 3 Preguntas del Orquestador
Cuando el multi-agente gana de verdad, es para subproblemas paralelizables e independientes con un paso de fusión — como investigación en varias fuentes más una pasada de revisión — donde un solo agente agotaría su ventana de contexto.
Las tareas secuenciales y dependientes son el peor encaje posible: acoplamiento máximo, paralelismo cero, y todos los beneficios del patrón desaparecen.
Aquí va el Marco de las 3 Preguntas del Orquestador. Antes de añadir cualquier agente extra, respóndelas:
Pregunta 1 — ¿Tengo baseline de un solo agente?
Construye el agente único excelente primero: un modelo, buenas tools, output estructurado. Mídele la tasa de éxito sobre un test set fijo. Cada afirmación multi-agente de tu sistema debe validarse contra este número.
Pregunta 2 — ¿El subproblema es genuinamente independiente?
¿Puede ejecutarse en paralelo sin depender de la salida del otro? Si la secuencia es estrictamente dependiente, un solo agente con tools hace el trabajo sin los puntos de fallo extra.
Pregunta 3 — ¿Tengo contrato tipado y validación?
Cada handoff es un schema tipado (Pydantic, JSON Schema, lo que sea). Workers nunca se pasan texto libre. Y un crítico — o chequeos deterministas — acepta o rechaza contra el plan antes de que propague.
Este es el patrón real, con contrato tipado y validación:
```python
from pydantic import BaseModel
from typing import List, Optional
from enum import Enum
class Subtarea(BaseModel):
id: str
tipo: str # "investigacion" | "redaccion"
instrucciones: str
estado: str = "pendiente"
resultado: Optional[str] = None
validado: bool = False
class Plan(BaseModel):
subtareas: List[Subtarea]
prioridad: List[str]
merge_rule: str = "concurrente"
El orquestador: planea, despacha, fusiona, decide
class Orquestador:
def planificar(self, tarea: str) -> Plan:
Un planner DE DETERMINISTA extrae subtareas
No es otro LLM role-play: es lógica de negocio
return self.splitter.extraer_subtareas(tarea)
def ejecutar(self, plan: Plan) -> dict:
resultados = {}
for sub in plan.subtareas:
worker = self.get_worker(sub.tipo) # herramienta/esquema propio
salida = worker.ejecutar(sub.instrucciones, schema=SchemaEsperado)
Validación cruzada ANTES de propagar
if not self.validador.aprobar(salida, contra=plan):
salida = worker.reescribir(sub.instrucciones, feedback)
resultados[sub.id] = salida
return self.merge(resultados, plan.merge_rule)
jerarquía (orquestador manda), contrato (schemas), validación (aprobar/rechazar)
```
⚠️ Comparación de tools (todas válidas):
LangGraph: orquestación basada en grafo con estado explícito y edges tipados. El más cercano al patrón jerarquía + contrato.
CrewAI: crews por roles con control de proceso integrado. Buen punto de partida si no quieres construir el state machine a mano.
AutoGen: conversacional. Más fácil caer en el anti-patrón de texto libre entre agentes.
State machine a mano: prefieres el control total. El patrón no depende del framework.
El Paso Más Importante: Mide la Regresión
Aquí está la parte que casi nadie hace.
Construye tu pipeline multi-agente. Ejecútalo sobre el mismo test set fijo que usaste para el baseline de un solo agente. Compara tasas de éxito.
Si el pipeline multi-agente no supera al baseline, reverte. Coordinación solo se justifica con ganancia medida.
Y la predicción incómoda: en muchos casos no la superará. El multi-agente gana solo cuando hay paralelismo real — tareas independientes que un solo agente no puede ejecutar sin agotar su ventana de contexto. Investigación multicanal, análisis de documentos largos con pasada de revisión, generación de contenido con revisión independiente.
Las cadenas secuenciales dependientes — donde cada agente espera la salida del anterior — son cargo cult. El peor encaje posible.
¿"¿Pero no hay tareas que genuinamente necesitan más de un agente?" Sí. El argumento es condicional:
✅ Multi-agente justificado: subproblemas paralelos e independientes con paso de fusión. La coordinación está diseñada (contratos, jerarquía, validación) y medida contra el baseline.
❌ Multi-agente como cargo cult: cadenas secuenciales dependientes donde los agentes se pasan texto libre. Máximo acoplamiento, cero paralelismo, error compuesto.
La Verdad Incómoda Sobre el 90%
Seamos honestos: la cifra del 90% es una tesis de practicante, no un benchmark medido de la industria. Es una afirmación direccional.
Pero es falsable y barata de testear. Audita tus propios sistemas:
¿Cuántos de tus "agentes" comparten el mismo modelo? ¿Cuántos no tienen paso de validación? ¿Cuántos handoffs son texto libre sin schema?
Si la mayoría — ya sabes la respuesta.
El camino correcto es el que casi nadie sigue: construye UN agente excelente con tools antes de añadir un segundo. Mídelo. Y solo entonces, si el problema es genuinamente paralelo, añade trabajadores con contratos tipados y un supervisor que apruebe o rechace.
La pregunta correcta no es "¿cuántos agentes?". Es "¿dónde está la coordinación?" — y la respuesta incómoda es que la mayoría de los equipos deberían construir un agente excelente antes de soñar con el segundo.
La coordinación no se añade. Se diseña. Y se mide. O no existe.
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