A2A vs MCP: Cómo elegir el protocolo adecuado para la comunicación entre agentes

La mayoría de sistemas de agentes de producción necesitan dos protocolos, no uno. El Model Context Protocol (MCP) da a un agente acceso a herramientas y fuentes de datos — registros de NetSuite, contactos de HubSpot, catálogos de proveedores, consultas de Redshift. El Agent2Agent Protocol (A2A) da a los agentes una forma de delegar trabajo a otros agentes — un agente de cotización pidiendo a un agente de catálogo piezas de repuesto, un agente de aprovisionamiento pidiendo a un agente de cumplimiento que verifique una certificación GMP. Confundir los dos conduce a arquitecturas frágiles: usar A2A para llamar a una base de datos, o usar MCP para coordinar dos agentes independientes, produce sistemas que luchan contra el diseño de su propio protocolo.

El 1 de agosto de 2026, OpenAI confirmó Astra — su próxima familia principal de modelos, diseñada explícitamente para tareas multiagente de larga duración que trabajan en problemas durante horas o días. Una versión interna resolvió diez problemas abiertos previamente no resueltos en matemáticas y informática teórica, con un coste total de tokens de aproximadamente $2,000. Astra coordina múltiples agentes durante periodos extendidos, que es el patrón exacto donde A2A (delegación agente-a-agente) y MCP (acceso agente-a-herramienta) deben trabajar juntos. La capa de modelo ahora se está construyendo para el patrón de dos protocolos.

Este artículo es un marco de decisión para equipos que eligen entre A2A y MCP — o, más comúnmente, decidiendo dónde va cada uno en un sistema multiagente. Asume que entiendes los fundamentos de cada protocolo. Si necesitas una guía de integración, el puente A2A Hermes Agent y la visión general de la pila de protocolos MCP + A2A cubren el lado de implementación.

La distinción en una línea

MCP conecta un agente con herramientas. A2A conecta agentes con agentes. MCP es un protocolo de llamada a herramientas — un agente solicita un recurso o invoca una función, y un servidor responde con datos estructurados. A2A es un protocolo de delegación de tareas — un agente envía una unidad de trabajo a otro agente, recibe salida en streaming y rastrea la tarea a través de una máquina de estados. El patrón de producción, confirmado en más de 150 organizaciones A2A y más de 10,000 servidores MCP, es: A2A entre agentes, MCP entre agentes y herramientas.

Dónde encaja cada protocolo

