Multi-Agent Systems: cómo funcionan y cuándo utilizarlos

La primera generación de agentes de Inteligencia Artificial ha estado dominada por una idea relativamente sencilla: asignar un objetivo a un agente, proporcionarle herramientas y permitir que ejecute determinadas acciones con cierto grado de autonomía. Pero cuando los procesos que queremos automatizar se vuelven más complejos aparece una decisión arquitectónica diferente, si un agente puede ejecutar una tarea, ¿qué ganamos introduciendo varios?

Los Multi-Agent Systems (MAS) trasladan al software una lógica de especialización. En lugar de concentrar contexto, herramientas, permisos y responsabilidades en un único agente, diferentes agentes pueden encargarse de partes específicas de un proceso y colaborar para alcanzar un objetivo común.

El interés empresarial está creciendo rápidamente. Gartner registró un aumento del 1.445% en las consultas relacionadas con sistemas multiagente entre el primer trimestre de 2024 y el segundo trimestre de 2025 y prevé que para 2027 el 70% de los Multi-Agent Systems utilizará agentes altamente especializados.

Pero distribuir un proceso entre varios agentes también introduce coordinación, nuevas dependencias, más comunicaciones, costes adicionales y una superficie de ataque mayor. Por eso, la decisión relevante para una empresa no consiste en determinar cuántos agentes puede desplegar, sino cuándo la especialización aporta suficiente valor para justificar esa complejidad.

Qué son los Multi-Agent Systems y cómo funcionan

Un sistema multiagente está compuesto por diferentes agentes de IA que interactúan para alcanzar objetivos individuales o compartidos. Estos componentes pueden disponer de información, herramientas, privilegios y responsabilidades diferentes, y no necesariamente tienen que haber sido desarrollados como una única aplicación.

Imaginemos un sistema encargado de gestionar incidencias IT. Un solo agente podría recibir una solicitud, clasificarla, consultar documentación, revisar sistemas internos, diagnosticar el problema, proponer una solución y decidir qué acción ejecutar.

Una arquitectura multiagente permite separar esas responsabilidades. Un componente puede interpretar y clasificar la incidencia; otro trabajar con la base de conocimiento técnico; un tercero consultar determinados sistemas; mientras otro comprueba que una acción cumple las políticas establecidas antes de autorizarla.

Esta separación permite controlar independientemente qué información recibe cada componente, qué herramientas puede utilizar, a qué datos accede y qué nivel de autonomía tiene.

Por eso, diseñar un MAS empieza a parecerse menos a configurar un chatbot y más a diseñar una pequeña organización digital. Hay que definir responsabilidades, mecanismos de comunicación, permisos, handoffs y reglas para determinar qué ocurre cuando los componentes producen resultados incompatibles.

Esta capa de diseño conecta directamente con el trabajo de un AI Solutions Architect, porque integrar modelos es solamente una parte del problema. También hay que decidir cómo interactúan con datos, aplicaciones, infraestructura y controles empresariales.

La especialización es la verdadera razón para utilizar varios agentes

Gartner prevé que para 2027 el 70% de los Multi-Agent Systems utilizará agentes estrechamente especializados, una evolución que puede aumentar la precisión pero también elevar la complejidad de coordinación.

La especialización tiene sentido porque no todos los componentes de un workflow necesitan utilizar el mismo modelo ni disponer de las mismas capacidades.

Una tarea de clasificación puede resolverse con un modelo relativamente pequeño y económico. Una decisión que requiera razonamiento complejo puede necesitar un modelo más capaz. Un agente puede disponer únicamente de permisos de lectura, mientras otro necesita autorización para ejecutar una acción sobre un sistema empresarial.

Incluso pueden existir componentes procedentes de diferentes proveedores o desarrollados específicamente para un dominio.

Separar responsabilidades permite diseñar el sistema alrededor de tres variables especialmente importantes: capacidad, coste y riesgo.

También facilita que determinados componentes evolucionen independientemente. Si aparece un modelo más eficiente para una función concreta, la organización puede sustituir esa parte sin reconstruir necesariamente todo el sistema.

