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.
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 un modelo basado en HTTP con extensiones para streaming de eventos, un esquema JSON estricto para las tarjetas de agente que describen capacidades, y un conjunto de verbos estandarizados para iniciar tareas, recibir progreso parcial, entregar resultados y cancelar conversaciones en curso. Nada revolucionario en la base transporte; lo revolucionario es el acuerdo.
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. Esto convierte el descubrimiento de agentes en un problema estándar: un agente cliente puede llamar a un registro o a un endpoint conocido, leer tarjetas y decidir a quién dirigir qué. 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. Sin esto cada implementación inventaba su propia máquina de estados.
La tercera pieza es el acuerdo sobre autenticación y autorización. La v1 define claramente cómo un agente prueba su identidad al otro, cómo se negocian permisos para acceder a capacidades específicas y cómo se registra cada llamada para trazabilidad. Se apoya en OAuth 2.1 y en firmas asimétricas compatibles con estándares como JWT, lo que permite reusar infraestructura de identidad existente en lugar de inventar un mecanismo paralelo.
Implementaciones disponibles en enero de 2026
A los seis meses de la donación a la Linux Foundation, las implementaciones de referencia han madurado lo suficiente para uso real. El SDK oficial en Python, mantenido inicialmente por Google y ahora por el grupo de trabajo de la Linux Foundation, cubre la v1 completa y está en producción en varios sistemas internos de Alphabet. El SDK en TypeScript, más joven, tiene paridad funcional pero menos horas de producción. Microsoft contribuyó una implementación en C# integrada con sus SDKs de Copilot y Azure AI, que funciona bien en ese entorno pero no es el camino estándar para quien no vive en la pila Microsoft.
La comunidad abierta ha contribuido implementaciones en Go, Rust y Java con distintos niveles de madurez. La de Go es la más avanzada y se usa dentro del ecosistema Anthropic para interoperabilidad entre agentes Claude y agentes de otros proveedores. Las de Rust y Java siguen en fase de validación y no las recomendaría para producción aún, pero cubren los casos básicos y crecen rápido.
En cuanto a despliegues reales, los ejemplos más visibles son Google Agentspace integrando agentes de terceros vía A2A, Salesforce Agentforce con el mismo modelo para extender su plataforma con agentes de partners, y varias herramientas de automatización como n8n y Zapier publicando conectores A2A para que los agentes construidos dentro de ellas puedan dialogar con agentes externos sin integración a medida. 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. MCP resuelve la relación agente-herramienta: un agente cliente habla con servidores MCP que exponen capacidades estáticas (una base de datos, una API, un sistema de archivos). La comunicación es asimétrica y el servidor no tiene criterio propio. A2A resuelve la relación agente-agente: dos sistemas, cada uno con su propia inteligencia, colaboran en una tarea con negociación y estado compartido.
En la práctica, un sistema típico en 2026 combina ambos. Un agente principal, con acceso a varias herramientas vía MCP, descubre que para cerrar una tarea necesita consultar a otro agente que tiene conocimiento del dominio. Inicia una conversación A2A con ese agente; este, a su vez, puede estar usando sus propias herramientas MCP internamente. Los dos protocolos no se pisan: cada uno cubre su nivel.
La distinción operativa clave es que MCP se despliega pensando en el cliente que quieres servir (ofreces capacidades, el cliente decide qué usar) y A2A se despliega pensando en la colaboración con iguales (ambos lados son activos, ambos tienen criterio). Confundir los dos casos al diseñar una integración suele producir soluciones feas.
Dónde la v1 todavía no llega
La v1 deja fuera varias áreas que la v2 tendrá que abordar. La más visible es la gestión de identidad entre agentes cuando estos operan con pseudónimos o con identidades temporales. El modelo actual asume que cada agente tiene identidad estable registrada en algún sistema de confianza; para casos donde agentes aparecen y desaparecen dinámicamente (por ejemplo, agentes temporales creados para una tarea concreta), la v1 funciona pero requiere algo de ingeniería adicional.
La segunda área con cobertura parcial es la comunicación entre más de dos agentes en la misma tarea. 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 que los coordina, con el protocolo actuando solo como transporte de los canales dos a dos. Para casos típicos de enjambre o de consenso multi-agente, el protocolo es insuficiente y sigue haciendo falta capa de coordinación específica.
La tercera área menos desarrollada es el tratamiento de conversaciones largas o periódicas. Una conversación A2A en la v1 es naturalmente corta: se inicia, se completa y se cierra. Si quieres una relación sostenida entre dos agentes durante meses, con memoria compartida y contexto acumulado, el protocolo no te da herramientas específicas para ello. Hay que construir la memoria a otro nivel, normalmente en la propia aplicación.
Si adoptar ya o esperar
Mi lectura para quien está diseñando sistemas con agentes en enero de 2026 es que la v1 está lista para producción en casos acotados, y que esperar no aporta mucho. Las implementaciones de referencia cubren los lenguajes principales, la interoperabilidad entre SDKs ha sido probada, el protocolo está formalmente publicado y la gobernanza en Linux Foundation garantiza evolución ordenada. Los cambios previsibles en v2 serán extensiones, no rupturas.
El caso donde recomiendo adoptar sin dudar es 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 que agentes externos colaboren con los tuyos. Es refactor neto positivo.
El caso donde esperar sigue siendo razonable es 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. En ese segundo caso, esperar a la v1.1 o la v2 para que la adopción madure más tiene sentido; el coste de ir primero no siempre compensa.
Mi lectura
A2A v1 es la primera capa abierta para comunicación entre agentes que tiene masa crítica real detrás y gobernanza sana en Linux Foundation. No es ubicua todavía pero está claramente en el camino. 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. Esto es lo que hacía falta para que el ecosistema de agentes saliera del modo silo y empezara a parecerse a Internet abierta en lugar de a servicios incompatibles compitiendo por bloqueo de proveedor.
La comparación útil es con HTTP en los años noventa. Nadie usaba agentes sofisticados esperando a que hubiera protocolo estándar; se construyeron sobre lo que había. Pero cuando HTTP se consolidó, todo lo demás se ordenó alrededor. A2A v1 está en ese momento. Adoptarlo ahora significa apostar bien al futuro predecible del sector, y el coste de hacerlo es bajo si ya estás construyendo con agentes. Hay pocas decisiones estratégicas tan fáciles de tomar en este campo a comienzos de 2026.