Dimensión	MCP	A2A
Qué conecta	Agente → herramienta, fuente de datos, API	Agente → agente
Unidad de trabajo	Llamada a herramienta (petición/respuesta)	Tarea (ciclo de vida con estado)
Cuerpo del protocolo	Anthropic (especificación abierta, final 2026-07-28)	Google (especificación abierta, Linux Foundation, más de 150 organizaciones)
Transporte	STDIO, Streamable HTTP (SSE deprecado, sunset de 12 meses)	JSON-RPC 2.0 sobre HTTP, streaming SSE
Descubrimiento	El servidor registra herramientas; el cliente descubre	Agent Card en /.well-known/agent-card.json
Estado	Sin estado (especificación 2026-07-28); el estado vive en el cliente	Máquina de estados de tarea: submitted → working → input-required → completed/failed/canceled
Streaming	Los resultados de herramientas son respuestas únicas	message/stream para entrega en tiempo real de tokens y artefactos
Humano-en-el-bucle	No es un concepto de primera clase	INPUT_REQUIRED es un estado de tarea de primera clase
Autenticación	Por servidor; OAuth 2.1 en especificación, bearer tokens en práctica	Por agente; el Agent Card declara esquemas de autenticación, el gateway maneja la aplicación
Adopción	Más de 10,000 servidores, 4 SDKs Tier 1 (TypeScript, Python, Go, C#)	Más de 150 organizaciones, gobernanza de Linux Foundation

La tabla responde a la primera pregunta que la mayoría de equipos hacen: si tu integración es "un agente necesita consultar NetSuite para un registro de cliente", eso es MCP. Si tu integración es "un agente de aprovisionamiento necesita que un agente de precios evalúe tres cotizaciones de proveedores y devuelva una recomendación", eso es A2A. La distinción es si la cosa al otro lado tiene su propio razonamiento, o si es una fuente de datos que responde a una consulta estructurada.

Las cinco preguntas que determinan la división

1. ¿El otro lado razona, o responde?

Un servidor MCP de NetSuite no razona. Recibe una llamada a herramienta (get_customer, search_items), consulta la API y devuelve JSON estructurado. El agente que lo llamó hace el razonamiento. Un agente de precios A2A sí razona — recibe una tarea ("evalúa estas tres cotizaciones contra precios históricos y fiabilidad del proveedor"), ejecuta su propia inferencia de modelo, puede llamar a sus propias herramientas MCP y devuelve una recomendación con razonamiento adjunto.

Si el otro lado es una fuente de datos o una API, usa MCP. Si el otro lado es un agente autónomo con su propio modelo, sus propias herramientas y su propia toma de decisiones, usa A2A. La prueba práctica: ¿la cosa que llamas tiene su propio prompt? Si sí, A2A. Si no, MCP.

2. ¿Necesitas salida en streaming?

Las llamadas a herramientas MCP son petición/respuesta. El servidor procesa la petición y devuelve un único resultado. No hay estado intermedio, no hay streaming token a token, no hay artefactos parciales. Esto está bien para consultar una base de datos o obtener un registro — quieres el resultado completo, no un flujo de fragmentos.

A2A soporta message/stream, que entrega deltas de tokens y artefactos a medida que se producen. Un agente de precios que tarda 30 segundos en evaluar tres cotizaciones puede transmitir su razonamiento mientras trabaja, de modo que el agente que llama (y el humano observando) pueda ver el progreso, detectar errores temprano y cancelar si el razonamiento se desvía. Si tu flujo de trabajo produce salida a lo largo del tiempo y necesitas actuar sobre resultados parciales, A2A es el protocolo que lo soporta nativamente.

3. ¿Hay una puerta de aprobación humana?

MCP no tiene un concepto de primera clase de humano-en-el-bucle. Puedes construir lógica de aprobación en el agente que llama a herramientas MCP — el agente se pausa, pide a un humano, luego procede — pero el protocolo mismo no codifica esto. El estado de aprobación vive en tu código de aplicación, no en el protocolo.

A2A define INPUT_REQUIRED como un estado de tarea de primera clase. Cuando un agente alcanza una decisión que necesita aprobación humana — una autorización de compra, una aprobación de cotización, una decisión de acceso a datos — transiciona la tarea a INPUT_REQUIRED. El agente que llama (o el operador humano detrás de él) ve un estado de protocolo estándar, no un detalle específico del framework. Cuando el humano responde, la tarea se reanuda. Si tu flujo de trabajo incluye puertas de aprobación que cruzan fronteras de agentes, A2A transporta esas puertas de forma transparente. El puente A2A de Hermes Agent mapea las solicitudes de aprobación nativas de Hermes al estado INPUT_REQUIRED de A2A, de modo que una cadena de delegación de agentes puede incluir un punto de control humano independientemente del framework en el que se ejecute cada agente.

4. ¿Cuánto tarda el trabajo?

Las llamadas a herramientas MCP están diseñadas para operaciones cortas y sincrónicas — consultar una API, obtener un registro, ejecutar un cálculo. La especificación 2026-07-28 hizo a MCP explícitamente sin estado, lo que significa que el servidor no mantiene contexto de conversación entre llamadas. El estado vive en el cliente (el agente), no en el servidor. Este es el diseño correcto para herramientas: un servidor NetSuite no debería recordar que consultaste un cliente hace cinco minutos.

Las tareas A2A están diseñadas para trabajos de mayor duración con gestión explícita del ciclo de vida. Una tarea pasa por submitted → working → completed (o failed, canceled, input-required). La máquina de estados es parte del protocolo. Una evaluación de precios que tarda dos minutos, una comprobación de cumplimiento que tarda una hora, o una tarea de investigación multiagente que tarda un día — estas encajan en el modelo de tarea de A2A. Astra de OpenAI, confirmada el 1 de agosto, está construida para tareas que trabajan en problemas durante horas o días. El patrón de coordinación multiagente de Astra se mapea directamente al ciclo de vida de tarea de A2A, no al modelo de llamada a herramientas sin estado de MCP.

5. ¿Estás llamando a un sistema o coordinando múltiples agentes?

Si tu agente necesita hablar con NetSuite, HubSpot y BigCommerce, eso son tres servidores MCP. Cada servidor expone herramientas; el agente las llama según sea necesario. El agente hace la coordinación — decide qué herramienta llamar, cuándo y en qué orden. Los servidores MCP no saben unos de otros.

Si tienes un agente de aprovisionamiento que necesita delegar a un agente de catálogo, un agente de precios y un agente de cumplimiento — cada uno con su propio modelo y sus propias herramientas — eso son tres endpoints A2A. El agente de aprovisionamiento envía tareas, recibe resultados en streaming y coordina la cadena de delegación. Los agentes de catálogo, precios y cumplimiento pueden cada uno usar MCP para acceder a sus propias fuentes de datos. Los dos protocolos operan en capas diferentes: A2A maneja la delegación agente-a-agente, MCP maneja el acceso agente-a-herramienta dentro de cada agente.

Cuándo usar ambos: el patrón de producción

El patrón de producción, confirmado por la guía empresarial de tyk.io y visible en las más de 150 organizaciones A2A, es una arquitectura de dos capas:

Cada agente especializado es un endpoint A2A (expone un Agent Card, acepta tareas, transmite resultados). Cada agente especializado también usa MCP para conectar a sus propias fuentes de datos. El agente orquestador nunca habla con NetSuite directamente — delega al agente de precios, que usa MCP para consultar NetSuite. Esta separación mantiene la superficie de herramientas de cada agente gobernada y auditable, mientras la capa A2A maneja la coordinación entre agentes.

La implementación de referencia del puente A2A de Hermes Agent demuestra este patrón: un gateway maneja la superficie del protocolo A2A (Agent Card, dispatch JSON-RPC, streaming SSE, máquina de estados de tarea), y handlers conectables traducen la semántica de tarea A2A a la API nativa de cada framework. Añadir un nuevo framework de agente significa escribir una clase handler — el protocolo, el gateway y la máquina de estados son infraestructura compartida. El mismo gateway puede enrutar a Hermes Agent, OpenClaw, o cualquier handler futuro sin cambiar la superficie del cliente A2A.

Cuándo un solo agente es suficiente

No todos los sistemas necesitan A2A. La investigación de Princeton NLP encontró que un solo agente igualó o superó a un sistema multiagente en el 64% de las tareas evaluadas — a 2× el coste para la configuración multiagente. Si tu flujo de trabajo es un solo agente que consulta NetSuite, redacta una cotización y la envía para aprobación, necesitas MCP (para la conexión NetSuite) y una puerta de aprobación a nivel de aplicación. No necesitas A2A.

A2A se vuelve necesario cuando tienes agentes con diferentes modelos, diferentes superficies de herramientas o diferentes fronteras de propiedad que necesitan coordinarse. Un agente de aprovisionamiento del equipo de compras y un agente de cumplimiento del equipo financiero son propiedad de grupos diferentes, pueden ejecutarse en infraestructura diferente y tienen selecciones de modelo diferentes. A2A les da un protocolo para delegar y rastrear trabajo sin compartir código base ni despliegue. Si todos tus agentes son el mismo modelo en la misma infraestructura con el mismo propietario, un solo agente con herramientas MCP es más simple y más barato.

La especificación MCP 2026-07-28 final: qué cambió para esta decisión

La especificación MCP se publicó como final el 28 de julio de 2026. Los cuatro SDKs Tier 1 (TypeScript, Python, Go, C#) hablan 2026-07-28. La especificación hizo a MCP explícitamente sin estado — los servidores no mantienen estado de sesión entre llamadas. La política de deprecación de SSE de 12 meses está activa: el transporte Streamable HTTP reemplaza a SSE, y los despliegues SSE existentes tienen hasta julio de 2027 para migrar.

Para la decisión A2A-vs-MCP, la especificación final confirma la estratificación: MCP es un protocolo de herramientas sin estado. Si estabas usando sesiones MCP para mantener el estado de conversación del agente, la especificación dice que pares — el estado pertenece al agente (el cliente MCP), no al servidor. Esto hace la capa A2A más claramente necesaria: la coordinación con estado y de larga duración entre agentes no es algo que MCP esté diseñado para manejar. La máquina de estados de tarea de A2A llena ese hueco.

Una nota sobre la superposición de transporte

Ambos protocolos usan HTTP y SSE, lo que puede causar confusión sobre si compiten. No lo hacen — la superposición de transporte es superficial. MCP usa HTTP para llamadas a herramientas (petición → respuesta) y está migrando de SSE a Streamable HTTP para notificaciones iniciadas por el servidor. A2A usa JSON-RPC 2.0 sobre HTTP para el dispatch de tareas y SSE para la transmisión de salida de tareas. El transporte es fontanería; la semántica del protocolo es diferente. MCP transporta llamadas a herramientas. A2A transporta ciclos de vida de tareas. Puedes ejecutar ambos sobre el mismo gateway — la implementación de referencia hace exactamente esto, con el gateway manejando HTTP y SSE para ambos protocolos mientras la capa del puente traduce a la API nativa de cada framework.

Qué significa esto para tu arquitectura

Si estás construyendo un sistema de agentes B2B — automatización de RFQ, flujos de trabajo de aprovisionamiento, soporte al cliente con grafos de conocimiento, orquestación de pipelines de datos — la decisión de protocolo sigue la forma del flujo de trabajo:

• Un agente, múltiples fuentes de datos → solo MCP. El agente usa módulos MCP para conectar a NetSuite, HubSpot, BigCommerce y catálogos de proveedores. No se necesita A2A.
• Múltiples agentes, mismo propietario, misma infraestructura → MCP para herramientas, coordinación a nivel de aplicación para el trabajo entre agentes. Considera A2A si la lógica de coordinación se vuelve lo suficientemente compleja como que una máquina de estados a nivel de protocolo la simplificaría.
• Múltiples agentes, diferentes propietarios o diferente infraestructura → A2A para delegación agente-a-agente, MCP para el acceso a herramientas de cada agente. Este es el patrón de producción para sistemas de agentes distribuidos.
• Tareas de larga duración con puertas de aprobación humana → A2A para el ciclo de vida de tarea y el estado INPUT_REQUIRED, MCP para las llamadas a herramientas dentro de cada tarea. La puerta de aprobación cruza fronteras de agentes como una transición de estado A2A, no como código de aplicación personalizado.

La confirmación de Astra de OpenAI el 1 de agosto hace del patrón multiagente de larga duración la dirección de diseño del modelo frontera. Astra está construida para tareas que trabajan en problemas durante horas o días, coordinando múltiples agentes durante periodos extendidos. La pila de protocolos que soporta este patrón es A2A para coordinación y MCP para acceso a herramientas — la arquitectura de dos protocolos que este artículo describe.

---

Un distribuidor de mercado medio necesita un agente de cotización que habla con un agente de catálogo que habla con un agente de cumplimiento — cada uno respaldado por un modelo diferente, cada uno propiedad de un equipo diferente, cada uno conectando a diferentes sistemas a través de módulos MCP. A2A da a esos agentes un protocolo compartido para delegación y streaming. MCP da a cada agente acceso gobernado a sus fuentes de datos. El patrón de puente deja a Hermes Agent, OpenClaw y cualquier otro framework participar en la red A2A sin reescribir sus internals.

Solicita un proyecto con alcance definido

Una semana de discovery. Obtienes un inventario de sistemas, mapa de flujo de trabajo y alcance fijo — independientemente de si construyes con nosotros.