La historia de la informática distribuida es una de proliferación de protocolos seguida de consolidación.
La arquitectura de agente de solicitud de objetos común (CORBA), el modelo de objetos componentes distribuidos (DCOM), la invocación de método remoto de Java (RMI) y los primeros protocolos de acceso a objetos simples (SOAP) compitieron por el mercado de integración empresarial a finales de la década de 1990 antes de que la transferencia de estado representacional (REST) ganara silenciosamente por ser más simple y nativo de HTTP.
El Protocolo extensible de mensajería y presencia (XMPP), Internet Relay Chat (IRC) y una docena de protocolos propietarios fragmentaron la mensajería en tiempo real antes de que MG Telemetry Transport (MQTT) y WebSockets crearan sus respectivos nichos. Cada nuevo paradigma informático genera una explosión de estándares competitivos y luego converge lentamente a medida que se acumulan implementaciones y la interoperabilidad se vuelve económicamente necesaria.
El ecosistema de agentes de IA se encuentra actualmente en una fase de proliferación. En los últimos dieciocho meses se han lanzado cuatro protocolos importantes: Model Context Protocol (MCP) de Anthropic a finales de 2024, Agent Communication Protocol (ACP) de IBM Research en marzo de 2025, Agent2Agent (A2A) de Google en abril de 2025 y Agent Network Protocol (ANP) de un grupo de trabajo independiente.
El grupo comunitario W3C AI Agent Protocol ha abierto un camino hacia la estandarización. El Internet Engineering Task Force (IETF) recibe proyectos de Internet sobre transporte de agentes. Las conferencias organizan talleres sobre interoperabilidad. Cada semana aparece un nuevo repositorio de GitHub que pretende resolver el problema de comunicación del agente.
Comprender dónde y con qué rapidez converge esto tiene consecuencias reales para las decisiones arquitectónicas que se toman hoy.
Qué resuelven realmente los protocolos
La proliferación parece más caótica de lo que es porque la mayoría de estos protocolos abordan diferentes capas de una pila en lugar de competir por la misma ranura. La confusión proviene del marketing, que describe cada uno de ellos como “el estándar de comunicación para los agentes de IA” sin especificar qué aspecto de la comunicación.
MCP es una interfaz de llamada de herramientas. Define cómo un modelo descubre funciones expuestas por un servidor, cómo invocarlas y cómo interpretar la respuesta. Este es un contrato de llamada a procedimiento remoto (RPC) escrito entre un cliente modelo y un servidor de herramientas, que se ejecuta a través de HTTP. La Fundación Linux confirmó más de 10,000 servidores MCP públicos activos y 164 millones de descargas mensuales del SDK de Python para abril de 2026. MCP ya ganó la capa de invocación de herramientas. De hecho, el trabajo de estandarización ya se ha llevado a cabo.
A2A es una interfaz de coordinación de tareas. Mientras que MCP define cómo un agente llama a una herramienta, A2A define cómo dos agentes delegan una tarea. Presenta tarjetas de agente (anuncios de capacidad), estados del ciclo de vida de las tareas y tres modos de interacción: sincrónico, de transmisión por secuencias y asíncrono. Google lo donó a la Fundación Linux en junio de 2025 y los equipos de IA empresarial lo han adoptado ampliamente porque llena un vacío real que MCP deja abierto.
ACP es un formato de sobre de mensaje. Ligero, sin estado, diseñado para el intercambio de mensajes de agente a agente sin la semántica de coordinación completa de A2A. Es útil en sistemas donde el simple paso de mensajes es suficiente y la sobrecarga del ciclo de vida de la tarea de A2A es innecesaria.
ANP es un protocolo de descubrimiento e identidad. Utiliza identificadores descentralizados (DID) para la identidad de los agentes y gráficos JSON-LD para las descripciones de capacidades, lo que proporciona una base para los mercados de agentes descentralizados donde no se requiere un libro de contabilidad central.
La pila emergente: descubrimiento de capacidades a través de ANP o registros más simples, coordinación de tareas a través de A2A, llamadas de herramientas a través de MCP y mensajería ligera a través de ACP para casos que no requieren una gestión completa del ciclo de vida de las tareas. Estas capas se complementan en lugar de competir entre sí.
El problema del transporte que persiste
Todos los protocolos de esta lista funcionan a través de HTTP. Esto refleja el origen de los protocolos: los equipos de investigación, los proveedores de API y las empresas de software empresarial crean sistemas en los que HTTP es una suposición incuestionable. HTTP es el protocolo que conocen, el que ya hablan sus servidores y el que facilita las demostraciones.
El problema de producción es que HTTP supone un servidor accesible. Detrás de la traducción de direcciones de red (NAT), y el 88 % de los dispositivos en red están detrás de NAT, no hay ningún servidor accesible sin retransmisión. Para las flotas de agentes que necesitan enrutar tareas directamente de igual a igual a través de los límites de la nube, las redes domésticas y las implementaciones de borde, esta centralización obliga a que cada mensaje pase a través de una infraestructura de retransmisión. La infraestructura de retransmisión agrega latencia, costo y modo de falla.
Los protocolos de la capa de aplicación resuelven la semántica de lo que los agentes se dicen entre sí. No resuelven cómo los agentes se encuentran entre sí y establecen conexiones directas. Este es un problema de la capa de sesión, la capa 5 del modelo de Interconexión de Sistemas Abiertos (OSI), y ninguno de MCP, A2A, ACP o ANP lo resuelve.
Las tecnologías para solucionarlo existen. UDP Punching with Session Traversal Utilities for NAT (STUN) permite el cruce de NAT para aproximadamente el 70 % de las topologías de red. X25519 Diffie-Hellman y AES-256-GCM proporcionan cifrado a nivel de túnel autenticado sin una autoridad de certificación. Las conexiones rápidas a Internet UDP (QUIC) (RFC 9000) o los protocolos de ventana deslizante personalizados sobre el protocolo de datagramas de usuario (UDP) proporcionan una entrega confiable sin bloqueo de cabecera de línea TCP. Estas son las mismas primitivas que usa WireGuard para túneles VPN y WebRTC para transmisiones de medios de navegador a navegador.
Lo que difiere en el contexto del agente es el enrutamiento basado en capacidades. Los agentes deben encontrar a sus pares no por el nombre de host, sino por lo que esos pares pueden hacer. Un agente de investigación debería poder preguntar «¿qué pares tienen datos cambiarios en tiempo real?» » y reciba una lista de agentes especialistas actualmente activos. Está más cerca de un registro de servicios que DNS y es una extensión natural de la filosofía de diseño de ANP aplicada a la capa de transporte.
Un puñado de proyectos juntan estas piezas. Pilot Protocol tiene la especificación publicada más completa, con un borrador de Internet del IETF que cubre direccionamiento, tunelización y recorrido NAT para redes de agentes. libp2p proporciona una base probada con primitivas similares. El grupo de trabajo QUIC del IETF está desarrollando extensiones transversales de NAT que serán relevantes aquí.
¿Cómo será la convergencia?
Los protocolos basados en HTTP (MCP, A2A) ya están convergiendo hacia versiones estables. En los próximos 12 meses veremos un aumento de la producción, mejoras de seguridad, servidores MCP sin estado para escalamiento horizontal y una mejor federación A2A, en lugar de nuevos diseños fundamentales. Las capas de invocación de herramientas y coordinación de tareas están en gran medida resueltas.
La capa de transporte tiene un retraso de 18 a 24 meses. Espere un período de diversidad de implementaciones a medida que los equipos experimenten con diferentes enfoques para la red de agentes de igual a igual (P2P), seguido de una consolidación en torno a una pequeña cantidad de implementaciones una vez que se acumulen datos empíricos sobre el rendimiento y la confiabilidad. Los estándares del IETF y el W3C probablemente producirán algo en la ventana 2027-2028, momento en el cual una o dos implementaciones de código abierto habrán acumulado suficientes implementaciones de producción para establecer estándares de facto antes de la especificación formal.
Para los líderes de ingeniería que toman decisiones arquitectónicas hoy en día, la implicación práctica es la adopción multinivel. Los protocolos de la capa de aplicación son lo suficientemente estables como para confiar en ellos. La adopción de MCP ahora es de bajo riesgo. La adopción de A2A para la coordinación de múltiples agentes es razonable mientras se espera que evolucione el protocolo. La capa de transporte es donde construyes algo personalizado y planeas reemplazarlo, o evalúas implementaciones tempranas sabiendo que el espacio está siempre en movimiento.
Los equipos que tendrán mayor influencia cuando se estabilice la capa de transporte son aquellos que han diseñado sus sistemas de agentes con una clara separación entre semántica de aplicación (MCP, A2A) y transporte (todo lo que hay debajo). La separación limpia es económica de implementar ahora y costosa de actualizar más adelante, una lección que la era de los microservicios enseñó a todos los que intentaron agregar observabilidad o interrupción de circuitos a sistemas que no la tenían.
Philip Stayetski es cofundador de Vulture Labs.
¡Bienvenido a la comunidad VentureBeat!
Nuestro programa de publicaciones invitadas es donde los expertos técnicos comparten sus conocimientos y brindan análisis neutrales e imparciales en profundidad sobre inteligencia artificial, infraestructura de datos, ciberseguridad y otras tecnologías de vanguardia que están dando forma al futuro de los negocios.
Más información de nuestro programa de publicación de invitados y consulte nuestro pautas ¡Si quieres contribuir con tu propio artículo!
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
