La historia de la computación distribuida ha sido una sucesión de auge de protocolos seguida de una consolidación gradual. En los años 90, tecnologías como CORBA, DCOM, RMI y el incipiente SOAP competían para integrar sistemas empresariales, hasta que REST las superó gracias a su simplicidad y compatibilidad nativa con HTTP.
De manera similar, protocolos para mensajería en tiempo real como XMPP o IRC se fragmentaron antes de que MQTT y WebSockets encontraran su espacio. El patrón se repite: cada nuevo paradigma computacional genera una oleada de estándares que luego convergen a medida que se despliegan implementaciones e interoperabilidad resulta fundamental.
En la actualidad, el ecosistema de agentes de inteligencia artificial se encuentra en esa fase de proliferación. Durante los últimos 18 meses se han presentado cuatro protocolos relevantes: el Modelo de Contexto (MCP) desarrollado por Anthropic a finales de 2024; el Protocolo de Comunicación entre Agentes (ACP) de IBM Research que vio la luz en marzo de 2025; Agent2Agent (A2A) de Google, publicado en abril de 2025; y el Protocolo de Red para Agentes (ANP) creado por un grupo independiente. 
Además, el grupo comunitario de protocolos para agentes AI del W3C ha abierto una vía oficial para estandarización, y el IETF ya evalúa borradores enfocados en el transporte de agentes. La comunidad técnica organiza talleres y surgen repositorios en GitHub semanales que prometen soluciones para la comunicación entre agentes.
¿Qué resuelve cada protocolo?
La aparente confusión entre protocolos se aclara al entender que no compiten directamente, sino que cubren distintas capas dentro de una arquitectura en pila. El marketing, a menudo, presenta cada estándar como “el estándar para la comunicación de agentes de IA” sin precisar su ámbito.
MCP se especializa en la invocación de herramientas. Define el modo en que un modelo descubre, llama e interpreta respuestas de funciones ofrecidas por un servidor, funcionando como un contrato tipado de llamadas remotas (RPC) sobre HTTP. Para abril de 2026, la Linux Foundation reportó más de 10,000 servidores públicos activos compatibles con MCP y 164 millones de descargas mensuales del SDK Python, consolidándolo como el estándar imbatible para esta capa.
A2A, por su parte, aborda la coordinación de tareas entre agentes. Mientras MCP regula la llamada a herramientas, A2A define cómo agentes delegan tareas, introduciendo conceptos como tarjetas de agentes (anuncios de capacidades), estados del ciclo de vida de tareas y modos de interacción (sincrónico, streaming y asincrónico). Google cedió A2A a la Linux Foundation en junio de 2025 y ha sido adoptado ampliamente en entornos empresariales para cubrir las carencias de MCP en coordinación.
ACP ofrece un formato ligero para el intercambio de mensajes entre agentes, sin las complejidades de coordinación completas de A2A. Resulta adecuado donde basta con una simple mensajería, evitando la sobrecarga del ciclo de vida de tareas.
ANP se focaliza en el descubrimiento y la identidad de agentes, usando identificadores descentralizados (DIDs) y gráficos JSON-LD para describir capacidades. Esto habilita mercados descentralizados de agentes sin un registro centralizado.
En conjunto, esta arquitectura emergente sugiere capas complementarias: descubrimiento de capacidades mediante ANP o registros simples, coordinación mediante A2A, llamadas a herramientas usando MCP, y mensajería ligera por medio de ACP cuando no se requieren las complejidades completas.
El desafío pendiente del transporte
Los protocolos actuales se basan predominantemente en HTTP, un reflejo de sus orígenes en equipos de investigación y proveedores de APIs para entornos empresariales, donde HTTP es el estándar y facilita implementaciones y demostraciones.
No obstante, HTTP parte de la premisa de un servidor accesible directamente, un problema dado que el 88% de dispositivos conectados están detrás de NAT (traducción de direcciones de red), lo que imposibilita una conexión directa sin recurrir a relés. Para flotas de agentes que necesitan comunicarse directamente—superando límites entre nubes, redes domésticas y despliegues en el borde—esto centraliza todo el tráfico a través de infraestructuras de relé, aumentando latencia, costos y puntos de fallo.
Estos protocolos definen qué se comunican los agentes, pero no cómo se encuentran ni establecen conexiones directas entre ellos, un problema propio de la capa de sesión (capa 5 en el modelo OSI) que no abarcan MCP, A2A, ACP ni ANP.
Las tecnologías para solventar esto existen: técnicas de perforación NAT con STUN permiten atravesar el NAT en cerca del 70% de topologías; cifrados con X25519 Diffie-Hellman y AES-256-GCM garantizan la privacidad a nivel de túnel sin necesidad de una autoridad certificadora; y protocolos como QUIC o esquemas personalizados basados en UDP ofrecen comunicaciones fiables evitando el bloqueo por cabezal típico de TCP. Estas herramientas son las mismas usadas en VPNs como WireGuard o en conexiones peer-to-peer en WebRTC.
Lo que cambia en agentes es la necesidad de un enrutamiento basado en capacidades: los agentes deben localizar otros por sus funcionalidades, no solo por nombre de host. Por ejemplo, un agente investigador puede preguntar por agentes que ofrezcan datos financieros en tiempo real. Esto se asemeja más a un registro de servicios que a un DNS tradicional y extiende la filosofía de ANP para el transporte.
Varios proyectos empiezan a integrar estos componentes. Pilot Protocol ofrece la especificación más completa con un borrador en el IETF que aborda direccionamiento, establecimiento de túneles y perforación NAT. libp2p es otra base consolidada con funcionalidades similares, y el grupo QUIC del IETF trabaja en extensiones para NAT que serán de gran ayuda.
¿Cómo será la convergencia definitiva?
Los protocolos basados en HTTP (MCP, A2A) ya avanzan hacia versiones estables. El próximo año servirá para madurar implementaciones en producción, robustecer la seguridad, escalar servidores MCP y mejorar la federación en A2A, sin cambios radicales en diseño. Las capas de llamada a herramientas y coordinación están prácticamente resueltas.
El transporte, sin embargo, permanecerá rezagado entre 18 y 24 meses. Tras un período de diversidad experimental en redes P2P para agentes, se consolidarán una o dos soluciones tras la acumulación de datos de rendimiento. La estandarización oficial de IETF y W3C podría materializarse entre 2027 y 2028, probablemente precedida por implementaciones open source que establecerán estándares de facto.
Para responsables de ingeniería que toman decisiones arquitectónicas ahora, la recomendación es adoptar los protocolos de capa aplicación con confianza: MCP se puede implementar sin riesgos y A2A es recomendable para coordinación multiagente con la expectativa de evolución. En la capa de transporte es aconsejable desarrollar algo provisional o evaluar implementaciones tempranas sabiendo que el panorama cambiará.
Quienes diseñen arquitecturas con una estricta separación entre semántica de aplicación (MCP, A2A) y transporte (cualquiera sea la solución final) tendrán una ventaja definitiva, pues adaptarse al transporte después suele ser costoso. Esta lección ya quedó demostrada en la era de los microservicios, donde carecer de separación dificultaba añadir observabilidad o gestión de fallos posteriormente.
Philip Stayetski, cofundador de Vulture Labs, aporta estas reflexiones sobre los estándares y retos que marcarán la comunicación entre agentes de IA en los próximos años.
