Multi agent systems: sistemas multiagente

¿Qué es un sistema multiagente?

Un sistema multiagente es una arquitectura en la que varios agentes basados en LLM colaboran para resolver una tarea que un solo agente no puede abordar. La propia definición de Anthropic lo resume bien: «A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together.» Lo decisivo es la delimitación: cada agente tiene su propio prompt, su propio rol, su propio conjunto de herramientas y, en sentido estricto, su propia ventana de contexto.

En 2026 esta distinción no es académica. Las presentaciones comerciales de los proveedores han diluido el término. Un único agente con muchas integraciones de herramientas que se vende como «multiagente» porque las propias herramientas se llaman «agentes» es lo que se conoce como multiagente de marketing. El tan citado ejemplo de Klarna («la IA hace el trabajo de 700 empleados») es un sistema de agente único para desviar consultas en atención al cliente y no un sistema multiagente, aunque a menudo se presente erróneamente como tal.

Un multiagente real presenta al menos una propiedad estructural: un agente líder u orquestador que genera dinámicamente subagentes con su propia ventana de contexto; mensajes entre agentes que cruzan fronteras de confianza (por ejemplo, de Agentforce a SAP Joule mediante A2A); o una descomposición propia por procesos, roles o modelos con un intercambio de estado no trivial. Allianz Project Nemo, con sus siete agentes especializados, es un ejemplo de manual.

La lectura honesta en 2026: la mayoría de los «agentes» en producción siguen siendo un único LLM, cuidadosamente construido, con herramientas y un bucle. No es un defecto; la propia Anthropic insiste en que debe ganar el patrón más simple que resuelva el problema. Por eso, la pregunta de arquitectura rara vez es «¿multiagente sí o no?», sino «¿qué patrón encaja y dónde está nuestro acoplamiento de estado?».

El patrón orquestador-trabajadores

El patrón orquestador-trabajadores (agente líder y subagentes) es el caso multiagente canónico. Un agente líder funciona en modo extended thinking o de planificación, descompone la petición del usuario en subtareas discretas y genera subagentes de forma dinámica mediante una herramienta Task. Cada subagente tiene su propio prompt, su propio conjunto de herramientas y, lo que es decisivo, su propia ventana de contexto. Los subagentes devuelven resultados comprimidos que el líder sintetiza.

El caso de referencia es el agente de investigación que hay detrás de la función Research de Claude (lanzada en abril de 2025, con la arquitectura publicada en junio de 2025): un líder con Claude Opus 4 y subagentes con Claude Sonnet 4. En la evaluación interna de investigación de Anthropic, este sistema superó en un 90,2 % al agente único Opus 4. El precio: según Anthropic, los sistemas multiagente consumen unas 15 veces más tokens que una interacción de chat normal, y un agente único, unas 4 veces más (fuente: Anthropic, «How we built our multi-agent research system», 13.06.2025). Anthropic fue explícita: este gasto de tokens solo compensa en tareas de investigación de alto valor, paralelizables y de amplio alcance.

El patrón se utiliza en problemas amplios y paralelizables con subtareas independientes (investigación, inteligencia de mercado, revisión de múltiples documentos, triaje amplio). Conviene evitarlo en tareas de escritura muy acopladas (generación de código que abarca varios archivos) y en flujos de trabajo muy deterministas que exigen reproducibilidad; ahí lo que corresponde es un pipeline.

Una indicación práctica clave de los experimentos de Anthropic: el líder tiene que aprender explícitamente cómo delegar. Cada subagente necesita un objetivo, un formato de salida, pautas sobre fuentes y herramientas y unos límites claros de la tarea. Las delegaciones «vagas» provocaron trabajo duplicado y lagunas de cobertura.

Roles, traspasos y coordinación

Los sistemas multiagente viven de roles claramente definidos y de traspasos limpios. Más allá de la estructura orquestador-trabajadores, existen varios patrones de coordinación que los sistemas en producción suelen combinar:

Los factores de tokens de la tabla son estimaciones aproximadas. Solo está respaldado el valor de orquestador-trabajadores, derivado de la medición de Anthropic (véase más arriba).

La semántica de los traspasos varía según el stack. En el OpenAI Agents SDK, los traspasos explícitos terminan el turno de un agente e inician el del siguiente, al que se pasa el historial de la conversación. AutoGen usa un chat de grupo con turnos de palabra. Sin embargo, Microsoft ha puesto AutoGen en modo de mantenimiento y recomienda para proyectos nuevos su sucesor, Microsoft Agent Framework. LangGraph pasa un objeto de estado tipado a través de los nodos y lo guarda de forma duradera con checkpoints. En el Claude Agent SDK de Anthropic, el líder genera mediante la herramienta Task subagentes que devuelven salidas comprimidas y estructuradas.

