Protocolos agente-a-agente: la próxima capa abierta
Actualizado: 2026-05-03
Los años 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.
Puntos clave
- MCP resuelve la conexión agente-herramienta (asimétrica); A2A resuelve la conexión agente-agente (simétrica con razonamiento propio en cada lado).
- Los dos protocolos son complementarios, no competidores: un sistema bien diseñado puede usar MCP para herramientas y A2A para coordinación entre agentes.
- A2A define tarjetas de agente, tareas con estado observable, artefactos estructurados y streaming de progreso en tiempo real.
- Las limitaciones reales están en seguridad y confianza (la autenticación queda al integrador), semántica de capacidades (texto libre, no ontología), y garantías de ejecución (sin modelo de responsabilidad formal).
- La gobernanza neutral bajo Linux Foundation AI & Data es el factor que lo convierte en apuesta razonable frente a alternativas propietarias.
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: un agente de ventas que entiende el catálogo, las promociones y el estado del inventario, y un 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.
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 — eventos, resultados parciales, finalización.
- Cómo cada agente expone sus capacidades sin revelar su arquitectura interna — la opacidad es un principio central del diseño.
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.
| Protocolo | Resuelve | Semántica |
|---|---|---|
| MCP | Agente ↔︎ Herramienta | Función con parámetros que devuelve datos; responsabilidad del agente llamante |
| A2A | Agente ↔︎ Agente | Sistema con razonamiento propio; responsabilidad distribuida |
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 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.
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ó gobernanza neutral desde el inicio porque los protocolos que cuajan como estándares suelen ser los percibidos como neutrales. 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.
Qué incluye la especificación
La especificación actual de A2A define varios componentes básicos:
- Tarjetas de agente — archivos JSON publicados en una URL conocida (típicamente
/.well-known/agent.json) describiendo capacidades, endpoints de comunicación, mecanismos de autenticación soportados y ejemplos de interacción. - Tareas — unidad de trabajo con descripción, estado (pendiente, en curso, pausada, completada, cancelada o fallida), cola de mensajes bidireccional y especificación de artefactos. El estado es observable vía streaming con eventos enviados por el servidor.
- Artefactos — 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.
Donde están los límites reales
La especificación cubre bien el canal técnico pero deja cuestiones importantes abiertas:
- Seguridad y confianza — 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.
- 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 distintas capacidades con palabras parecidas.
- Garantías de ejecución — A2A define el protocolo de comunicación pero no un modelo de responsabilidad. Si un agente externo falla una tarea crítica, la distribución de responsabilidad queda para contratos legales y acuerdos de nivel de servicio.
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. El soporte por parte de Anthropic es todavía tibio, probablemente porque MCP ya cubre gran parte del espacio que les interesa. Este ecosistema emergente se analiza también en el contexto de UX para agentes: primer consenso de diseño, donde los patrones de coordinación multi-agente son una de las fronteras aún sin estabilizar.
Conclusión
Mi valoración después de seguir la especificación desde su publicación original 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.
La recomendación pragmática: 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. 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.
