¿Qué es multiagente? Patrones, frameworks y la realidad de coste 15x explicados a fondo (2026)

En 2026, la conversación en torno a los agentes de IA ha pasado de "un superagente que lo hace todo" a "un equipo de agentes con roles distintos". La función Research de Anthropic, los subagentes de Claude Code, el equipo de ingeniería de Devin, los workers paralelos de Cursor: todos ellos se construyen sobre una arquitectura que coordina varias IA.

Este artículo parte de la definición de qué es realmente un sistema multiagente, recorre los principales patrones de arquitectura, una comparativa de frameworks de producción, casos reales, la estructura de costes y, en última instancia, cuándo deberías usarlo y cuándo no, todo basado en las fuentes más recientes. Olvida la fantasía del "pásate a multi y será más inteligente" y sal con una base real para tomar decisiones de diseño.

1. ¿Qué es un sistema multiagente?

Un sistema multiagente (MAS) es una arquitectura en la que varios agentes de IA cooperan para resolver una única tarea. Cada agente tiene su propio prompt, herramientas y contexto, e intercambian mensajes y resultados para alcanzar un objetivo compartido.

El punto de partida, el "agente único" tratado en nuestro artículo sobre agente de IA, es una sola entidad ejecutando por sí sola el bucle "percibir → razonar → actuar → observar". La forma más clara de pensar en un sistema multiagente es: tomar eso y añadirle especialización por rol y paralelismo.

En qué se diferencia de un agente único

2. ¿Por qué orquestar varias IA?

El punto de partida es: "si un solo agente puede hacerlo todo, déjalo en paz". Multiagente se vuelve necesario por tres muros estructurales que un agente único tiene difícil cruzar.

Multiagente cruza esos muros con un kit de tres piezas: "aislamiento de contexto × paralelización × especialización por rol". La función Research de Anthropic es el ejemplo canónico: un investigador líder planifica el trabajo, varios subagentes investigan distintos ángulos en paralelo y los resultados se agregan. Anthropic informa de que esto supuso aproximadamente una mejora de calidad del 90% frente a la versión de agente único.

3. Cinco patrones de arquitectura clave

Los diseños multiagente vienen en un puñado de "formas". Los nombres difieren según el framework, pero en esencia convergen en estos cinco patrones.

3-1. Orquestador-worker (el más común)

Un único "director (orquestador / agente líder)" descompone la tarea y reparte los fragmentos a varios "workers (subagentes)" en paralelo. Cada worker se ejecuta en su propio contexto y devuelve su resultado al orquestador, que los agrega para producir la salida final.

Usado por: Anthropic Research, los subagentes de Claude Code, la configuración canónica en OpenAI Agents SDK.

3-2. Handoff (el linaje OpenAI Swarm)

Los agentes se ceden el control unos a otros explícitamente con un "te toca". El historial de conversación y el contexto van pasando de mano en mano. Estructuralmente parecido a un ticket que se reasigna entre responsables, encaja en escenarios como el flujo de escalado de un servicio de soporte.

Usado por: OpenAI Agents SDK (el sucesor del antiguo Swarm).

3-3. Jerárquico (equipos de equipos)

Una estructura en árbol: bajo el orquestador hay una capa adicional de agentes "mandos intermedios" y, bajo ellos, un grupo de workers. Aparece en sistemas grandes; se informa de que Devin, de Cognition, utiliza este patrón. El coste y la latencia crecen con la profundidad, así que dos o tres capas es el techo realista.

3-4. Peer-to-peer (debate y consenso)

Sin orquestador alguno: varios agentes discuten entre iguales e iteran hasta alcanzar consenso. Estudiado como Multi-Agent Debate, se ha informado de que mejora la veracidad y la robustez del razonamiento. La implementación no es trivial, así que su adopción práctica sigue siendo limitada.

3-5. Pipeline (la forma de workflow)

Cada agente se ejecuta en una secuencia fija tipo "investigar → estructurar → verificar → producir salida". Es el terreno propio de LangGraph con su modelo basado en grafos. Sacrifica la toma de decisiones dinámica, pero a cambio ofrece reproducibilidad y depuración más sencilla; a menudo es la forma más estable en producción.

4. Comparativa de los principales frameworks

Para 2026, el desarrollo multiagente se ha consolidado en torno a cuatro frameworks (la larga cola de frameworks pequeños se ha adelgazado).

En producción, Claude Agent SDK, OpenAI Agents SDK, LangGraph y Strands son los cuatro grandes. CrewAI y AutoGen son buenos para aprender y para PoC, pero los despliegues empresariales en producción se concentran en los cuatro primeros.

5. Qué se está ejecutando realmente en producción

