Cuando los agentes hablan entre sí

Durante dos años, el reto fue conectar la IA con las herramientas. Ya está casi resuelto. El reto nuevo es otro: que los agentes se comuniquen entre sí, se deleguen tareas y cooperen sin un humano coordinando cada paso. Y esa frontera, que parece puramente técnica, arrastra una pregunta que la ingeniería no puede esquivar: cuando algo falla en una conversación entre máquinas, ¿quién responde?

El punto de partida: del agente solo al sistema de agentes

Un agente de IA aislado es, a estas alturas, un problema resuelto. Sabe usar herramientas, consultar bases de datos, ejecutar tareas acotadas. La pieza que faltaba no era hacer más capaz al agente individual, sino hacer que varios agentes trabajen juntos.

Las cifras del sector señalan que esa transición ya está en marcha. Gartner estima que el 40% de las aplicaciones empresariales incorporarán agentes específicos en 2026, frente a menos del 5% en 2025. No es una tendencia lejana: es el año en curso.

Y aquí surge el problema que un ingeniero de datos reconoce de inmediato, porque lo ha visto antes en otros contextos. Cuando se pasa de un componente a muchos componentes que deben coordinarse, la dificultad no crece de forma lineal. Crece con el número de interacciones posibles. Cada agente nuevo no añade un nodo: añade todas las conversaciones que ese nodo puede mantener con los demás.

Sin un protocolo común, cada una de esas conversaciones exige integración a medida. Y la integración a medida, multiplicada por una población creciente de agentes, se vuelve inmanejable. Es exactamente el problema que en su momento resolvieron los estándares de red, los formatos de intercambio de datos o los buses de mensajería. La historia rima.

Dos protocolos para dos problemas distintos

La confusión más común al acercarse a este terreno es tratar MCP y A2A como competidores. No lo son. Resuelven capas distintas del mismo sistema, y entender esa diferencia es el primer paso para diseñar bien.

MCP: el agente y el mundo

El Model Context Protocol estandariza cómo un agente accede a herramientas, APIs y fuentes de datos. Es la capa vertical: conecta al agente con el mundo exterior.

Su adopción se ha consolidado de una forma poco habitual por lo rápida. La promesa de “escríbelo una vez, úsalo en todas partes” se está cumpliendo: un servidor MCP para una base de datos concreta funciona con cualquier cliente de IA compatible. Eso ha convertido a MCP en un estándar de facto para la conectividad agente-herramienta.

Pero MCP tiene un límite de diseño explícito, y conviene tenerlo claro: no fue pensado para que los agentes hablen entre sí. Su modelo asume un patrón cliente-servidor, una conexión hacia una capacidad. La negociación entre agentes, la delegación de tareas, la coordinación de un trabajo compartido — nada de eso entra en su alcance.

MCP conecta al agente con sus herramientas. No con sus pares.

A2A: el agente y sus pares

Ese hueco —la comunicación horizontal entre agentes— es el que vino a llenar A2A (Agent-to-Agent), presentado por Google en abril de 2025 y donado a la Linux Foundation poco después.

A2A estandariza algo distinto: cómo los agentes se descubren entre sí, negocian capacidades y se delegan tareas, con independencia del framework sobre el que estén construidos. Si MCP es el cable hacia la herramienta, A2A es el lenguaje común entre agentes que necesitan repartirse un trabajo.

El mecanismo central es la Agent Card: una descripción estructurada que cada agente publica sobre lo que sabe hacer. Otros agentes la leen, descubren qué pueden delegarle y le pasan tareas. Sin código de pegamento escrito a mano para cada par de agentes que deba colaborar.

El movimiento de consolidación del sector ha sido notable. El Agent Communication Protocol de IBM se integró en A2A a lo largo de 2025, y en diciembre de ese año la Linux Foundation lanzó la Agentic AI Foundation —con OpenAI, Anthropic, Google, Microsoft, AWS y Block entre los fundadores— como hogar permanente tanto de A2A como de MCP. Dos protocolos, dos capas, un mismo techo institucional.

El stack de dos capas, visto desde la ingeniería

Puestos en orden, los dos protocolos dibujan una arquitectura clara:

La recomendación práctica que emerge del consenso del sector es sobria: adoptar MCP para la conectividad con herramientas, adoptar A2A cuando aparezcan flujos multi-agente, y —esto es lo importante— abstraer la capa de protocolo detrás de interfaces limpias, porque ambos estándares todavía están evolucionando y conviene poder actualizarlos sin reescribir la lógica de los agentes.