En el modelo hub-and-spoke sobre A2A, un agente central delega en agentes pares especializados, potencialmente de distintos proveedores. Para ello, el protocolo A2A define un ciclo de vida de las tareas (submitted → working → input-required → completed | failed | canceled), un descubrimiento de capacidades mediante la AgentCard (un documento JSON con endpoint, capacidades, skills, modalidades y esquemas de autenticación) y mensajes multiparte con artefactos como resultado. La lógica interna del agente remoto sigue siendo opaca. Eso permite que un agente de Salesforce llame a un agente de SAP sin que ninguno revele al otro sus prompts, su memoria o sus modelos.

La regla de coordinación que ha cristalizado en 2026 afecta a la ruta de escritura: muchos agentes leen, recopilan, deducen y proponen, pero solo un agente (o una etapa del pipeline) hace el commit. El fan-out multiagente para lectura es robusto; el fan-out para escritura es frágil; las escrituras simultáneas sobre un estado compartido son la espiral de la muerte.

Fallos y errores acumulativos

Los sistemas multiagente tienen modos de fallo que un sistema de agente único desconoce. Cada uno de los siguientes ha sido documentado en producción por Anthropic, Cognition, Sierra, Salesforce o Microsoft; para cualquier arquitecto, conocer este catálogo no es negociable:

1. Fallos en cascada. Un subagente alucina un hecho; el líder lo incorpora a la síntesis de la respuesta; los agentes posteriores actúan sobre ese hecho falso. Antídoto: agente verificador-juez, recuperación fundamentada, citas obligatorias.
2. Cámara de eco. Los subagentes refuerzan una premisa errónea del líder. Antídoto: diversificar los modelos y prompts de los subagentes (al estilo MoA), incorporar un rol de crítico.
3. Confusión de autoridad. Un subagente sobrescribe las instrucciones del líder, o el líder pierde la autoridad sobre la conversación. Antídoto: jerarquías de roles claras, contratos de tareas A2A con AgentCards sólidas.
4. Interbloqueo de recursos. Los agentes se esperan mutuamente (A espera el resultado de B; B, la aclaración de A). Antídoto: timeouts en cada tarea, estado input-required explícito en A2A.
5. Amplificación de la inyección de prompts. Cada ventana de contexto de un subagente es una nueva superficie de ataque. EchoLeak (CVE-2025-32711, Aim Labs, junio de 2025) fue la primera inyección de prompts zero-click conocida con exfiltración real de datos en un sistema LLM en producción (Microsoft 365 Copilot). Esta misma clase de riesgo escala linealmente con el número de agentes que ingieren contenido no fiable.
6. Fragmentación del contexto (la crítica central de Cognition). Los subagentes toman decisiones implícitas incompatibles entre sí. Antídoto: compartir las trazas completas donde el acoplamiento es alto; escrituras en un solo hilo; contratos de decisión explícitos.
7. Explosión de costes. Según Anthropic, los sistemas multiagente consumen unas 15 veces más tokens que un chat, y un agente único, unas 4 veces más. Frente al agente único, eso supone casi el cuádruple. El gasto solo compensa en tareas de alto valor. Antídoto: límites de tokens por subagente, niveles de QoS, enrutamiento según un umbral de complejidad.
8. Colapso de la depurabilidad. Ninguna traza individual cubre la ejecución completa. Antídoto: trazado distribuido sobre la malla A2A, IDs de correlación propagados en cada tarea A2A y en cada llamada MCP.

El núcleo conceptual de los errores acumulativos procede del análisis de Cognition.ai «Don't Build Multi-Agents» (Walden Yan, 12.06.2025): las acciones llevan consigo decisiones implícitas, y las decisiones contradictorias producen malos resultados. Los «desacuerdos aparentes» entre agentes suelen ser síntomas de fragmentación del contexto, no de una discrepancia real. En la actualización de abril de 2026 («Multi-Agents: What's Actually Working», 22.04.2026), Cognition precisó: el multiagente funciona cuando varios agentes aportan inteligencia, pero las escrituras siguen en un solo hilo.

Síntesis para la decisión de arquitectura

Si pones a Anthropic y a Cognition una al lado de la otra e ignoras la retórica, la síntesis es inequívoca:

• El multiagente funciona en problemas que son paralelizables, presentan un bajo acoplamiento de estado entre los subproblemas y cuya ruta de escritura es de un solo hilo o trivialmente reconciliable. Se benefician la investigación, la búsqueda amplia, el fan-out de documentos, el triaje de siniestros y la detección de fraude con comprobaciones independientes.
• El multiagente fracasa en problemas muy acoplados y secuenciales, en los que cada «decisión implícita» condiciona todos los pasos posteriores. El ejemplo claro sigue siendo la programación: un enjambre de agentes programadores que escriben en paralelo produce un diff que nadie puede fusionar.
• Para la mayoría de los flujos de trabajo empresariales, la respuesta está en un punto intermedio, y la elección del patrón importa más que la pregunta binaria.

Las cuatro frases que puedes oponer a cualquier pitch multiagente: comparte el contexto donde el acoplamiento es alto; aísla el contexto donde domina el paralelismo; nunca dejes que dos agentes escriban a la vez en el mismo estado; paga el sobrecoste de tokens solo si la tarea tiene forma de investigación.

Contexto europeo y notas de cumplimiento normativo

