MCP vs A2A vs UCP vs AP2 vs A2UI: La pila de protocolos de agentes explicada

Los protocolos de agentes de IA se multiplican con rapidez: MCP, A2A, UCP, AP2, A2UI y estándares adyacentes aparecen cada vez más en los mismos diagramas de arquitectura. A menudo se describen como protocolos competidores. En la práctica, la mayoría resuelve diferentes problemas de interoperabilidad en límites distintos. La pregunta útil no es “¿Qué protocolo ganará?”, sino “¿Qué relación en el sistema necesita estandarizarse?”

El error fundamental: comparar protocolos que operan en límites diferentes

Un protocolo es útil porque dos sistemas implementados de forma independiente necesitan un contrato estable. El contrato solo tiene sentido si el límite está claro. Un agente que se comunica con una base de datos tiene un problema de interoperabilidad diferente al de un agente que delega trabajo en otro, un comprador que autoriza una compra o un agente remoto que solicita a una aplicación nativa que renderice un formulario.

La guía de desarrolladores de Google de 2026 presenta explícitamente MCP, A2A, UCP, AP2, A2UI y los protocolos de interfaz de usuario relacionados como una pila de estándares complementarios. Un mismo flujo de trabajo de ejemplo puede utilizar varios de ellos de forma conjunta: herramientas para el inventario, agentes remotos para proveedores, comercio para pedidos, autorización de pagos para gastos y protocolos de interfaz de usuario para la interacción.

La Pila de Responsabilidad de Protocolos

1. MCP: conectar el agente a las capacidades

El Model Context Protocol es un estándar abierto para conectar aplicaciones de IA a sistemas externos donde residen herramientas, datos y recursos reutilizables. Un servidor expone capacidades; un host de MCP se conecta a ese servidor y pone dichas capacidades a disposición del modelo o aplicación.

La documentación actual de MCP TypeScript v2 describe el protocolo exactamente en esos términos: los servidores exponen herramientas, recursos y prompts, mientras que los hosts, como entornos de desarrollo o aplicaciones personalizadas, se conectan a ellos. Esto convierte a MCP principalmente en un protocolo de integración de capacidades.

Utilice MCP cuando

• Una aplicación de IA necesite acceso estandarizado a herramientas o API.
• Desea que un único servidor de capacidades funcione con múltiples hosts de IA compatibles.
• Necesite acceso estructurado a datos o recursos sin codificar de forma fija cada integración en cada agente.
• El sistema externo sea un proveedor de capacidades, no un agente autónomo equivalente.

2. A2A: conectar agentes independientes

Agent2Agent (A2A) está diseñado para la comunicación entre sistemas de agentes independientes y potencialmente opacos. Su especificación actual v1.0 se centra en el descubrimiento de capacidades, mensajería, tareas, artefactos, contenido multimodal y colaboración de larga duración sin requerir que un agente exponga sus herramientas internas, memoria o implementación a otro.

Esa opacidad es el límite importante. El agente invocador no necesita saber si el agente remoto utiliza internamente MCP, herramientas personalizadas, un planificador propietario, otro proveedor de modelos o escalamiento humano. Necesita un contrato para descubrir capacidades y delegar trabajo.

A2A v1.0 también estandariza la negociación de versiones y admite múltiples enlaces alrededor de un modelo de datos común. Su mecanismo publicado de Agent Card ofrece a los clientes un punto de descubrimiento estándar para las capacidades, protocolos admitidos, requisitos de autenticación y habilidades de un agente.

Use A2A cuando

• Un agente autónomo necesita delegar trabajo en otro agente autónomo.
• El sistema remoto debe permanecer opaco detrás de un contrato de capacidades.
• Las tareas pueden ser de larga duración, asíncronas o requerir interacción humana en el bucle (human-in-the-loop).
• Los agentes están construidos con diferentes frameworks, lenguajes, proveedores o pertenencia organizativa.

MCP vs. A2A: integración vertical frente a colaboración horizontal

