En diciembre de 2025 escribí sobre el protocolo Agent2Agent, que Google había donado a la Linux Foundation a mediados de año. Apuntaba a convertirse en el complemento natural de MCP para la comunicación entre agentes distintos. Seis semanas después, con la versión 1 publicada formalmente, las implementaciones de referencia ya operativas y los primeros despliegues reales en productos empresariales, toca actualizar la lectura. Qué incluye esta v1, qué significa en la práctica para quien construye con agentes y si ya merece la pena apostar por ella.

Puntos clave

  • A2A v1 estabiliza el formato de tarjeta de agente, el modelo de tareas con estado y el esquema de autenticación basado en OAuth 2.1 + JWT.

  • MCP y A2A son complementarios, no rivales: MCP cubre agente-herramienta, A2A cubre agente-agente.

  • Los SDK oficiales en Python, JavaScript, Java, Go y .NET ya están listos para producción; Rust sigue en validación.

  • La v1 deja fuera identidades temporales, conversaciones multi-agente en tiempo real y relaciones de largo plazo.

  • Adoptar ya tiene sentido si ya tienes múltiples agentes con integraciones a medida entre ellos.

Qué formaliza la versión 1

La versión 1 del protocolo A2A, publicada formalmente por la Linux Foundation en enero de 2026, consolida las decisiones de diseño que durante 2025 estuvieron en iteración rápida. El núcleo técnico es:

  • Modelo basado en HTTP con extensiones para streaming de eventos.

  • Esquema JSON estricto para las tarjetas de agente que describen capacidades.

  • Conjunto de verbos estandarizados para iniciar tareas, recibir progreso parcial, entregar resultados y cancelar conversaciones.

La pieza más relevante de la v1 es la estabilización del formato de tarjeta de agente. Una tarjeta describe qué puede hacer el agente, qué tipo de entradas espera, qué formato tiene la salida y qué metadatos necesita un cliente para decidir si este agente es candidato para una tarea. Sin tarjeta estandarizada no hay interoperabilidad real.

La segunda pieza estabilizada es el modelo de tareas con estado. Cuando un agente pide a otro que haga algo, la tarea tiene identificador, estado, lista de eventos acumulados y resultado final opcional. Este modelo permite que una conversación entre agentes sea duradera, resumible tras desconexiones, observable para auditoría y cancelable si cambian las circunstancias.

La tercera pieza es el acuerdo sobre autenticación y autorización, apoyado en OAuth 2.1 y firmas asimétricas compatibles con JWT, lo que permite reusar infraestructura de identidad existente.

Implementaciones disponibles

A los seis meses de la donación a la Linux Foundation, las cifras públicas confirman que la madurez es real. Más de 150 organizaciones respaldan ya el proyecto, el doble que hace un año. El proyecto supera las 22.000 estrellas en GitHub y hay SDK listos para producción en cinco lenguajes, según el informe de la Linux Foundation de abril de 2026[1]:

  • SDK oficial en Python[2]: cubre la especificación v1 completa[3] y es el que más uso real acumula.

  • SDK en JavaScript/TypeScript: paridad funcional con el de Python, aunque con menos horas de producción acumuladas.

  • Java y Go: los otros dos SDK oficiales que completan, junto a Python y JavaScript, los lenguajes con más tracción en producción.

  • .NET (Microsoft): integrado en el Microsoft Agent Framework[4], con soporte tanto para exponer como para consumir agentes A2A desde Azure AI Foundry.

  • Rust: todavía en fase de validación en la comunidad; cubre los casos básicos pero no lo recomiendo aún para producción.

Los ejemplos de despliegue más visibles son Google Agentspace, Salesforce Agentforce y conectores A2A en n8n y Zapier. No es ubicuo aún, pero ha salido del terreno demo.

Cómo encaja con MCP

MCP y A2A son complementarios y esa claridad es una de las mejores noticias de la v1. La distinción es simple:

  • MCP resuelve la relación agente-herramienta: un agente cliente habla con servidores que exponen capacidades estáticas. Comunicación asimétrica, el servidor no tiene criterio propio.

  • A2A resuelve la relación agente-agente: dos sistemas con inteligencia propia colaboran en una tarea con negociación y estado compartido.

En la práctica, un sistema típico combina ambos. Un agente principal con acceso a herramientas vía MCP descubre que para cerrar una tarea necesita consultar a otro agente con conocimiento del dominio. Inicia una conversación A2A; ese agente, a su vez, puede estar usando sus propias herramientas MCP internamente.