Esta modularidad explica buena parte del interés por los MAS dentro de las arquitecturas de Artificial Intelligence. Pero modularidad y complejidad suelen avanzar juntas: cuantos más componentes participan, más importante se vuelve controlar sus interacciones.

Tres formas diferentes de organizar la colaboración

Un Multi-Agent System no implica necesariamente un grupo de agentes conversando libremente entre ellos. La forma de coordinación depende del problema y de cuánto control necesite conservar la arquitectura.

Un orquestador distribuye el trabajo

En una arquitectura centralizada existe un componente encargado de interpretar el objetivo general y decidir qué agentes deben participar.

Los especialistas reciben tareas concretas y devuelven sus resultados al orquestador, que conserva una visión más amplia del workflow. Esto facilita la trazabilidad porque existe un punto claramente identificable desde el que observar la ejecución.

El inconveniente es que una parte importante del sistema depende de la capacidad del orquestador para tomar buenas decisiones y transferir correctamente el contexto.

Un agente delega cuando necesita otra capacidad

Otra posibilidad es permitir que un agente descubra durante la ejecución que necesita una competencia que no posee y transfiera parte del trabajo a otro.

Un agente que analiza un contrato, por ejemplo, podría necesitar que otro componente especializado en información financiera compruebe determinados datos antes de continuar.

La arquitectura gana flexibilidad, pero los handoffs adquieren mayor importancia. Hay que establecer qué contexto debe transferirse, quién conserva la responsabilidad de la tarea y cómo se incorpora posteriormente el resultado.

La coordinación puede ser distribuida

Los escenarios más complejos permiten que diferentes agentes compartan información, propongan soluciones o coordinen acciones sin que todas las decisiones pasen necesariamente por un único controlador.

Aquí aparece buena parte del potencial de los MAS, pero también algunos de sus problemas más difíciles. La empresa necesita comprender no solamente qué hizo cada agente, sino cómo las interacciones entre ellos produjeron el resultado final.

Diseñar estas relaciones requiere decisiones de Software Architecture que van mucho más allá de seleccionar un LLM o escribir buenos prompts.

Más agentes también significan más lugares donde algo puede fallar

La modularidad puede reducir la carga que soporta cada agente individual, pero no elimina los errores. Los distribuye.

Un componente puede generar información incorrecta. Otro puede interpretarla como válida y utilizarla para tomar una decisión. Un tercero puede ejecutar una acción basándose en esa decisión. El resultado final puede parecer coherente aunque el error se haya originado varias interacciones antes.

Gartner identifica entre los desafíos de los Multi-Agent Systems una superficie de ataque mayor, necesidades adicionales de integración y monitoring, dificultades para controlar costes y problemas de fiabilidad derivados de errores que pueden acumularse entre agentes.

También pueden aparecer comportamientos menos evidentes: componentes que repiten trabajo, contextos que crecen innecesariamente, llamadas redundantes a modelos o herramientas y loops de comunicación que consumen recursos sin acercar el sistema a su objetivo.

Esto cambia el significado de observabilidad.

No basta con saber si cada servicio está disponible. La organización necesita conocer qué agente inició una acción, qué información recibió, a quién delegó, qué herramientas utilizó, cuánto costaron las diferentes interacciones y dónde apareció una desviación.

En un sistema distribuido de agentes, la trazabilidad del workflow completo se convierte en parte de la arquitectura.

El collaboration gap: un buen agente individual puede formar parte de un mal equipo

Existe otra razón para no asumir que añadir agentes mejora automáticamente un sistema.

Microsoft Research ha estudiado lo que denomina collaboration gap, la diferencia entre la capacidad que muestran determinados modelos individualmente y el rendimiento que alcanzan cuando necesitan colaborar.

Los investigadores evaluaron 32 modelos abiertos y propietarios en configuraciones individuales, homogéneas y heterogéneas. Los resultados mostraron que modelos con buen desempeño individual podían degradarse considerablemente cuando el resultado dependía de la colaboración con otro agente.

El experimento incluso encontró casos en los que modelos pequeños capaces de resolver correctamente los problemas individualmente prácticamente dejaban de hacerlo en determinadas combinaciones. También observó que permitir que el agente más capaz comenzara el proceso antes de transferir el trabajo podía recuperar una parte importante del rendimiento perdido.

