La diapositiva de arquitectura de IA que más aparece en 2026 tiene 6–8 cajitas conectadas, cada una con nombre lindo: orchestrator, researcher, writer, critic, executor. Es la era del multi-agent system. La promesa: agentes especializados colaboran, cada uno hace lo que sabe mejor, el resultado emergente supera a cualquier agente monolítico. En algunos casos, verdad. En la mayoría, fantasía operativa vendida como sofisticación.
Este texto va sobre cuándo multi-agent rinde, cuándo es overhead caro disfrazado, y la regla para decidir antes de gastar tres meses construyendo orquestación que debería haber sido un agente único.
Qué separa multi-agent real de teatro
Multi-agent system no es "agente que llama a otro agente". Con esa definición, cualquier LLM con tool use se vuelve multi-agent — y el término pierde sentido. La definición útil es más estrecha: sistema donde múltiples agentes mantienen estado propio, razonan independientemente y coordinan decisiones compartidas.
Bajo esa definición, tres cosas necesitan estar presentes para merecer el nombre:
- Especialización real. Cada agente hace algo cualitativamente distinto — no es una división arbitraria de tareas.
- Estado independiente. Cada agente mantiene contexto propio, memoria, perspectiva. No es solo fan-out paralelo de llamadas.
- Coordinación no-trivial. Existe un protocolo de comunicación, reglas de quién decide qué, y el resultado depende de la interacción. No es orquestador llamando funciones.
Sin esos tres, el sistema es monolito con prompt chain — más barato, más rápido, más fácil de debuguear. Llamarlo multi-agent es jerga.
Multi-agent es una de las herramientas más sofisticadas — y más frecuentemente mal aplicadas — de 2026. Para la mayoría de los casos, un agente único con tools bien diseñadas resuelve mejor.
Los tres casos donde multi-agent rinde
Los contextos donde la arquitectura tiene sentido. Todos tienen algo en común: el costo de coordinación es menor que la ganancia de especialización.
- Tareas largas con perspectivas inherentemente distintas. Generación de código + revisión crítica + test. Investigación + escritura + edición. Acá tiene sentido que un agente genere y otro critique — porque la perspectiva crítica es distinta de la generativa. Un único agente haciendo ambas tiene sesgo (le gusta la propia respuesta). El costo de coordinación lo paga la ganancia de calidad.
- Dominios técnicos heterogéneos con expertise distinta. Sistema que necesita razonamiento jurídico + análisis financiero + redacción comercial. Cada uno exige prompt, base de conocimiento y tono distintos. Agente único queda mediocre en todo; agentes especialistas brillan cada uno en su dominio, orquestador coordina.
- Workflows con decisión humana entre etapas. Sistemas donde el humano aprueba entre pasos, o donde diferentes humanos interactúan con diferentes agentes. Estructura natural multi-agent refleja la estructura humana — no intenta ocultarla.
Fuera de esos tres, multi-agent tiende a ser sobre-ingeniería. Y sobre-ingeniería en IA cuesta más que en sistema tradicional, porque la latencia se compone (cada agente agrega tiempo de inferencia) y el costo se multiplica (cada agente corre LLM, cada coordinación cuesta tokens).
Los dos antipatrones más caros
Donde multi-agent se vuelve teatro, el error tiene nombre.
Antipatrón 1: dividir una tarea única en N agentes "porque parece organizado". El equipo arma agente que clasifica intent, agente que extrae entidades, agente que busca contexto, agente que genera respuesta. Cada uno es una llamada LLM. El sistema queda 4× más lento, cuesta 4× más, y la calidad no mejora — porque la división es arbitraria. Un único agente con instrucción clara y tool calling resolvería el mismo problema en una sola llamada.
Antipatrón 2: orchestrator + workers idénticos. "Tengamos un agente master que distribuye tareas a 5 workers en paralelo". Si los workers hacen lo mismo, eso es fan-out — no multi-agent. Puede hasta ser útil para paralelizar, pero no lo llames multi-agent. Y en el 80% de los casos donde aparece, la ganancia de paralelización es menor que el overhead de coordinación.
Esos dos antipatrones cubren la mayoría de los sistemas que se llaman "multi-agent" en presentación de conferencia y en práctica son prompt chains caros.
La regla honesta antes de decidir
Antes de aprobar arquitectura multi-agent, cinco preguntas separan decisión técnica de moda.
- ¿La división entre agentes es cualitativa o solo de tarea? Diferentes perspectivas, expertise o estados = cualitativa, multi-agent tiene sentido. Misma cosa en pedazos = monolito es mejor.
- ¿Cuánto cuesta en latencia total? Cada agente agrega 1–5s de inferencia. Sistema con 5 agentes puede quedar inutilizable en UX síncrona. Rinde en workflow asíncrono; mata en chatbot tiempo-real.
- ¿Cuánto cuesta en tokens totales? La coordinación consume tokens. Sistema multi-agent típico cuesta 3–10× más que monolito equivalente. Calcular antes de firmar contrato anual.
- ¿Cómo es el debugging? Multi-agent es multiplicativamente más difícil de debuguear — necesitás rastrear estado en N agentes + protocolo de comunicación. Sin evaluación seria, el sistema se vuelve caja negra en 6 meses.
- ¿Existe un único agente que resuelve al 70%? Si sí, empezá con él. Subí a multi-agent solo después de agotarlo. Invertir cuesta caro.
Quien responde las cinco con claridad sabe si multi-agent es necesario u ornamento. Quien responde "depende" en tres o más todavía no tiene caso de uso definido para ninguna arquitectura.
El paralelo con LLM como agente interno
Como argumenté sobre LLM como agente interno, el error más común en IA empresarial es tratar la herramienta como solución universal. El multi-agent system carga el mismo error en otra capa: la tentación de usar arquitectura sofisticada porque está disponible, aunque el caso de uso no lo pida.
La ganancia técnica de multi-agent es real donde aplicable. El costo es alto donde no. La diferencia entre proyecto que rinde y teatro de IA es, otra vez, disciplina de alcance.
La decisión para 2026
Si tu empresa está discutiendo multi-agent, tres movimientos honestos antes de comprometer arquitectura:
Empezá con agente único y tools bien diseñadas. Cubre el 70–80% de los casos de uso que aparecen como "necesitamos multi-agent". Tool calling con instrucción clara sustituye orquestación en casi todo.
Pilotá multi-agent solo donde la especialización es cualitativa. Generación + crítica es el caso más clásico que vale. Mezcla de dominios técnicos heterogéneos, segundo lugar. Otros casos, volver al agente único.
Medí latencia y costo desde el primer prototipo. Multi-agent escala mal en ambos. Descubrirlo en producción es caro; descubrirlo en piloto es barato.
La peor decisión de IA empresarial en 2026 es confundir sofisticación con necesidad. Multi-agent system es poderoso donde encaja. Aplicarlo en todos lados es la forma más cara de hacer con cinco agentes lo que uno haría mejor. (Para quien quiere ver esto en la operación real, con 5 agentes en producción por 90 días y los errores nombrados, el diario de campo está acá.)