Anthropic Research (dentro de Claude.ai)

La función de research de Claude.ai es un orquestador-worker de manual. El investigador líder divide la pregunta del usuario en piezas, varios subagentes investigan distintos ángulos en paralelo (información de empresa, cronologías, detalle técnico, etc.) y los resultados se agregan en un informe. Anthropic publicó los detalles en su blog de ingeniería e informa de aproximadamente una mejora del 90% en precisión frente a la versión de agente único.

Subagentes de Claude Code

En Claude Code puedes delegar tareas largas a subagentes con roles distintos. Ejemplo: el Claude principal traza el plan, un subagente de investigación lee varios archivos en paralelo y un subagente de implementación escribe el parche. Cada subagente tiene su propia ventana de contexto, así que no satura el contexto principal.

Devin (Cognition)

Se informa de que el ingeniero autónomo Devin, de Cognition, utiliza una estructura multiagente jerárquica. Bajo un agente padre tipo gestor de proyecto, equipos especializados se ejecutan en paralelo por dominio. Esa profundidad es lo que se necesita para llevar PR complejas y trabajos de migración de principio a fin.

Workers paralelos de Cursor

Una actualización reciente de Cursor reforzó su capacidad de repartir cambios que abarcan varios archivos entre subagentes paralelos. En lugar de un único agente procesando archivos en secuencia, agentes separados trabajan en paralelo sobre áreas distintas.

6. Coste y compromisos: la realidad de los 15x tokens

Antes de comprar la idea de "multi significa más listo", hay que entender la estructura de costes. El propio informe de Anthropic indica que un sistema multiagente consume aproximadamente 15x más tokens que una sesión de chat estándar.

Multiagente solo se justifica para "tareas en las que el valor del resultado compensa el coste". Tomando prestada la formulación de Anthropic: el caso de uso previsto son las "tareas complejas de investigación en las que el valor del resultado es alto en relación con el coste".

7. Cuándo usarlo y cuándo no

Casos que piden multiagente

• Investigación paralela: "investigar diez sitios simultáneamente y elaborar un informe", "atacar varias API en paralelo y combinar"; cualquier cosa donde el paralelismo cree valor directo
• Tareas autónomas de larga duración: cargas que exceden la ventana de contexto de una sola sesión. Sin separación de roles, la contaminación de contexto destruye la precisión
• Especialización heterogénea: cuando un mismo agente "escribe código" y "revisa código", su mirada crítica se embota. Separar los roles eleva la calidad de forma directa
• Tareas puntuales con alto valor de negocio: informes de auditoría, análisis estratégicos, investigaciones técnicas complejas; salidas que justifican el coste

Casos en los que no deberías

• Tareas claras y secuenciales: "arregla este código", "resume este documento"; trabajo que un agente único termina con normalidad
• Servicios sensibles a la latencia: primeras respuestas de un chatbot, atención al cliente; cualquier sitio donde la respuesta ágil sea el requisito
• Trabajos por lotes sensibles al coste: trabajo repetitivo de alto volumen. Pasar a multi multiplica el coste unitario por el multiplicador y los números no cuadran
• Equipos sin capacidad para depurar y operar: la complejidad crece exponencialmente con multiagente. Si tu equipo no puede sostenerla, empieza con un agente único

El mantra del sector es "Empieza con un agente; añade más solo cuando tengas una razón clara". Es el consenso entre los ingenieros de producción en 2026.

8. Buenas prácticas de diseño

Una vez decidido que multiagente es la opción correcta, aquí van los puntos que hacen tropezar a los diseñadores, destilados en su mayoría del material publicado por Anthropic.

1. Entrega a los subagentes un "propósito, formato de salida, herramientas y límites" explícitos

La mayoría de los fallos de los subagentes adoptan la forma de "instrucciones vagas que provocaron que se desviara a otra tarea" o "salidas que no compartían formato y no se pudieron agregar". La guía de Anthropic: dale a cada subagente (1) un propósito claro, (2) el formato de salida esperado, (3) las herramientas y fuentes de información que puede usar y (4) los límites de su tarea.

2. Haz explícito el "nivel de esfuerzo"

Los subagentes son malos decidiendo por sí mismos "hasta qué punto profundizar". Hornea el nivel de esfuerzo en el prompt: "investigación de un solo salto", "verificación exhaustiva", "inferir solo a partir de información conocida". El xhigh de Claude Opus 4.7 y los task budgets (beta) son justamente la respuesta oficial a este problema.

3. Da al orquestador el trabajo de "agregar y resolver conflictos"