El propio proyecto A2A describe ahora la distinción como horizontal frente a vertical: MCP conecta agentes con herramientas y bases de datos internas, mientras que A2A permite la colaboración peer-to-peer entre sistemas de agentes.

3. UCP: estandarizar el comercio agéntico

El Universal Commerce Protocol no es un protocolo de agentes genérico. Estandariza los recorridos comerciales entre interfaces de consumidores, comerciantes y proveedores de pagos. La implementación de Google ya admite capacidades como la creación de carritos, el checkout, el cumplimiento de pedidos y el ciclo de vida de los pedidos a través de perfiles y API versionadas.

Un comerciante puede publicar un perfil de UCP en /.well-known/ucp describiendo servicios, versiones de protocolo y capacidades. Ese patrón de descubrimiento es importante porque una interfaz agéntica no debería necesitar un contrato de checkout a medida para cada comerciante.

UCP también es intencionalmente componible. La descripción técnica general de Google indica que puede integrarse a través de API, A2A y MCP, y es compatible con AP2 para la autorización de pagos agénticos.

Use UCP cuando

• El flujo de trabajo involucra productos de comerciantes, carritos, checkout, cumplimiento o ciclo de vida del pedido.
• Está construyendo una interfaz para comerciantes que debe funcionar con experiencias de compra agénticas.
• La integración necesita semántica específica de comercio en lugar de llamadas a herramientas genéricas.
• Desea un contrato de comercio interoperable que pueda coexistir con MCP, A2A y protocolos de pago.

4. AP2: demostrar que el agente tenía autorización para gastar

El comercio agéntico introduce un problema que los flujos de checkout ordinarios no tenían que resolver de la misma manera: un agente puede realizar transacciones cuando el humano no está haciendo clic en el botón final en tiempo real. El Agent Payments Protocol (AP2) aborda la autorización, la autenticidad y la rendición de cuentas para los pagos dirigidos por agentes.

La guía de protocolos de Google de 2026 describe AP2 a través de mandatos tipados que capturan la intención del usuario, las restricciones de gasto y la transacción específica que se autoriza. AP2 puede funcionar como una extensión junto a UCP: UCP describe la transacción comercial, mientras que AP2 proporciona pruebas de que el agente tenía autorización para realizar el pago.

Esta distinción es importante. Un protocolo de checkout puede indicarle a un comerciante qué debe comprarse. Por sí solo no demuestra quién autorizó al agente a gastar, bajo qué límite, para qué comerciante, durante cuánto tiempo o si el carrito final se mantuvo dentro de esa autorización.

UCP vs. AP2: semántica de transacciones frente a autoridad

5. A2UI: permita que los agentes describan interfaces sin adueñarse de su frontend

Agent-to-User Interface (A2UI) aborda otro límite: cómo un agente remoto o local comunica una interfaz interactiva enriquecida a una aplicación anfitriona. En lugar de enviar HTML, CSS y JavaScript arbitrarios, A2UI utiliza datos declarativos que el anfitrión renderiza a través de su propio catálogo de componentes de confianza.

Esto preserva el sistema de diseño y el modelo de seguridad de la aplicación anfitriona, al tiempo que permite que un agente solicite interfaces dinámicas. A2UI v0.9 enfatiza específicamente la intención de interfaz de usuario independiente del framework y las actualizaciones en streaming a través de la web, móviles y otros clientes.

El trabajo posterior de Google sobre A2UI + MCP Apps también demuestra que estos modelos de interfaz de usuario no son necesariamente mutuamente excluyentes. La interfaz de usuario nativa declarativa y las experiencias más ricas de aplicaciones integradas pueden coexistir según la tarea.

Utilice A2UI cuando

• Un agente remoto necesita solicitar formularios, tarjetas, controles u otra interfaz interactiva.
• El anfitrión debe preservar sus componentes nativos, estilo y límite de seguridad.
• No desea que los agentes remotos envíen código frontend ejecutable arbitrario.
• La misma intención de interfaz definida por el agente debe funcionar en diferentes frameworks de cliente.

