Multiagente vs agente único: framework con 3 casos reales
DominicodeHace tres semanas monté un pipeline de cuatro agentes para una feature que no necesitaba ni uno: planner, coder, reviewer y tester, cada uno con su propio prompt y su propia ventana de contexto. Se sentía como arquitectura seria.
Tardó el triple que si lo hubiera hecho con un solo agente bien instruido. Gasté más tokens coordinando handoffs entre roles que resolviendo el problema real. Y el resultado no fue mejor — fue distinto, y peor: el reviewer contradecía decisiones que el coder ya había tomado con buen criterio.
Ese día entendí que la pregunta multiagente vs un solo agente no se responde por instinto ni por moda. Se responde con criterios concretos, y esos criterios ya los han medido equipos que sí llevaron el experimento a producción, no solo a un demo.
En corto: multiagente vale la pena cuando las subtareas son realmente paralelas, casi no comparten contexto, y el resultado justifica pagar entre 4 y 15 veces más tokens. Si tus subtareas dependen unas de otras —como pasa en la mayoría del código— un solo agente bien instruido gana en velocidad, coste y calidad. Orquestar varios agentes no es gratis: se gana con datos, no con intuición.
¿Qué es un sistema multiagente?
Un sistema multiagente es una arquitectura de IA donde varios agentes —con roles, prompts o ventanas de contexto distintas— colaboran, en paralelo o en secuencia, para completar una tarea que en teoría podría resolver un solo agente con suficiente contexto y herramientas.
La palabra clave es "en teoría". Que se pueda dividir un problema en roles no significa que dividirlo mejore el resultado — ya expliqué por qué el mega-prompt falla cuando se resuelve metiendo más subagentes sin criterio. La mayoría de los equipos confunden "se puede separar" con "conviene separar" — y esa confusión se siente más profesional, con nombres de rol y diagramas de flujo, aunque cada agente adicional solo añade un punto de fallo más y una llamada más al modelo que pagar.
Tres equipos distintos, en dominios distintos, ya midieron esto en producción. Sus resultados no coinciden en la respuesta, pero sí coinciden en el criterio.
Tres casos reales que no dicen lo mismo (y por eso sirven)
| Caso | Qué se comparó | Resultado multiagente | Resultado agente único | Quién ganó y por qué |
|---|---|---|---|---|
| Anthropic — Claude Research | Preguntas "breadth-first" con varios subagentes en paralelo vs. Claude Opus 4 solo | 90,2% mejor que el agente único en su eval interna, pero consume ~15x los tokens de una conversación normal | Consume ~4x los tokens de una conversación normal; peor en exploración amplia de fuentes independientes | Multiagente. Las subtareas eran genuinamente independientes y el valor de la respuesta justificaba el coste. Anthropic aclara que en coding, con dependencias fuertes, esto no aplica |
| Cognition (equipo de Devin) — "Don't Build Multi-Agents" | Subagentes paralelos construyendo partes de una misma app vs. un agente lineal con historial comprimido | Subagentes con contexto fragmentado tomaron decisiones incompatibles entre sí sin verlo (estilos, assets, nombres) | Un agente que arrastra el contexto de cada decisión previa, con resúmenes comprimidos en tareas largas | Agente único. El código depende de decisiones implícitas coherentes que solo sobreviven con contexto compartido real |
| Uncle Bob — harness SwarmForge | Harness con 6 roles fijos vs. un solo agente en la misma tarea de desarrollo | 3-4 horas, calidad aceptable | 40 minutos, calidad superior, consumo de tokens muchísimo menor | Agente único. La orquestación rígida sumaba overhead sin sumar calidad; los gates de verificación siguieron siendo necesarios en ambos casos |
Nota lo que no dicen estos tres casos: no dicen "el multiagente está muerto" ni "siempre gana un solo agente". Dicen que cada arquitectura gana cuando el problema tiene una forma concreta, y esa forma se puede medir antes de construir nada.
El propio lanzamiento del post de Cognition generó un hilo largo en Hacker News donde varios ingenieros coinciden en algo puntual: los subagentes sirven para aislar contexto que ensucia el prompt principal, no para repartir trabajo autónomo sin supervisión. Un comentarista lo resume mejor que cualquier framework: "si necesitas pensar distinto sobre el problema, necesitas un agente distinto" — si el razonamiento es el mismo con datos distintos, es el mismo agente.
El framework: cinco criterios, no una moneda al aire
De los tres casos sale un patrón repetido. Lo convertí en cinco criterios que reviso antes de escribir el primer prompt de orquestación.
| Criterio | Señal de que multiagente vale la pena | Señal de que gana un solo agente | Peso |
|---|---|---|---|
| Paralelismo real de las subtareas | Las subtareas son independientes: ninguna necesita ver el resultado de otra hasta el final | Las subtareas se encadenan paso a paso (editar y refactorizar código) | Alto |
| Coste en tokens vs. ahorro de tiempo humano | El resultado justifica pagar 4x-15x tokens (investigación, análisis masivo, due diligence) | La tarea es rutinaria y el ahorro de tiempo no compensa el gasto extra | Alto |
| Dependencias y decisiones implícitas compartidas | Ninguna decisión de un agente condiciona lo que hace otro | Una decisión de un paso condiciona el siguiente (arquitectura, nombres, estilo) | Alto |
| Especialización de contexto vs. overhead de coordinación | Cada rol necesita un contexto tan distinto que mezclarlo degrada el prompt (buscar en la web vs. escribir código) | Los roles comparten casi todo el contexto — separarlos solo añade handoffs | Medio |
| Necesidad real de "pensar distinto" | La tarea exige un tipo de razonamiento distinto por fase (buscar, sintetizar, criticar) | Todo el trabajo usa el mismo tipo de razonamiento aunque tenga varios pasos | Medio |
| Riesgo si te equivocas de opción | Pagas 4x-15x tokens sin ganar calidad, y los agentes pueden contradecirse entre sí sin que nadie lo note | Te quedas corto si el paralelismo era real: pierdes el tiempo que sí te habría ahorrado dividir el trabajo | — |
La heurística que uso es simple: si tres o más criterios de peso "Alto" apuntan a multiagente, lo construyo. Si no, empiezo con un solo agente bien instruido y solo divido cuando el contexto se vuelve imposible de manejar en una ventana — no antes, por elegancia arquitectónica.
Esto es exactamente la lógica que enseño en el curso Construye con IA: empezar con la arquitectura más simple que resuelve el problema, y añadir complejidad solo cuando el proyecto la reclama, no cuando la moda lo sugiere.
Un matiz que los tres casos comparten: la verificación no depende de la arquitectura. Tengas uno o seis agentes, necesitas gates deterministas —tests, tipos, contratos— que confirmen que lo entregado hace lo que dice. Si todavía revisas el código de tus agentes leyendo el diff en vez de contra un contrato, el ebook gratuito de Revisión por Contrato explica cómo montar ese gate en una tarde.
Cuándo el framework no aplica
Este framework tiene límites reales, y fingir que no los tiene sería venderte una solución perfecta que no existe.
No sabes de antemano si tus subtareas son paralelas. El framework asume que puedes evaluar el paralelismo antes de construir. En dominios nuevos eso no es cierto: el acoplamiento oculto entre pasos solo aparece con el sistema corriendo en producción, no en el diseño en papel.
Los números no son universales. El 15x de tokens y el 90,2% de mejora de Anthropic salieron de research breadth-first, no de tu chatbot de soporte ni de tu pipeline de facturación. Úsalos como orden de magnitud, no como cifra que se traslada directo a tu caso — mide en tu propio proyecto antes de decidir.
La observabilidad cambia el cálculo. Un equipo con buen tracing, replay y evals puede sostener un sistema multiagente incluso cuando el framework diría que no, porque detecta y corrige fallos en minutos. Un developer solo, sin esa infraestructura, paga el precio completo de la complejidad sin la red de seguridad que la justifica.
Qué hacer con esto hoy
Coge tu proyecto actual y pon los cinco criterios en una hoja. Cuenta cuántos "Alto" apuntan a multiagente.
Si son menos de tres, borra el orquestador que ya empezaste a montar y quédate con un solo agente con mejor contexto. Vas a tardar menos en notar la diferencia que en terminar de escribir el segundo rol.
Si son tres o más, constrúyelo — pero mide tokens y tiempo desde el primer día, porque ese es el dato que te dirá si acertaste. Si quieres ver estos patrones aplicados a proyectos reales, en Dominicode Labs los revisamos cada semana con la comunidad.
Preguntas frecuentes
¿Cuándo es mejor usar multiagente en vez de un solo agente?
Cuando las subtareas son genuinamente independientes, no requieren compartir contexto para tomar decisiones coherentes, y el valor del resultado justifica pagar varias veces más tokens. El caso de Anthropic es el más claro: preguntas amplias donde explorar diez fuentes en paralelo vale más que explorarlas una a una.
¿Cuánto más cuesta un sistema multiagente en tokens?
En el caso público de Anthropic, un agente simple usa alrededor de 4 veces los tokens de una conversación normal, y un sistema multiagente completo llega a unas 15 veces. No es una cifra universal, pero sirve como orden de magnitud: si tu tarea no genera un valor claramente superior a ese multiplicador, la orquestación no se paga sola.
¿El multiagente sirve para tareas de programación?
Rara vez, por una razón concreta: escribir código depende de decisiones que se encadenan (nombres, estilo, arquitectura) y que un agente necesita "ver" para no contradecirlas. Cognition/Devin y Uncle Bob con SwarmForge llegaron a la misma conclusión en dominios distintos: un agente único con buen contexto superó a la orquestación.
¿Cómo empiezo si no sé si mi tarea es paralelizable?
Empieza siempre con un solo agente bien instruido. Si notas que el contexto no cabe en una ventana razonable, o que mezclas dos tipos de razonamiento completamente distintos en el mismo prompt, ahí tienes la señal real para dividir — no antes.
¿Qué pasa si ya construí un sistema multiagente y no está funcionando?
Revisa si el problema es de coordinación (agentes que se contradicen) o de coste (tokens que no se justifican con el resultado). En el primer caso, el diagnóstico de Cognition aplica directo: necesitas más contexto compartido, no más agentes. En el segundo, vuelve a los cinco criterios y cuenta cuántos apuntaban realmente a multiagente antes de construirlo.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
¿Te resultó útil este artículo?
Compártelo con tu comunidad y ayuda a otros desarrolladores.