Los resultados de los subagentes pueden contradecirse entre sí (p. ej., reportar el mismo hecho desde ángulos distintos). La mitad del trabajo del orquestador es "resolver las contradicciones y consolidarlas en una respuesta única y coherente". Si escatimas en la lógica de agregación, las ganancias de pasar a multi se evaporan.

4. Construye observabilidad desde el principio

Los sistemas multiagente colapsan en cuanto no puedes saber qué está pasando. Registra la entrada/salida de cada subagente, el tiempo de ejecución, el consumo de tokens y las llamadas a herramientas desde el día uno. LangGraph y Strands están diseñados pensando en la observabilidad, y esa es una de las razones por las que ganan en producción.

5. Empieza único y divide solo en los cuellos de botella

No diseñes en multi desde el principio. Hazlo funcionar primero como agente único y luego separa un subagente solo en los puntos que hayas identificado claramente como muros. La misma mentalidad que en una refactorización; con eso basta.

Resumen

• Multiagente es una arquitectura en la que "varias IA trabajan en paralelo con roles divididos". Cruza los tres muros del agente único: contaminación de contexto, ausencia de paralelismo y mezcla de roles
• Los patrones centrales son cinco: orquestador-worker, handoff, jerárquico, peer-to-peer y pipeline. Orquestador-worker es de lejos el más común
• Los principales frameworks se han consolidado en cuatro grandes: Claude Agent SDK, OpenAI Agents SDK, LangGraph y Strands
• El coste es de 2x a 15x. La latencia, +30 a 50%. Recurrir a él a la ligera es económicamente erróneo
• Regla de decisión: si el paralelismo, la especialización o el trabajo de larga duración son un requisito firme, ve a multi. En caso contrario, único es suficiente
• Regla de diseño: empieza único y divide solo en los cuellos de botella, una vez que puedas verlos

Preguntas frecuentes

Q1. ¿Multiagente es siempre mejor que un "agente único más listo"?

No. Research de Anthropic vio una mejora de precisión de ~90%, pero eso fue dentro de su punto fuerte: "investigación paralela compleja". Para tareas claras y secuenciales, un agente único es más rápido, más barato y al menos igual de bueno. Depende de la naturaleza de la tarea.

Q2. Si quiero construir yo mismo un sistema multiagente, ¿con qué framework empiezo?

Depende del caso de uso. ¿Usas Claude? Empieza con Claude Agent SDK (oficial, con subagentes + Hooks). ¿Centrado en OpenAI? Agents SDK. ¿Necesitas expresar lógica de ramificación compleja? LangGraph. ¿En producción sobre AWS? Strands. Para aprender, CrewAI va bien para asimilar los conceptos.

Q3. ¿Se puede migrar de único a multi gradualmente?

Sí, y la mayoría de los sistemas en producción hacen exactamente eso. Construye el MVP como agente único y luego separa subagentes solo donde realmente hayas chocado con límites de ventana de contexto, problemas de latencia o necesidades de especialización. Diseñarlo todo como multi desde el principio no es recomendable.

Q4. ¿Existe un protocolo estándar de comunicación entre agentes?

A fecha de 2026, MCP (Model Context Protocol) se está convirtiendo en el estándar de facto. Nació en Anthropic y hoy lo adoptan OpenAI, Microsoft, AWS y otros. Se usa ampliamente como interfaz común tanto entre agentes como entre agentes y herramientas. Existe también una propuesta de estandarización llamada ACP (Agent Communication Protocol), pero las implementaciones aún son pocas.

Q5. ¿Cuál es el modo de fallo más común en multiagente?

(1) Falta de observabilidad (no sabes qué está pasando), (2) las instrucciones a los subagentes son demasiado vagas para agregar los resultados y (3) explosión de coste. (3) en particular: un subagente se queda atrapado en un bucle, machaca la API toda la noche y la factura de cloud salta un orden de magnitud de la noche a la mañana; estos accidentes son sorprendentemente comunes. Fija siempre task budgets (techos de coste y tiempo).

Q6. ¿Es multiagente un camino hacia la AGI (IA general)?

Los investigadores están divididos. Un bando sostiene que "la especialización por rol y la coordinación son la esencia de la inteligencia"; el otro defiende que "escalar un único modelo es la esencia; multiagente es solo un parche de ingeniería". Ambos son creíbles. En la práctica, el encuadre más seguro es tratar multiagente como "una forma de ampliar el rango de tareas de IA hoy alcanzables".

Q7. ¿Hay una opción intermedia entre único y multi?

Sí. "Agente único + subagentes como herramientas". La herramienta Task del Claude Agent SDK es exactamente esto: el principal sigue siendo un agente único, pero puede invocar subagentes desechables a demanda. Sin la complejidad completa de multiagente, empuja más allá de algunos límites del agente único. Es popular como un punto medio razonable.