En Europa entran en juego variables estructurales que las arquitecturas de referencia de la nube estadounidense rara vez abordan abiertamente. Las siguientes notas tienen carácter meramente informativo y no constituyen asesoramiento jurídico.

Soberanía de los datos. Cuando distintos agentes se ejecutan en distintos proveedores de computación (por ejemplo, un agente de Salesforce que llama a un agente de SAP Joule, que a su vez usa un paso de razonamiento de Anthropic Claude mediante A2A), el flujo de datos cruza en cada tarea varias fronteras de residencia de datos y de encargados del tratamiento. Con el RGPD, cada proveedor de agentes es potencialmente un encargado del tratamiento (art. 28); el multiagente alarga así la cadena de contratos de encargo del tratamiento. En los pasos transfronterizos entre EE. UU. y la UE se aplican los arts. 44–49 en cada salto entre agentes que cruza una frontera: o bien la decisión de adecuación sobre el Marco de Privacidad de Datos UE-EE. UU. (art. 45) para proveedores estadounidenses certificados en el DPF, o bien cláusulas contractuales tipo junto con una evaluación de impacto de la transferencia (art. 46). La decisión del DPF está en vigor, pero hay un recurso de casación pendiente ante el TJUE (asunto C-703/25 P). Para cargas de trabajo multiagente reguladas, deberías estudiar en serio opciones de nube soberana como STACKIT (Grupo Schwarz), Open Telekom Cloud, IONOS o plusserver. No son obligatorias por ley, pero normas sectoriales como DORA pueden imponer requisitos más estrictos. El handshake A2A con un agente no soberano es la exposición de cumplimiento que más se pasa por alto en el diseño multiagente para empresas europeas.

Pista de auditoría. Cada mensaje entre agentes es potencialmente relevante para una auditoría. Por el no determinismo, la reproducibilidad de las decisiones multiagente es más difícil que en los sistemas de agente único: fija las versiones de los modelos, registra todos los prompts de los subagentes, las llamadas a herramientas, los contextos recuperados y las AgentCards utilizadas, y correlaciónalo todo con un único ID de traza. El diseño de Allianz Nemo, con un agente de auditoría dedicado que genera un resumen completo de todas las decisiones de los agentes, es aquí el patrón de referencia; la auditabilidad forma parte de la topología de agentes, no solo del pipeline de logging.

Reglamento de IA de la UE (visión general, a título informativo, sin carácter de asesoramiento jurídico). En 2026 sigue habiendo cuestiones abiertas sin resolver de forma definitiva: cada agente es plausiblemente un «sistema de IA» propio (art. 3, punto 1), y la composición también es un sistema de IA, con una clasificación de riesgo potencialmente más alta que la de sus partes. En una composición A2A de Salesforce, SAP y Anthropic, normalmente cada fabricante es el proveedor de su propio agente, mientras que la organización integradora es el responsable del despliegue del sistema compuesto. Las obligaciones de transparencia del art. 50 se multiplican a lo largo de las llamadas entre agentes.

Cogestión. Los flujos de trabajo multiagente en RR. HH., atención al cliente o monitorización operativa pueden requerir la participación del comité de empresa según el § 87, apdo. 1, n.º 6 de la BetrVG (Alemania) o los § 96 y § 96a de la ArbVG (Austria), y además a nivel de flujo de trabajo, no por cada agente individual. La tendencia en 2026 son los acuerdos de empresa específicos sobre IA que cubren composiciones multiagente (a título informativo, sin carácter de asesoramiento jurídico).

Coherencia lingüística. Los sistemas multiagente para clientes de la región DACH (Alemania, Austria y Suiza) necesitan un tono de voz unificado y un registro de tratamiento (Sie/Du) coherente en todos los agentes. Un agente de Salesforce que tutea con «Du» y llama a un agente de SAP que usa el «Sie» formal genera una experiencia de cliente que parece «rota». Las guías de estilo deben aplicarse a nivel de AgentCard y de plantilla de prompt.

Perspectivas y recomendación práctica

Para los proyectos en 2026, los valores por defecto racionales están claros: agente único + herramientas como estándar, y paso a multiagente solo cuando la tarea es paralelizable, de lectura intensiva o reconciliable en la escritura, y el factor de coste sale a cuenta. MCP para herramientas, A2A para agentes: en 2026, todo lo demás es una desviación consciente del stack convergente. Trata cada ventana de contexto de subagente como una nueva superficie de ataque. Integra la auditabilidad en la topología (el agente de auditoría de Allianz como modelo). Elige una capa de orquestación más una nativa de la plataforma; tres o más frameworks en producción son una superficie de ingeniería inmanejable. Y publica AgentCards, porque son el contrato entre sistemas que decide si un agente participa en el ecosistema empresarial.

La pregunta en la próxima revisión de arquitectura ya no es «¿Deberíamos construir un sistema multiagente?», sino: «¿Qué patrón de Anthropic encaja con nuestra carga de trabajo, cuánta tolerancia al acoplamiento de estado tenemos, qué entornos de proveedores operamos ya y en qué punto entran MCP y A2A en nuestro perímetro de gobernanza?»