La prueba de selección de protocolos

No empiece por el acrónimo. Empiece por la relación que necesita interoperabilidad.

Un flujo de trabajo multiprotocolo realista

Por qué es poco probable que un protocolo universal de agentes los reemplace a todos

Un protocolo universal suena más sencillo hasta que debe codificar la semántica de cada dominio. El descubrimiento de herramientas, la colaboración prolongada entre agentes, el checkout, la autorización de pagos y la interfaz de usuario nativa tienen diferentes requisitos de ciclo de vida, seguridad y corrección.

La propia web evolucionó mediante protocolos por capas en lugar de un único formato de mensaje para cada problema. El stack agéntico emergente parece avanzar en la misma dirección: primitivas horizontales comunes, contratos de dominio especializados y descubrimiento/versionado explícitos.

Por lo tanto, el desafío arquitectónico pasa de «¿qué protocolo gana?» a con qué claridad se componen los protocolos sin duplicar la identidad, la autorización, el estado y la semántica de auditoría.

La composición de protocolos genera nuevos modos de fallo

La elección del protocolo no reemplaza la arquitectura de la aplicación

Los estándares abiertos reducen el acoplamiento de integración, pero no deciden su modelo de dominio, política de autorización, fuente de verdad, estrategia de reintentos o criterios de aceptación. Una herramienta MCP aún puede exponer la capacidad incorrecta. Un agente A2A aún puede devolver un artefacto erróneo. Un checkout de UCP aún puede contener datos desactualizados del comerciante. La lógica de la aplicación aún puede aplicar incorrectamente un mandato AP2.

Trate los protocolos como contratos entre componentes que evolucionan de forma independiente. Mantenga la verdad del dominio y la política consecuente en la capa de aplicación a la que pertenecen, y luego use protocolos para hacer que los límites sean interoperables.

¿Qué cambiaría esta respuesta?

La pila tecnológica cambia si los protocolos convergen, si un estándar absorbe formalmente a otro o si los proveedores estandarizan una capa compartida de identidad y autorización a través de múltiples límites. UCP ya demuestra la composición al admitir APIs, A2A y MCP, y al integrarse con AP2 en lugar de reemplazarlos.

La respuesta también varía según el alcance de la aplicación. Un agente interno pequeño puede necesitar únicamente MCP. Un flujo de trabajo entre múltiples empresas puede necesitar A2A. Un comerciante puede necesitar UCP sin A2UI. Un agente de compras delegado puede necesitarlos todos. Utilice el conjunto de protocolos más pequeño que represente los límites reales sin aplanar la semántica de dominio.

Limitaciones

Los protocolos analizados aquí se encuentran en diferentes niveles de madurez y tienen distintos modelos de gobernanza. A2A ha alcanzado una especificación v1.0 estable, mientras que otros estándares continúan evolucionando rápidamente. La adopción en el ecosistema también es desigual entre proveedores y frameworks.

Este artículo se enfoca en la responsabilidad arquitectónica más que en la exhaustividad de la implementación. Los métodos de autenticación específicos, los enlaces de transporte, los esquemas y los mecanismos de extensión deben tomarse de la especificación vigente de cada protocolo.

Conclusión

MCP, A2A, UCP, AP2 y A2UI cobran más sentido cuando se consideran protocolos para diferentes relaciones, y no cinco intentos competitivos de estandarizar los “agentes”.

MCP expone capacidades. A2A coordina agentes independientes. UCP otorga al comercio su propio contrato legible por máquinas. AP2 añade autoridad de pago verificable. A2UI proporciona a los agentes una vía declarativa y segura hacia las interfaces de usuario. Por lo tanto, la web agéntica emergente no está reemplazando los protocolos con IA; está creando una nueva pila de protocolos en torno a la IA.

Preguntas frecuentes

Glosario

Fuentes principales y lecturas adicionales