Para una empresa, el hallazgo introduce una distinción importante.

Seleccionar el modelo con mejor benchmark para cada función no garantiza que la combinación produzca el mejor sistema.

También importan la calidad de los handoffs, la capacidad de transmitir contexto, la interpretación de las respuestas producidas por otros agentes y los mecanismos disponibles para detectar desacuerdos.

Por tanto, la evaluación de un Multi-Agent System debería comprobar tanto el desempeño individual de sus componentes como su capacidad para colaborar cuando el resultado depende del trabajo realizado por otros.

¿Un agente o un Multi-Agent System?

Antes de introducir una arquitectura distribuida, conviene comprobar si el problema realmente necesita esa separación.

El siguiente marco elaborado por lateam resume algunos criterios que pueden orientar esa decisión:

Marco de decisión elaborado por lateam para evaluar cuándo la especialización multiagente puede justificar la complejidad adicional. No representa un estándar oficial del sector.

La tabla contiene deliberadamente varios “depende”. Una arquitectura no debería elegirse únicamente por el número de pasos de un proceso.

Un workflow puede involucrar diez operaciones y seguir funcionando correctamente con un único agente bien diseñado. Otro puede tener cuatro acciones, pero requerir separación porque una de ellas utiliza información especialmente sensible o necesita permisos que no deberían concederse al resto del sistema.

La frontera adecuada está en las responsabilidades, no en contar tareas.

Un caso empresarial: automatizar incidencias IT sin construir un “superagente”

La gestión de incidencias permite visualizar esta diferencia.

Una empresa podría construir un único agente con acceso a tickets, documentación interna, herramientas de diagnóstico, información de infraestructura y determinadas acciones administrativas. Técnicamente puede ser posible, pero concentraría una cantidad considerable de contexto y permisos en un único componente.

Una arquitectura multiagente podría separar estas responsabilidades.

Un componente de triage interpreta la incidencia y establece su prioridad. Otro consulta documentación técnica y casos anteriores. Un agente con permisos estrictamente controlados obtiene información de infraestructura. Otro propone una resolución y una capa de políticas comprueba determinadas condiciones antes de autorizar acciones sensibles.

Estos nombres describen funciones dentro de la arquitectura, no nuevos perfiles profesionales.

El beneficio aparece cuando esa separación permite aplicar políticas diferentes. El componente que consulta documentación no necesita permiso para modificar infraestructura. El encargado de ejecutar una acción tampoco necesita necesariamente acceso a toda la información del cliente.

Además, los diferentes componentes pueden utilizar modelos, contextos y límites de consumo distintos.

Este tipo de arquitectura también explica por qué el trabajo de un AI Agent Developer puede extenderse más allá de construir agentes individuales. Cuando varios componentes colaboran hay que diseñar contratos de interacción, estados, herramientas, evaluaciones y mecanismos para gestionar fallos parciales.

La governance se complica cuando cada agente tiene una autonomía diferente

Un Multi-Agent System introduce un problema que los modelos de governance uniformes manejan mal: los agentes no representan necesariamente el mismo nivel de riesgo.

Uno puede limitarse a consultar información. Otro puede acceder a una base de datos interna. Un tercero puede generar recomendaciones y otro disponer de herramientas capaces de modificar información empresarial.

Aplicar exactamente las mismas restricciones a todos ignora esas diferencias.

Gartner prevé que para 2027 el 40% de las empresas degradará o retirará agentes autónomos debido a gaps de governance descubiertos después de incidentes en producción. Su recomendación es clasificar los agentes según autonomía y trust boundaries, aplicando controles proporcionales a la capacidad de actuación y al alcance de acceso de cada uno.

Esto cobra todavía más importancia cuando las empresas comienzan a acumular agentes. Gartner estima que una compañía promedio del Fortune 500 podría superar los 150.000 agentes en uso en 2028, frente a menos de 15 en 2025, mientras solamente el 13% de las organizaciones considera actualmente que dispone de la governance adecuada para gestionarlos.