Confundir los dos casos al diseñar una integración suele producir soluciones feas. Para más sobre el ecosistema MCP, ver el análisis del ecosistema MCP consolidado en 2026.

Dónde la v1 todavía no llega

Estas son las áreas que la v1 deja fuera y que la v2 tendrá que abordar:

  • Identidades temporales: el modelo asume que cada agente tiene identidad estable. Para agentes que aparecen y desaparecen dinámicamente, la v1 funciona pero requiere ingeniería adicional.

  • Comunicación multi-agente en tiempo real: la v1 define bien conversaciones punto a punto; conversaciones de tres o más agentes coordinándose en tiempo real siguen siendo responsabilidad del orquestador.

  • Relaciones sostenidas de largo plazo: una conversación A2A en la v1 es naturalmente corta. Para relaciones de meses con memoria compartida y contexto acumulado, hay que construir esa capa a otro nivel.

Si adoptar ya o esperar

La v1 está lista para producción en casos acotados, y esperar no aporta mucho. Las implementaciones cubren los lenguajes principales, la interoperabilidad entre SDKs ha sido probada y la gobernanza en Linux Foundation garantiza evolución ordenada.

El caso donde recomiendo adoptar sin dudar: cuando ya estás construyendo un sistema con múltiples agentes y actualmente tienes integraciones a medida entre ellos. Sustituir esas integraciones por A2A reduce deuda, estandariza observabilidad y abre la puerta a agentes externos. Es refactor neto positivo.

El caso donde esperar sigue siendo razonable: cuando tienes un único agente hablando con herramientas (usa MCP, no A2A). También cuando estás en un entorno de regulación alta donde cada protocolo nuevo requiere aprobación formal.

Este ecosistema de agentes es inseparable del debate sobre las habilidades y skills de agentes Claude en empresa y de los patrones de skills y subagentes en producción.

Conclusión

A2A v1 es la primera capa abierta para comunicación entre agentes con masa crítica real y gobernanza sana en la Linux Foundation. Combinada con MCP, forma el stack básico de interoperabilidad que la industria necesitaba: herramientas por un lado, agentes por el otro, con estándares abiertos en los dos planos. La comparación útil es con HTTP en los noventa: cuando se consolidó, todo lo demás se ordenó alrededor. A2A v1 está en ese momento.

Versión en inglés: Agent-to-agent protocols v1: what we have in hand.

Preguntas frecuentes

¿A2A sustituye a MCP o tengo que usar los dos?

Son complementarios, no rivales, y un sistema típico combina ambos. MCP resuelve la relación agente-herramienta: un agente cliente habla con servidores que exponen capacidades estáticas, sin criterio propio. A2A resuelve la relación agente-agente: dos sistemas con inteligencia propia colaboran en una tarea con negociación y estado compartido. Si tienes un único agente hablando con herramientas, usa MCP, no A2A; confundir los dos casos al diseñar una integración suele producir soluciones feas.

¿En qué lenguajes puedo usar A2A v1 en producción hoy?

Hay SDK oficiales listos para producción en cinco lenguajes. Python cubre la especificación v1 completa y es el de más uso real; JavaScript/TypeScript tiene paridad funcional con Python, con menos horas de producción. Completan la lista Java, Go y .NET, este último integrado en el Microsoft Agent Framework con soporte para Azure AI Foundry. El SDK de Rust sigue en fase de validación en la comunidad: cubre los casos básicos, pero no es recomendable aún para producción.

¿Qué casos no cubre todavía la versión 1 de A2A?

Tres áreas quedan para la v2. Identidades temporales: el modelo asume que cada agente tiene identidad estable, así que los agentes que aparecen y desaparecen dinámicamente requieren ingeniería adicional. Comunicación multi-agente en tiempo real: la v1 define bien conversaciones punto a punto, pero coordinar tres o más agentes sigue siendo responsabilidad del orquestador. Y relaciones de largo plazo: una conversación A2A es naturalmente corta, y la memoria compartida durante meses hay que construirla a otro nivel.

Fuentes:

  1. Linux Foundation: A2A Protocol Surpasses 150 Organizations[1]
  2. A2A Protocol: especificación oficial v1[3]
  3. Microsoft Agent Framework: A2A v1 en el SDK de .NET[4]
  4. a2aproject/a2a-python: SDK oficial en Python[2]

Última revisión: 2026-04-01.

Fuentes

  1. informe de la Linux Foundation de abril de 2026
  2. SDK oficial en Python
  3. especificación v1 completa
  4. Microsoft Agent Framework