El año 2024 y 2025 consolidaron el Model Context Protocol de Anthropic como estándar de facto para conectar un agente con herramientas y fuentes de datos. MCP resuelve de forma elegante el problema de que cada modelo hablara con cada servicio mediante una integración puntual: con MCP, un servidor expone sus capacidades una vez y cualquier cliente compatible las consume. Pero hay un problema paralelo que MCP no aborda por diseño: cómo se comunican dos agentes distintos entre sí. Para ese hueco, Google presentó en abril de 2025 el protocolo Agent2Agent o A2A, y en junio de ese mismo año lo donó a la Linux Foundation como proyecto abierto. A finales de 2025 vale la pena mirar con calma qué pretende resolver, cómo se relaciona con MCP y qué falta para que la interoperabilidad entre agentes sea una realidad operativa.
Qué problema intenta resolver A2A
MCP resuelve una capa concreta: un agente (cliente) consulta a servicios (servidores MCP) que exponen herramientas, recursos y prompts. La comunicación es asimétrica: el servidor responde a peticiones del cliente pero no inicia acciones autónomas. Esto funciona muy bien cuando el agente es la inteligencia central y las herramientas son pasivas. No funciona cuando quieres que dos agentes, cada uno con su propia capacidad de razonamiento, colaboren en una tarea compleja repartiéndose trabajo y negociando resultados.
Piensa en un ejemplo práctico. Tienes un agente de ventas de una empresa que entiende el catálogo, las promociones y el estado del inventario. Tienes otro agente de finanzas que conoce las políticas de descuento y los límites de crédito de cada cliente. Cuando un cliente pide un presupuesto complejo con descuento especial, quieres que el agente de ventas hable con el de finanzas, le consulte qué margen tiene disponible para este cliente y reciba una respuesta con justificación. Esto no es una llamada a una herramienta que devuelve JSON; es una conversación entre dos sistemas con criterio propio que tienen que entenderse.
A2A intenta estandarizar exactamente esa conversación. El protocolo define cómo un agente descubre a otros (a través de “tarjetas de agente” publicadas en endpoints conocidos), cómo inicia una tarea (con una descripción en lenguaje natural o estructurado), cómo siguen ambos lados el estado de la tarea (eventos, resultados parciales, finalización), y cómo cada agente expone sus capacidades sin revelar cómo las implementa internamente. La opacidad es un principio central del diseño: un agente A2A no tiene por qué exponer su arquitectura interna, solo su capacidad observable.
La relación con MCP
Una pregunta frecuente es si A2A compite con MCP. La respuesta corta es no: operan en capas distintas y son complementarios. MCP resuelve la conexión entre un agente y sus herramientas (modelo-herramienta). A2A resuelve la conexión entre dos agentes (agente-agente). Un sistema bien diseñado puede usar los dos: cada agente se conecta a sus herramientas vía MCP, y los agentes entre sí se comunican vía A2A.
Esta separación no es trivial. Los dos problemas parecen similares a primera vista pero tienen semántica distinta. Una herramienta MCP es una función que se llama con parámetros y devuelve datos; la responsabilidad del resultado la tiene el agente llamante. Un agente A2A es un sistema con su propia cadena de razonamiento y toma de decisiones; la responsabilidad del resultado está distribuida. El protocolo de A2A incluye nociones como negociación, confianza y autoría que MCP no necesita.
Esta separación también refleja una observación empírica del mercado. En 2024 vimos que las herramientas entre agentes se estandarizaban razonablemente bien con MCP, pero cada vez que dos productos de empresas distintas intentaban colaborar como agentes, aparecía integración a medida con APIs REST, webhooks propios y esquemas de eventos incompatibles. A2A intenta cortar esa proliferación antes de que cristalice en decenas de protocolos cerrados.
Donación a la Linux Foundation
La decisión de donar A2A a la Linux Foundation en junio de 2025 es estratégicamente relevante. Google podría haberlo mantenido como iniciativa propia, pero eligió una gobernanza neutral desde el inicio porque los protocolos que cuajan como estándares suelen ser los percibidos como neutrales y un protocolo Google-only tiene techo de adopción en Microsoft, AWS y Anthropic. El resultado es que el repositorio oficial vive en la organización a2aproject en GitHub, con patrocinio explícito de Linux Foundation AI & Data, y los primeros meses han visto contribuciones de Microsoft, SAP, Salesforce, Cisco e Intuit, lo que da señales razonables de interés multi-proveedor.
Qué incluye la especificación
La especificación actual de A2A define varios componentes básicos. Las tarjetas de agente son archivos JSON que publica un agente en una URL conocida (típicamente /.well-known/agent.json) describiendo sus capacidades, endpoints de comunicación, mecanismos de autenticación soportados y ejemplos de interacción. Cualquier agente compatible puede leer la tarjeta y decidir si es pertinente colaborar con él.
Las tareas son la unidad de trabajo que un agente inicia en otro. Una tarea tiene una descripción, un estado (pendiente, en curso, pausada esperando información, completada, cancelada o fallida), una cola de mensajes bidireccional y una especificación de artefactos que se producirán. El estado es observable vía streaming con eventos enviados por el servidor para que el agente cliente pueda mostrar progreso en tiempo real sin hacer encuesta activa.
Los artefactos son la salida estructurada: texto, JSON, archivos binarios o URLs a recursos externos. El protocolo es agnóstico del formato mientras el tipo de contenido esté declarado, lo que permite que agentes que generan cosas muy distintas usen la misma API.
Donde están los límites reales
La especificación cubre bien el canal técnico pero deja cuestiones importantes abiertas. La primera es la seguridad y confianza. ¿Cómo sé que el agente con el que hablo es quien dice ser? ¿Cómo autentico al usuario final a través de una cadena de dos o tres agentes? A2A define puntos de anclaje para usar OAuth, OIDC o mTLS pero deja al integrador decidir, lo que significa que dos implementaciones pueden ser incompatibles en la práctica aunque ambas sigan A2A.
La segunda es la semántica de las capacidades. Una tarjeta A2A dice “puedo hacer X” pero la descripción de X es texto libre. Dos agentes pueden describir la misma capacidad con palabras distintas, o describir capacidades distintas con palabras parecidas. Esto es un problema clásico de interoperabilidad semántica que A2A posterga deliberadamente al usar lenguaje natural y descripciones estructuradas como guía, pero que en la práctica requiere disciplina por parte de los desarrolladores.
La tercera son las garantías de ejecución. Si pido a otro agente que ejecute una tarea crítica y falla, ¿quién es responsable? A2A define el protocolo de comunicación pero no un modelo de responsabilidad. Esto es adecuado para un estándar técnico pero deja trabajo importante para contratos legales y acuerdos de nivel de servicio cuando hablamos de agentes corporativos que actúan entre empresas.
Estado del ecosistema a finales de 2025
A finales de 2025, A2A es un protocolo joven pero con tracción real. Hay SDKs oficiales en Python, TypeScript, Java, Go y C#. Algunas plataformas como LangChain, CrewAI y AutoGen exponen salida A2A nativa. Varias plataformas empresariales (Salesforce Einstein, SAP Joule, ServiceNow) han anunciado compatibilidad entrante en sus próximas versiones. El soporte por parte de Anthropic es tibio: Claude no lo integra nativamente todavía, probablemente porque MCP ya cubre gran parte del espacio que les interesa y A2A compite indirectamente con algunas extensiones que Anthropic está explorando.
La adopción real, medida en agentes desplegados que se comunican vía A2A en producción, es todavía muy baja. Esto no es inusual para un protocolo de doce meses. La comparación natural es con MCP, que en sus primeros doce meses también parecía más promesa que producto, y que ahora mueve integraciones serias. A2A puede seguir camino similar si resuelve los límites mencionados y si los grandes proveedores mantienen su compromiso.
Mi lectura
Mi valoración después de seguir la especificación desde su publicación original y trastear con sus primeros SDKs es que A2A ocupa un hueco real y necesario. La pregunta no es si va a existir un protocolo agente-a-agente estándar sino cuál va a ser, y A2A empieza en mejor posición que los candidatos alternativos por la combinación de diseño técnico decente, gobernanza neutral y respaldo multi-proveedor.
Dicho esto, 2026 será el año decisivo. Si Microsoft, AWS y Anthropic adoptan A2A en sus productos primarios, se consolidará. Si alguno de ellos propone una alternativa propia, el espacio se fragmentará y volveremos a integraciones a medida durante años más. La historia reciente de protocolos (MCP triunfó, Bedrock Agents y Semantic Kernel se quedaron con nichos) sugiere que el que tiene gobernanza abierta y proceso de especificación público gana. A2A cumple ambas condiciones, lo que lo convierte en apuesta razonable para equipos que necesitan construir sistemas multi-agente hoy. La recomendación pragmática es diseñar las interfaces internas de tus agentes pensando en A2A, aunque todavía no lo uses, para reducir fricción futura cuando llegue el momento de integrar con sistemas externos que ya lo hablen. Esperar a ver quién gana tiene coste de oportunidad real.