En una arquitectura multiagente, la organización necesita saber quién puede hacer qué y bajo qué condiciones.

La governance debe abarcar identidad, herramientas disponibles, datos accesibles, acciones permitidas, límites de consumo, registros de actividad y situaciones que requieren aprobación humana.

Asegurar un MAS no consiste únicamente en proteger cada componente individual. También implica controlar las relaciones y los límites de confianza que existen entre ellos.

Cuándo un Multi-Agent System añade complejidad sin suficiente valor

El entusiasmo alrededor de agentic AI puede llevar a tratar la arquitectura multiagente como una evolución obligatoria. No lo es.

Gartner ya advertía en 2025 que más del 40% de los proyectos de agentic AI podrían cancelarse antes de terminar 2027 por costes crecientes, falta de valor empresarial o controles de riesgo insuficientes. La firma señalaba además que muchos casos presentados como agentic no necesitan realmente una implementación de este tipo.

El mismo criterio debería aplicarse con mayor rigor a los MAS.

Un Multi-Agent System probablemente no sea la mejor opción cuando:

• Un único agente resuelve la tarea con suficiente precisión y un coste razonable

• El workflow es corto, estable y predecible

• Dividir responsabilidades no introduce una mejora observable

• La organización todavía no puede evaluar correctamente agentes individuales

• No existe suficiente observabilidad para reconstruir interacciones

• El coste y la latencia de coordinación superan el beneficio obtenido.

También existen procesos donde una automatización convencional combinada con IA en puntos específicos puede resultar más robusta que transformar todo el workflow en una arquitectura agentic.

Antes de escalar agentes, hay que construir el sistema que los rodea

Una empresa preparada para experimentar con Multi-Agent Systems necesita capacidades que no dependen exclusivamente de la calidad de los modelos utilizados.

La arquiterctura debe ser modular para que las responsabilidades estén suficientemente delimitadas y un componente pueda evolucionar o sustituirse sin reconstruir todo el workflow.

También se necesita una política clara de identidad y permisos. Cada agente debería operar bajo el principio de mínimo privilegio y acceder únicamente a los datos y herramientas necesarios para realizar su función.

La observabilidad debe permitir reconstruir interacciones, medir latencia y costes, identificar loops y localizar el origen de una determinada decisión. Y la evaluación debe extenderse más allá de los componentes individuales para probar handoffs, fallos parciales, información contradictoria y comportamientos inesperados.

En este contexto, especialistas en Machine Learning pueden trabajar sobre modelos y evaluación, mientras perfiles de IA y arquitectura diseñan el entorno donde esos componentes operan.

A medida que el sistema escala, la diferencia entre construir un buen modelo y construir una buena plataforma para agentes se vuelve cada vez más importante.

La empresa no necesita más agentes; necesita la combinación correcta

Los Multi-Agent Systems ofrecen una forma de dividir procesos complejos entre componentes especializados. Esa separación puede permitir utilizar diferentes modelos, limitar permisos, reducir contextos innecesarios y asignar responsabilidades con mayor precisión que en un agente monolítico.

Pero distribuir inteligencia también distribuye dependencias.

El collaboration gap observado por Microsoft ofrece una advertencia especialmente útil: la calidad de las partes no determina por sí sola la calidad del sistema. Comunicación, coordinación, governance y evaluación se convierten en capacidades de primer nivel.

La tendencia hacia la especialización parece clara. Gartner prevé que el 80% del ROI tangible de agentic AI procederá en 2028 de agentes especializados y orientados a dominios concretos, en lugar de sistemas generalistas.

Eso no significa que la respuesta sea multiplicar agentes indiscriminadamente.

El criterio debería ser cuántas responsabilidades merece realmente la pena separar.

Cuando existen especializaciones claras, permisos diferentes, múltiples fuentes de información y decisiones que se benefician de capacidades distintas, los Multi-Agent Systems pueden proporcionar una arquitectura más flexible y controlable.

Cuando esas condiciones no existen, un único agente bien diseñado puede seguir siendo la mejor decisión.

La sofisticación de una arquitectura de IA no se mide por el número de agentes que contiene, sino por qué tan bien cada componente entiende su función, sus límites y su relación con los demás.