Hasta aquí, el terreno cómodo: arquitectura, capas, estándares. Ahora viene la parte que el entusiasmo del sector menciona menos.

Lo que esto cambia en la ingeniería de datos

La comunicación inter-agente no es solo una capacidad nueva. Reordena cómo se diseña, se observa y se gobierna un sistema. Cuatro consecuencias concretas.

1. El sistema deja de ser inspeccionable de un vistazo

Un pipeline tradicional se puede seguir. Entrada, transformación, salida. Hay un hilo que recorrer.

Un sistema de agentes que se delegan tareas entre sí no ofrece ese hilo. La ejecución se ramifica: un agente descubre a otro, le pasa una tarea, ese subcontrata a un tercero. El camino real que siguió una petición solo existe, reconstruible, si se ha registrado deliberadamente cada salto.

Por eso la observabilidad deja de ser una buena práctica y pasa a ser un requisito de arquitectura. Cada llamada MCP, cada transición de estado de una tarea A2A, cada delegación: todo tiene que quedar trazado. Un sistema multi-agente sin logging exhaustivo no es un sistema ágil. Es una caja negra que además se mueve.

2. La superficie de fallo se multiplica

Cuando los agentes se coordinan, aparecen modos de fallo que no existían con un agente solo. Un agente publica una Agent Card que describe mal lo que hace. Otro delega una tarea sobre esa descripción equivocada. Un tercero recibe un resultado a medias y construye encima.

El fallo, además, se propaga. Y se propaga de una forma particularmente difícil de diagnosticar: el síntoma aparece en un agente que no cometió el error, sino que heredó las consecuencias de otro varios saltos atrás. Quien haya depurado sistemas distribuidos reconoce el patrón. La diferencia es que aquí los nodos no son deterministas: cada agente es un modelo que puede interpretar la misma tarea de forma distinta según el contexto.

3. La capa externa cambia de función

Aquí hay un desplazamiento que conviene anticipar. A medida que los protocolos absorben la coordinación —descubrimiento, delegación, gestión del ciclo de vida de una tarea—, las arquitecturas de orquestación montadas a mano pierden parte de su razón de ser.

Pero no desaparecen. Cambian de trabajo. La capa externa deja de ocuparse de cómo se hablan los agentes —eso lo hace el protocolo— y pasa a ocuparse de lo que el protocolo no cubre: la integración con los sistemas reales de la organización. Las bases de datos, las colas, las APIs de negocio, las reglas de acceso, los límites de lo que cada agente puede tocar.

La coordinación baja al protocolo. El gobierno sube a la infraestructura.

4. La seguridad se vuelve un problema de identidad entre máquinas

Si un agente puede descubrir a otro y delegarle una tarea, la pregunta de seguridad es inmediata: ¿qué agente tiene permiso para pedirle qué a cuál? La autenticación y la autorización entre agentes —todavía en evolución en ambos protocolos— dejan de ser un detalle de implementación. Son el perímetro.

Un sistema donde los agentes se delegan tareas sin un control claro de identidad y permisos no es un sistema autónomo. Es un sistema sin puertas.

Lo que los protocolos no resuelven

Conviene ser preciso: MCP y A2A resuelven la interoperabilidad. Hacen que agentes de distintos fabricantes puedan entenderse. Eso es valioso y real.

Pero la interoperabilidad no es lo mismo que el control. Que dos agentes puedan hablarse no dice nada sobre si deberían, sobre quién supervisa esa conversación, ni sobre qué pasa cuando produce un resultado equivocado. Los protocolos estandarizan el canal. No estandarizan la responsabilidad.

Y esa distinción es la que abre la segunda mitad de este artículo.

El otro lado: la responsabilidad que se diluye

Hasta aquí, la ingeniería. Pero un sistema donde las máquinas se delegan tareas entre sí toca algo que va más allá de la arquitectura: toca la cuestión de quién responde.

Cuando un único agente fallaba, la cadena de responsabilidad era localizable. Había un modelo, una entrada, una salida, un punto donde algo se torció. Con varios agentes cooperando, esa cadena se vuelve difusa. Y la palabra difusa no es retórica: es la descripción precisa de lo que ocurre.

Sobre el fallo sin autor

