GUÍA DE ARQUITECTURA
Sistemas multiagente: cuándo usar varios agentes de IA y cuándo no
Dividir un sistema en varios agentes puede aumentar capacidad, pero también multiplica coordinación, estado, latencia y nuevas formas de fallo.
La decisión no debería empezar preguntando cuántos agentes construir, sino qué contexto, permisos, herramientas, responsabilidad o trabajo necesita estar realmente separado.
RESPUESTA RÁPIDA
Un sistema multiagente coordina dos o más agentes dentro de un mismo objetivo o proceso. Puede usar un manager, handoffs, ejecución secuencial, trabajo paralelo o especialistas remotos. Más agentes no implican automáticamente más calidad. La separación tiene sentido cuando resuelve una frontera real de contexto, especialización, paralelismo, permisos, herramientas, ownership o infraestructura.
La regla práctica de este artículo es sencilla: otro agente necesita una razón arquitectónica.
Qué es un sistema multiagente
Un sistema multiagente combina varias unidades agénticas que participan en una misma tarea, producto o proceso.
Cada agente puede tener su propio conjunto de instrucciones, contexto, herramientas, permisos, memoria, modelo y objetivo local. Lo importante es que esas unidades no trabajan aisladas: alguna forma de coordinación conecta sus resultados con un objetivo común.
Esa coordinación puede adoptar formas muy diferentes. Un agente principal puede delegar subtareas a especialistas y mantener el control. Un agente de triage puede transferir la conversación mediante un handoff. Un workflow puede ejecutar tres agentes en una secuencia fija. Varios subagentes pueden investigar en paralelo y devolver resultados a un coordinador. Incluso puede haber agentes remotos que viven en servicios independientes.
Por tanto, multiagente no significa necesariamente un grupo de modelos conversando libremente entre sí.
También puede existir una arquitectura muy controlada:
agente A → agente B → agente C
con el orden definido por código.
La característica esencial no es la metáfora de «equipo». Es que existen varias unidades con responsabilidades o contextos separados que deben coordinarse para producir un resultado común.
Empieza por un solo agente
Antes de dividir un sistema conviene intentar resolver el problema con la arquitectura más sencilla que pueda cumplir los requisitos.
OpenAI recomienda maximizar primero las capacidades de un solo agente. Anthropic señala que un único agente puede resolver la mayoría de los flujos de trabajo empresariales y que multiagente aporta valor principalmente cuando aparecen razones claras como aislamiento de contexto, paralelismo o especialización. Microsoft advierte además que cada handoff introduce latencia y obliga a gestionar estado explícitamente.
Un solo agente suele tener ventajas inmediatas:
- menos llamadas al modelo;
- menos transferencias de contexto;
- menos puntos de fallo;
- menos estado distribuido;
- trazas más fáciles de leer;
- evaluación más simple;
- menor coste de coordinación.
Esto no significa que un agente único sea siempre mejor.
Significa que la complejidad multiagente debe ganarse.
Si el mismo agente puede comprender el objetivo, utilizar las herramientas necesarias y completar el trabajo con controles adecuados, dividirlo únicamente porque «el proceso es complejo» no demuestra que vayamos a obtener una arquitectura mejor.
La complejidad del problema y la cantidad de agentes no tienen una relación uno a uno.
La pregunta correcta: qué frontera necesita separarse
La mejor razón para crear otro agente no es que podamos hacerlo, sino que podamos señalar una frontera que merece existir.
Contexto
Un especialista necesita trabajar con mucha información que no debería ocupar el contexto del coordinador.
Especialización
Dos partes del proceso necesitan instrucciones, criterios o fuentes suficientemente diferentes.
Paralelismo
Varias subtareas pueden resolverse de manera independiente y simultánea.
Permisos
No todos los componentes deberían tener la misma autoridad. Un agente puede leer mientras otro dispone de herramientas de escritura más controladas.
Superficie de herramientas
Separar dominios puede reducir el catálogo disponible en cada contexto y evitar herramientas solapadas o innecesarias.
Ownership
Distintos equipos pueden ser responsables de agentes diferentes, con fuentes, reglas y ciclos de cambio propios.
Infraestructura
Los agentes pueden vivir en servicios, frameworks u organizaciones diferentes y necesitar un contrato explícito de interoperabilidad.
Estas fronteras pueden combinarse. Pero si no existe ninguna, probablemente estemos añadiendo coordinación sin obtener una separación útil.
Otro agente necesita una frontera real
La separación debe resolver un problema concreto: contexto, especialización, paralelismo, permisos, herramientas, ownership o infraestructura.
Equivalente textual del diagrama
- CONTEXTO: Aislar grandes volúmenes de información
- ESPECIALIZACIÓN: Instrucciones y criterios distintos
- PARALELISMO: Subtareas realmente independientes
- PERMISOS: Separar autoridad y credenciales
- TOOLS: Reducir la superficie disponible
- OWNERSHIP: Responsables o equipos diferentes
- INFRAESTRUCTURA: Servicios o runtimes independientes
Aislamiento de contexto: varios agentes para no mezclarlo todo
El aislamiento de contexto es uno de los argumentos más sólidos para una arquitectura multiagente.
Un agente principal puede conservar el objetivo global, las restricciones principales y el estado del proceso, mientras un especialista recibe un contexto limpio con solo lo que necesita.
Anthropic utiliza esta idea en su sistema multiagente de investigación. Los subagentes pueden consumir búsquedas, documentos y resultados intermedios dentro de ventanas de contexto separadas y devolver posteriormente una síntesis al agente líder.
Esto evita que el coordinador arrastre cada página consultada, cada respuesta de herramienta y cada detalle de exploración.
El beneficio no es que el subagente sea «otra personalidad». Es que puede disponer de un presupuesto de contexto separado.
Esta frontera resulta especialmente útil cuando una subtarea genera mucho material intermedio pero el sistema principal solo necesita conclusiones, referencias o un artefacto final.
Patrón manager: un agente coordina y otros trabajan
Uno de los patrones más comunes es el manager u orchestrator-worker.
La estructura conceptual es:
usuario → manager → especialistas → manager → respuesta
El manager conserva la visión global y decide qué trabajo delegar. Los especialistas pueden recuperar información, analizar documentos, consultar fuentes concretas, preparar cálculos, revisar resultados o ejecutar funciones limitadas.
Después devuelven un resultado al manager, que continúa coordinando la tarea.
OpenAI implementa un patrón equivalente mediante agents as tools: el coordinador puede invocar a otro agente como una herramienta. El especialista realiza su trabajo y devuelve la salida, pero no se convierte automáticamente en el agente principal de la conversación.
Este patrón es útil cuando queremos una única interfaz ante el usuario, centralizar el plan, combinar resultados de varios especialistas o mantener aislados sus contextos.
El riesgo es convertir al manager en un cuello de botella. Si todo debe pasar por él, puede acumular demasiado contexto, trabajo de síntesis y decisiones de enrutamiento.
Handoff: cuando el especialista toma el control
Un handoff resuelve un problema distinto.
En lugar de delegar una subtarea y recibir después el resultado, el agente actual transfiere el control a otro.
Podemos representarlo así:
usuario → triage → handoff → especialista → usuario
Por ejemplo, un agente de entrada puede identificar que una consulta pertenece a facturación y transferirla a un agente cuyas instrucciones, herramientas y permisos están diseñados para ese dominio.
OpenAI diferencia explícitamente handoffs de agents-as-tools.
La distinción es importante: en un manager, el coordinador conserva el control; en un handoff, el receptor pasa a ser el agente activo.
Manager y handoff resuelven cosas distintas
En un manager, el coordinador delega y recupera el resultado. En un handoff, el agente receptor pasa a controlar el turno o la tarea.
Equivalente textual del diagrama
Manager: usuario → manager → especialista → manager → usuario.
Handoff: usuario → triage → especialista → usuario.
Secuencial, paralelo y evaluador
No todos los sistemas multiagente necesitan un manager dinámico.
Secuencial
A → B → C
Cada etapa necesita el resultado de la anterior. Puede ser adecuado para un proceso como analizar → redactar → revisar. El flujo puede estar completamente definido por código.
Paralelo
coordinador → [A, B, C] → síntesis
Los agentes trabajan simultáneamente en subtareas independientes. Puede ser útil para investigar diferentes fuentes, procesar documentos independientes, dividir un lote o explorar varias líneas en paralelo.
Evaluador
productor → revisor → aprobar / repetir
Un agente produce una salida y otro aplica un criterio de revisión. Puede utilizarse para controles de calidad o crítica especializada, pero necesita una condición clara de salida para evitar bucles.
Estos patrones pueden combinarse. Lo importante es que la topología del sistema responda a dependencias reales del trabajo.
Tres patrones de coordinación
La topología debe seguir las dependencias reales del trabajo: etapas dependientes, subtareas independientes o un loop explícito de producción y evaluación.
Equivalente textual del diagrama
Secuencial: A → B → C.
Paralelo: coordinador → A/B/C → síntesis.
Evaluador: productor → revisor → aprobar o repetir.
Multiagente no significa orquestación autónoma
Es perfectamente posible utilizar varios agentes dentro de un workflow determinista.
OpenAI distingue entre orquestación mediante LLM y orquestación mediante código.
En el primer caso, un modelo puede decidir qué especialista necesita, cuándo invocarlo y cómo continuar.
En el segundo, la aplicación define explícitamente enrutamiento, orden, paralelismo, reintentos, criterios de salida y bucles de evaluación.
Microsoft Agent Framework sigue una idea similar al ofrecer patrones de workflow secuencial, concurrente, handoff o group chat.
Esto conecta directamente con una idea que ya hemos utilizado al comparar agentes y automatización: no toda decisión tiene por qué delegarse al modelo.
Un sistema puede tener varios agentes especializados y, aun así, mantener la coordinación global bajo reglas deterministas.
Multiagente describe separación y coordinación; no un nivel obligatorio de autonomía.
El handoff es una interfaz
Cada frontera entre agentes necesita un contrato.
Un buen handoff debería definir, según el caso:
- objetivo;
- contexto necesario;
- datos permitidos;
- restricciones;
- identificadores;
- artefactos;
- formato de salida esperado;
- estado de la tarea;
- permisos;
- errores posibles;
- y quién conserva la fuente de verdad.
El error habitual es pensar: «Le paso toda la conversación y ya entenderá qué hacer».
Eso puede funcionar en un prototipo, pero reduce las ventajas de aislamiento. Pasar todo puede inflar contexto, revelar datos innecesarios, trasladar instrucciones que no corresponden al especialista y mezclar responsabilidades.
OpenAI permite filtrar el historial transferido en un handoff. Anthropic insiste en que los subagentes funcionen mejor con tareas y fronteras claras.
Pensar el handoff como interfaz obliga a responder una pregunta útil:
¿Cuál es el mínimo contexto suficiente para que el siguiente agente haga bien su trabajo?
Artefactos y referencias pueden ser mejores que conversaciones enteras
No toda información debe viajar como texto dentro de los mensajes entre agentes.
Supongamos que un subagente ha analizado cien documentos y ha producido un informe extenso. Puede devolver todo el contenido al coordinador, que quizá tenga que resumirlo de nuevo antes de enviarlo a otro componente.
O puede:
- guardar un artefacto;
- devolver su identificador o ubicación;
- entregar una síntesis estructurada;
- permitir que otro agente consulte el artefacto si realmente lo necesita.
Anthropic describe este tipo de estrategia para reducir un «juego del teléfono» entre subagentes, donde cada resumen intermedio puede eliminar detalle o deformar información.
Entre agentes, a veces conviene transferir referencias y estado, no conversaciones enteras.
Esta decisión conecta con la gestión de memoria en agentes de IA: contexto, estado, memoria y artefactos cumplen funciones diferentes.
Qué puede salir mal al coordinar varios agentes
Cada nuevo componente añade nuevos modos de fallo.
Trabajo duplicado
Dos especialistas resuelven la misma subtarea porque la delegación era ambigua.
Gaps
Cada agente asume que otra parte del sistema resolverá un requisito y nadie lo hace.
Misrouting
La tarea llega al especialista equivocado.
Pérdida o fuga de contexto
El handoff omite una condición crítica o transfiere información que no debería cruzar esa frontera.
Delegación infinita
A delega a B, B devuelve a A y el sistema entra en un bucle.
Over-spawning
El coordinador crea más subagentes de los necesarios. Anthropic documentó este problema durante el desarrollo de su sistema de Research.
Estado inconsistente
Dos agentes trabajan sobre versiones diferentes de un mismo dato.
Side effects conflictivos
Dos componentes intentan modificar simultáneamente el mismo recurso.
Fallo de síntesis
Todos los especialistas producen resultados válidos, pero el coordinador los combina mal.
Ese último caso es especialmente importante: cada agente puede pasar su evaluación individual y el sistema completo seguir fallando.
Coste, latencia y observabilidad
Un sistema multiagente no cuesta más únicamente porque haya más llamadas al modelo.
También hay que coordinar contexto, estado, handoffs, reintentos, timeouts, trazas, resultados parciales, síntesis y errores distribuidos.
Microsoft señala que los handoffs introducen latencia y gestión de estado. Anthropic ha mostrado además que su sistema multiagente de Research consume muchos más tokens que una interacción de chat convencional; en esa carga de trabajo concreta documentó aproximadamente quince veces más tokens. Esa cifra pertenece a su arquitectura y no es un benchmark universal, pero ilustra el coste potencial de multiplicar contextos y trabajo.
También cambia la observabilidad.
En multiagente necesitamos saber quién delegó, qué recibió cada agente, qué devolvió, cuánto tardó, qué herramientas utilizó, qué estado modificó, por qué se produjo un reintento y cómo se llegó al resultado final.
Si no podemos reconstruir la coordinación, depurar el sistema se vuelve muy difícil.
Multiagente y seguridad
Separar agentes puede ayudar a limitar autoridad, pero solo si la separación existe técnicamente.
Por ejemplo, un agente de análisis puede tener acceso de lectura; un agente ejecutor puede disponer de una herramienta concreta de escritura; un revisor puede no tener credenciales para producir efectos externos; y un agente de otro dominio puede no recibir determinados datos.
Esto aplica principios de mínimo privilegio y reduce la superficie de herramientas de cada componente.
Pero crear tres prompts diferentes no produce aislamiento por sí solo.
Si todos comparten las mismas credenciales, el mismo contexto completo, todas las herramientas y permisos globales, la separación visual entre «agentes» no ha creado una frontera de seguridad real.
La autoridad sigue dependiendo de la arquitectura de tool calling, credenciales, validaciones, ámbitos y, cuando corresponda, supervisión humana.
A2A: cuándo los agentes están realmente separados
Cuando varios agentes viven dentro de la misma aplicación, no necesitamos necesariamente un protocolo de comunicación distribuida. Podemos invocarlos como funciones, herramientas o nodos de un workflow.
A2A —Agent2Agent— cobra relevancia cuando la frontera también es de infraestructura:
- agentes en servicios distintos;
- frameworks diferentes;
- equipos independientes;
- proveedores distintos;
- organizaciones distintas;
- ciclos de despliegue separados.
Google impulsó A2A como protocolo abierto de comunicación entre agentes y el proyecto pasó a Linux Foundation. Microsoft lo utiliza como referencia para interoperabilidad agente-a-agente entre runtimes o plataformas.
La diferencia con MCP es útil: MCP conecta principalmente hosts o agentes con herramientas, recursos y capacidades; A2A facilita la interacción entre agentes como servicios independientes.
Pero cada llamada A2A también es una llamada de red. Eso introduce latencia, timeouts, reintentos, autenticación, versionado, disponibilidad remota y estado distribuido.
No conviertas agentes locales en servicios distribuidos solo porque existe un protocolo para hacerlo.
Cómo evaluar un sistema multiagente
La evaluación tiene que ocurrir en varios niveles.
- Especialista: ¿cada agente realiza correctamente su responsabilidad local?
- Routing: ¿la tarea se envía al agente adecuado?
- Handoff: ¿recibe el contexto mínimo necesario y no recibe información indebida?
- Coordinación: ¿hay duplicados, huecos, bucles o reintentos innecesarios?
- Outcome: ¿el sistema completo deja el entorno en el estado correcto?
- Operación: ¿cuántas llamadas, tokens, herramientas, handoffs y revisiones fueron necesarias?
Esto conecta con nuestra guía sobre cómo evaluar un agente de IA, pero en multiagente aparece un nivel adicional: la coordinación también debe evaluarse.
Podemos tener:
agente A = PASS · agente B = PASS · agente C = PASS · sistema completo = FAIL
porque el enrutador eligió mal, el handoff perdió una condición o la síntesis combinó resultados incompatibles.
También conviene probar fallos deliberados: especialista no disponible, respuesta vacía, timeout, dato contradictorio, efecto parcial o resultado que llega tarde.
Framework: ¿realmente necesitas otro agente?
Antes de dividir una arquitectura, utiliza estas preguntas para obligar a que cada nueva frontera tenga una razón concreta.
Si después de responderlas no aparece una razón clara para separar, probablemente el siguiente paso no sea otro agente.
Puede ser simplemente mejorar las herramientas, el contexto, el flujo de trabajo, los permisos, la memoria o la evaluación del agente existente.
Preguntas frecuentes
¿Qué es un sistema multiagente?
Es una arquitectura en la que dos o más agentes participan coordinadamente en un mismo objetivo o proceso. Pueden estar dirigidos por un manager, conectados mediante handoffs, encadenados por un workflow o ejecutarse en paralelo.
¿Dos agentes son siempre mejores que uno?
No. Añadir agentes aumenta coordinación, estado, coste y puntos de fallo. Solo aporta valor cuando la separación resuelve una necesidad concreta como aislamiento de contexto, especialización, paralelismo, permisos u ownership.
¿Qué diferencia hay entre manager y handoff?
En un patrón manager, el coordinador conserva el control y utiliza especialistas para subtareas. En un handoff, el control pasa al agente receptor, que se convierte en el agente activo del flujo o conversación.
¿Un workflow con varios agentes es un sistema multiagente?
Sí, puede serlo. La coordinación no necesita estar decidida por un LLM. Un workflow determinista puede ejecutar varios agentes especializados en una secuencia o grafo definido por código.
¿Puede un agente llamar a otro como herramienta?
Sí. Frameworks como OpenAI Agents SDK permiten exponer un agente especialista como una tool para un manager. El especialista devuelve su resultado y el manager mantiene el control global.
¿Qué contexto deberían compartir los agentes?
Solo el necesario para la subtarea y la coordinación. Pasar toda la conversación por defecto puede eliminar las ventajas del aislamiento y aumentar ruido, coste o exposición de datos.
¿Qué diferencia hay entre MCP y A2A?
MCP se utiliza principalmente para conectar hosts o agentes con herramientas, recursos y capacidades. A2A está orientado a interoperabilidad entre agentes independientes. Pueden coexistir, pero resuelven capas distintas.
¿Cómo sé si necesito varios agentes?
Intenta señalar la frontera exacta que quieres crear. Si no puedes explicar qué contexto, permisos, herramientas, responsabilidad, trabajo paralelo o infraestructura necesita estar separado, probablemente un agente único o un workflow más simple siga siendo una mejor base.
Fuentes y lecturas recomendadas
Estas fuentes sostienen los criterios de separación entre agentes, los patrones manager/handoff, el aislamiento de contexto, los costes de coordinación y la diferencia entre composición interna y agentes remotos.
- 01Anthropic — Creando sistemas multiagente: cuándo y cómo usarlos (enlace externo)claude.com
Explica cuándo el aislamiento de contexto, la especialización y el paralelismo pueden justificar varios agentes.
- 02Anthropic — How we built our multi-agent research system (enlace externo)anthropic.com
Describe un sistema real de orquestador y subagentes, sus beneficios, costes y problemas de coordinación.
- 03Anthropic — Building Effective Agents (enlace externo)anthropic.com
Presenta patrones como parallelization, orchestrator-workers y evaluator-optimizer.
- 04OpenAI — A practical guide to building agents (enlace externo)openai.com
Recomienda maximizar primero un agente único y distingue manager de handoffs.
- 05OpenAI Agents SDK — Agent orchestration (enlace externo)openai.github.io
Distingue orquestación mediante LLM y mediante código, además de agents-as-tools y handoffs.
- 06OpenAI Agents SDK — Handoffs (enlace externo)openai.github.io
Documenta transferencia de control y filtrado de contexto entre agentes.
- 07Microsoft — Single agent vs multi-agent (enlace externo)learn.microsoft.com
Explica trade-offs de latencia, estado, seguridad, especialización y ownership.
- 08Microsoft Agent Framework — Workflow orchestrations (enlace externo)learn.microsoft.com
Documenta patrones secuenciales, concurrentes, handoff y group chat.
- 09Microsoft — Multi-agent patterns (enlace externo)learn.microsoft.com
Trata least privilege, simplicidad, auditabilidad y la relación entre MCP y A2A.
- 10Microsoft Agent Framework — Agent-to-Agent (enlace externo)learn.microsoft.com
Explica implicaciones operativas de conectar agentes remotos mediante A2A.
- 11Google Cloud — Multi-agent systems (enlace externo)cloud.google.com
Introducción a coordinación centralizada, distribuida e híbrida.
- 12Linux Foundation — Agent2Agent Protocol Project (enlace externo)linuxfoundation.org
Contexto sobre A2A como protocolo abierto de interoperabilidad entre agentes.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Tu proceso necesita varios agentes o solo una arquitectura más clara?
Antes de dividir un sistema, conviene identificar qué contexto, permisos, herramientas o responsabilidades justifican realmente crear una nueva frontera.
En Agentes Como Servicio diseñamos estas arquitecturas empezando por el proceso y sus límites: añadimos separación solo cuando mejora control, capacidad, aislamiento u operación de una forma que pueda justificarse y evaluarse.
Solicitar acceso