Introduccion
Cuando empiezas a construir un sistema Multi-Agent, es facil dejarse atraer por su forma.
Un agent planifica, otro ejecuta y otro revisa. En un sistema mas complejo se anaden investigadores, programadores, testers y supervisores. La consola se llena de tareas, mensajes y llamadas a herramientas; varios agents se ejecutan al mismo tiempo y todo parece profesional.
Pero cuanto mas profundice, mas clara se hizo la otra cara: el trabajo esta dividido, pero la responsabilidad no; los mensajes se enviaron, pero la informacion no se tomo realmente en cuenta; el flujo de revision termina, pero el resultado sigue sin servir.
Los problemas de un solo agent suelen ser directos: no entendio el requisito, fallo una llamada a herramienta o escribio codigo incorrecto. Normalmente puedes seguir una trayectoria de ejecucion hasta la causa. En Multi-Agent, el problema se distribuye entre descomposicion de tareas, transferencia de contexto, estado compartido, permisos de rol y aceptacion de resultados. Un fallo corriente al final puede haber empezado diez turnos antes.
Despues de construir flujos Plan-Exec, anadir Supervisors a agents de ejecucion y seguir experimentos de Anthropic, Google y Cursor, llegue a una conclusion:
Multi-Agent no convierte a una persona inteligente en una empresa. Convierte los problemas de un modelo en un conjunto de problemas organizativos.
Estas son mis siete observaciones.
1. Escribir cinco roles no significa que una tarea pueda dividirse en cinco
Lo mas sencillo al disenar Multi-Agent es definir roles: un product manager entiende la necesidad, un arquitecto disena la solucion, un programador escribe codigo, un tester valida la funcion y un CEO toma la decision final.
Suena razonable porque copia la estructura de una empresa humana. En ejecucion, a menudo no funciona asi.
Al disenar un flujo Plan-Exec vi que un Planner podia producir una lista aparentemente completa, mientras que el Executor no sabia que resultado verificable debia entregar cada paso. Una tarea decia “analiza las relaciones geometricas de la imagen”; otra, “dibuja a partir del analisis”. Nadie habia decidido si la primera debia devolver prosa, relaciones estructuradas o un DSL geometrico ejecutable. El primer agent escribio un analisis y el segundo miro la imagen de nuevo. La division de trabajo solo anadio una repeticion de la informacion.
Un equipo de Berkeley analizo siete sistemas Multi-Agent y mas de doscientas trayectorias de ejecucion; alrededor del 41.77% de los fallos fueron de especificacion y diseno del sistema: requisitos ignorados, roles ineficaces, pasos repetidos, contexto perdido y finalizacion ambigua.[1]
El problema no es que los nombres de los roles sean poco detallados. Los roles humanos tienen experiencia acumulada, limites de responsabilidad, normas profesionales y acuerdos por defecto. Escribir “eres un ingeniero de pruebas senior” en el system prompt anade contexto linguistico, pero no crea esas instituciones.
Los roles son narrativa; las interfaces son ingenieria. Si una subtarea no tiene entrada, salida, criterio de finalizacion y estado de fallo claros, no deberia entregarse a otro agent.
2. Las tareas que parecen paralelas suelen ocultar una cadena de pensamiento que no puede cortarse
Los sistemas multi-agent rinden bien en investigacion, y es logico. Investigar decenas de empresas, buscar vulnerabilidades en varios repositorios o reunir hechos dispersos de muchas paginas se puede dividir por objeto o direccion. Que una rama no encuentre nada no rompe las demas.
Pero el equipo Research de Anthropic indica que las tareas con mucho contexto compartido y dependencias mutuas no son una buena opcion para los Multi-Agent actuales. El codigo es un caso especialmente claro: las partes realmente independientes suelen ser menos de lo que parecen.[2]
El paralelismo puede reducir la cantidad de trabajo; no puede reducir las dependencias.
Google Research llego a una conclusion parecida con 180 configuraciones de agents. En tareas financieras que admitian analisis paralelo, un Multi-Agent centralizado supero a un solo agent en 80.9%. En PlanCraft, que exige planificacion continua, todas las arquitecturas Multi-Agent bajaron entre 39% y 70%.[3]
Cada relevo necesita explicar otra vez el estado actual. El juicio completo de un agent se comprime en una salida; el siguiente intenta reconstruir la situacion desde ella. Un razonamiento continuo se fragmenta y el sistema gasta mas tokens explicandose que resolviendo la tarea.
3. Cuando crece el numero de agents, lo primero que crece es el trabajo duplicado
Los logs de Multi-Agent crean una ilusion sencilla: varios agents buscan a la vez, el Supervisor reparte tareas, los ejecutores llaman herramientas y la interfaz dice continuamente “analizando”, “validando” y “mejorando”. El sistema parece muy ocupado.
Al mirar de cerca, aparecen resultados de busqueda parecidos, analisis equivalentes y contexto del proyecto leido repetidamente por distintos agents. Se gastaron mas tokens, pero no se produjo informacion proporcionalmente nueva.
MAST situa la repeticion de pasos como su fallo individual mas comun, con 17.14%. Recoge un caso simple: un usuario pidio las diez primeras canciones de una lista. El agent de Spotify podia devolverlas todas de una vez, pero el orquestador mantuvo diez intercambios y recupero una cancion cada vez.[1]
Normalmente no falta capacidad de modelo; al sistema le falta una granularidad correcta para asignar trabajo. En desarrollo aparece otro patron: el Supervisor detecta una salida incorrecta y ofrece feedback general; el Executor no localiza un defecto concreto y repite toda la tarea. El resultado cambia un poco, el Supervisor vuelve a revisarlo y ninguno corrige un problema conocido. Solo vuelven a muestrear la misma zona.
Algunos Multi-Agent no colaboran: se fabrican material de lectura unos a otros.
4. Si un pool de tareas se deja a agents autonomos, los problemas dificiles suelen quedarse sin responsable
Un diseno atractivo permite a varios agents iguales mirar un pool compartido y decidir que hacer. Encaja con la idea de colaboracion emergente: no hay un flujo fijo; los agents reclaman trabajo, actualizan estado y esperan resultados ajenos.
Cursor probo este esquema en experimentos largos de programacion. Los agents se coordinaban con archivos compartidos y locks para evitar reclamaciones duplicadas. Retenian locks mucho tiempo, olvidaban liberarlos, salian mientras los tenian o editaban sin tomarlos. Con veinte agents, el rendimiento efectivo equivalia a solo uno a tres agents; la mayor parte del tiempo se gastaba esperando.
Al retirar locks pesimistas y usar concurrencia optimista, bajo la contencion de archivos pero volvio el problema de propiedad. Los agents elegian cambios locales, seguros y faciles; nadie asumio el trabajo central complejo y arriesgado. Se acumulaban commits pequenos mientras la parte mas dificil del proyecto no avanzaba.[4]
Se parece a la difusion de responsabilidad en organizaciones humanas. La diferencia es que un agent no siente presion por el retraso ni consecuencias profesionales por evitar lo dificil. Una entrega final no puede surgir de forma fiable de workers sin un responsable final.
5. Que la informacion se publique en el grupo no significa que el sistema la conozca
En sistemas Multi-Agent es frecuente que aparezca un dato crucial sin que afecte las acciones posteriores. MAST documenta un caso donde un Phone Agent descubrio un requisito especial de la API para el formato de usuario, pero no comunico esa restriccion claramente al Supervisor. El Supervisor no pregunto, siguio probando el formato errado y la tarea fallo.[1]
Tambien sucede en la practica: un Supervisor ve un punto mal colocado en una figura geometrica y dice solo que la figura no coincide por completo; el agent ejecutor cambia el estilo de las lineas. Un agent detecta una contradiccion de requisitos, la deja como nota al final, y el siguiente continua con el plan original.
Para una persona, un mensaje en lenguaje natural lleva tono, prioridad y una senal de accion. Un agent solo recibe contexto. Si el sistema no diferencia explicitamente restricciones, decisiones y bloqueos, puede no entender por que importa un hecho.
6. Copiar diez veces el mismo modelo solo crea diez puntos ciegos parecidos
Solemos asumir que, si un agent puede equivocarse, tres agents votando seran mas fiables; o que un Reviewer encontrara lo que omitio el ejecutor. Esa logica exige que sus errores sean relativamente independientes.
Con el mismo modelo, prompts similares y la misma evidencia, la suposicion falla con frecuencia. Anthropic encontro que dieciocho de treinta agents creaban exactamente el mismo nombre de rama Git. Varios agents creativos escogieron el mismo titulo de novela sin una guia de genero. Al pedirles un proyecto impresionante, mas de la mitad eligio un ray tracer o un compilador autocontenido.[5]
A escala de una tarea, la homogeneidad parece repeticion. A escala de sistema, puede convertirse en congestion, estampida o juicio compartido equivocado. Google tambien encontro que agents independientes y sin coordinacion podian amplificar el error hasta 17.2 veces; un orquestador lo redujo, pero aun fue 4.4 veces. Cuando varios agents concuerdan, no trates su numero como el numero de evidencias independientes: pueden haber seguido el mismo sesgo de entrenamiento y ancla de prompt hasta la misma respuesta errada.
7. El debate entre agents a menudo no corrige el error: le da mejores razones
Algunos sistemas intentan resolver la homogeneidad mediante debate: un agent propone una respuesta, otro la cuestiona y, tras dos o tres rondas, votan. Se parece a revision por pares. En la practica, el primer agent puede dar una explicacion fluida pero incorrecta y los demas siguen su premisa. El razonamiento posterior se enriquece y el error inicial parece mas creible.
Un estudio con diez agents homogeneos y tres rondas de debate encontro adopcion de la mayoria de hasta 85.5%. Algunos agents que habian respondido bien cambiaron a la respuesta equivocada al ver las opiniones de otros. Frente a la autocorreccion aislada, el debate gasto de 2.1 a 3.4 veces mas tokens, con igual o menor precision.[6]
Los modelos son especialmente buenos continuando texto existente. Una vez que la primera respuesta entra en el contexto compartido, los agents posteriores ya no parten de una pagina en blanco; pueden estar revisandola o solo siendo influidos por ella. Un debate sin juicio independiente se convierte facilmente en una costosa afirmacion mutua.
Referencias
[1] Cemri, Mert et al. Why Do Multi-Agent LLM Systems Fail?. arXiv, 2025.
[2] Anthropic. How we built our multi-agent research system.
[3] Google Research. Towards a science of scaling agent systems: When and why agent systems work.
[4] Cursor. Scaling long-running autonomous coding.
[5] Anthropic. Patterns and problems in multiagent systems.
[6] The Cost of Consensus: Isolated Self-Correction Prevails Over Unguided Homogeneous Multi-Agent Debate. arXiv, 2026.