Actualizado: 2026-07-12

En diciembre de 2025 escribí sobre el protocolo Agent2Agent, que Google había donado a la Linux Foundation a mediados de año y que apuntaba a convertirse en el complemento natural de MCP para comunicación entre agentes distintos. Seis semanas después, con la versión 1 publicada formalmente, varias implementaciones de referencia 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 varias 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), 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

La v1 deja fuera varias áreas 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) o 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.

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