Imaginemos un sistema multi-agente que produce una decisión errónea. Un agente interpretó mal una tarea. Otro la delegó confiando en una Agent Card imprecisa. Un tercero integró un resultado parcial sin detectar que lo era. Ningún agente “falló” en sentido estricto. Cada uno hizo lo que su diseño contemplaba. Y aun así, el sistema produjo un error con consecuencias.

¿De quién es ese error? La pregunta no tiene una respuesta cómoda. No hay un componente culpable. Hay una propiedad emergente del sistema: un fallo que nace de la interacción, no de ninguna de las partes. Y los sistemas jurídicos, las organizaciones y las costumbres profesionales están construidos para atribuir responsabilidad a actores concretos, no a interacciones.

Sobre la delegación que nadie ve

Hay un segundo efecto, más sutil. Cuando un agente delega en otro a través de A2A, esa delegación es invisible para el usuario final. La persona que inició la petición ve una entrada y una salida. No ve que, en medio, la tarea pasó por cuatro agentes de tres fabricantes distintos, cada uno con sus sesgos, sus límites y sus criterios.

El resultado llega limpio, unificado, sin costuras. Y esa ausencia de costuras es precisamente el problema: oculta la cadena de decisiones que lo produjo. El usuario no puede preguntar “¿quién decidió esto?” porque la interfaz le presenta el resultado como si tuviera un solo autor. No lo tiene. Tiene una asamblea de agentes que nadie le presentó.

Sobre el ritmo de la autonomía

Y hay una tercera cuestión, la más estructural. Estos protocolos están diseñados, en sus propias palabras, para permitir que los agentes colaboren “sin intervención humana”. Ese es el objetivo declarado, y desde la eficiencia tiene toda la lógica: la intervención humana es lenta, cara, un cuello de botella.

Pero la intervención humana también era el punto donde la responsabilidad se anclaba. Cada vez que un humano revisaba, aprobaba o supervisaba, había alguien que respondía. Retirar al humano del bucle no solo retira un cuello de botella: retira el ancla. Y un sistema de agentes que se coordinan a toda velocidad, sin puntos de supervisión, es un sistema donde el error también se propaga a toda velocidad, sin que nadie llegue a tiempo de detenerlo.

La pregunta para quien diseña no es si los agentes deben poder coordinarse solos. Es dónde colocar deliberadamente los puntos donde un humano todavía mira — no por desconfianza hacia la máquina, sino porque esos puntos son los que mantienen localizable la responsabilidad.

Preguntas abiertas

• Cuando un sistema multi-agente falla y ningún agente cometió el error, ¿quién responde ante el afectado?
• ¿Tiene derecho un usuario a saber cuántos agentes —y de qué fabricantes— intervinieron en la respuesta que recibe?
• Si la eficiencia empuja a retirar al humano del bucle, ¿dónde se vuelve a anclar la responsabilidad?
• ¿Estamos diseñando sistemas de agentes que cooperan, o sistemas donde la culpa no tiene domicilio?
• La interoperabilidad ya está casi resuelta. ¿Quién está trabajando con la misma intensidad en la trazabilidad de la responsabilidad?

No hay respuesta cerrada para ninguna. Pero conviene una idea final: hacer que los agentes se entiendan entre sí fue un problema de ingeniería, y se está resolviendo bien. Hacer que esa conversación siga siendo auditable, atribuible y supervisable es un problema distinto — y todavía está esperando a quien lo tome en serio.

Referencias

• DEV Community — MCP vs A2A: The Complete Guide to AI Agent Protocols in 2026 (marzo 2026). dev.to
• OneReach.ai — MCP vs A2A: Protocols for Multi-Agent Collaboration 2026. onereach.ai/blog
• OneReach.ai — A2A Protocol Explained: Secure Interoperability for Agentic AI 2026. onereach.ai/blog
• AI Magicx — MCP vs A2A vs ACP: The Complete Guide to AI Agent Communication Protocols in 2026 (marzo 2026). aimagicx.com/blog
• OptinAmpOut — MCP vs A2A vs ACP: The 2026 Guide to AI Agent Communication Protocols. optinampout.com/blogs
• DigitalApplied — AI Agent Protocol Ecosystem Map 2026 (marzo 2026). digitalapplied.com/blog
• Ruh.ai — AI Agent Protocols 2026: The Complete Guide (enero 2026). ruh.ai/blogs