Qué es el protocolo A2A (Agent2Agent) y cuándo lo necesitas

Un agente de IA que trabaja solo es un producto. Varios agentes que tienen que entenderse entre sí, y que pertenecen a compañías distintas, son un problema de infraestructura: esa es la frontera que intenta resolver A2A, y también la razón de que la mayoría de los equipos que hoy preguntan por él no lo necesiten todavía. Conviene saber en qué lado estás.

El protocolo Agent2Agent lo publicó Google el 9 de abril de 2025 y lo donó a la Linux Foundation dos meses y medio después. Desde marzo de 2026 tiene versión estable. En ese tiempo ha pasado de anuncio a estándar con gobernanza propia, integraciones en las tres nubes grandes y más de ciento cincuenta organizaciones que declaran apoyarlo.

Lo que no ha pasado, todavía, es al mercado laboral. En las 25.439 ofertas de empleo tech publicadas en España entre junio y agosto de 2026, la mención a Agent2Agent aparece en siete, lo que no es una contradicción sino el orden natural de las cosas cuando una capa de infraestructura llega antes que los equipos que tendrán que operarla. Conviene saberlo antes de convertirla en requisito de una arquitectura.

Qué es el protocolo A2A

A2A es un protocolo de comunicación entre agentes autónomos. Su unidad de trabajo no es la llamada a una función sino la tarea: un agente cliente le encarga algo a un agente remoto y ese agente remoto, sin exponer cómo funciona por dentro, decide por su cuenta cómo resolverlo. Puede tardar segundos o días, pedir información intermedia y devolver resultados parciales por el camino, y el protocolo se ocupa de que todo ese intercambio tenga una forma predecible sin que ninguna de las dos partes conozca las tripas de la otra. Ahí está el valor.

La pieza que hace posible el descubrimiento se llama Agent Card, un documento en JSON que el agente publica en una ruta conocida de su dominio y que declara tres cosas: qué habilidades ofrece, por dónde se le habla y qué mecanismo de autenticación exige a quien quiera hablarle. Un agente que quiere delegar trabajo lee esa tarjeta, comprueba si la habilidad que busca está ahí y actúa en consecuencia, sin registro central y sin catálogo que alguien tenga que mantener al día: la capacidad se anuncia donde vive el agente que la ofrece.

El transporte no inventa nada. La versión 1.0 define un modelo común de operaciones y tres formas estándar de llevarlo: JSON-RPC sobre HTTP, HTTP+JSON/REST y gRPC, más unas reglas para quien necesite el suyo. Cada transporte resuelve a su manera los resultados que llegan por tramos, algo habitual en tareas que duran más de unos segundos, y el protocolo reutiliza para eso estándares que ya existen, Server-Sent Events entre ellos. Un agente solo acepta ese modo si lo declara en su Agent Card. Esa decisión de diseño es deliberada y tiene consecuencias prácticas: los balanceadores, los cortafuegos de aplicación, la observabilidad y los mecanismos de autenticación que ya hay montados siguen sirviendo. No es un canal nuevo que haya que abrir en la red, es tráfico web con una gramática acordada encima.

Lo nuevo es la relación. En una integración clásica quien llama sabe exactamente qué va a ejecutar el otro lado y con qué parámetros, mientras que en A2A quien llama describe un objetivo y confía en que el agente remoto tenga criterio suficiente para alcanzarlo por su cuenta. Esa confianza es la característica del protocolo y también su superficie de riesgo, y es la razón de que la versión estable dedique una parte del trabajo a identidad verificable. No es un detalle menor.

En qué se diferencia A2A de MCP

La confusión entre los dos protocolos es la pregunta más repetida del tema y tiene una respuesta corta: van en ejes distintos. MCP, el Model Context Protocol, conecta un modelo o un agente con las herramientas y las fuentes de datos que necesita para trabajar, sean una base de datos, una API o un sistema de ficheros. Es la relación entre un agente y su instrumental. A2A conecta agentes completos entre sí, cada uno con su propio instrumental por dentro. Es la relación entre pares.

La distinción práctica está en lo que cada lado expone. Cuando un agente habla por MCP, el otro extremo es pasivo: una base de datos, una API, un sistema de ficheros. Hace lo que se le pide y no decide nada. Cuando un agente habla por A2A, el otro extremo es activo: recibe un encargo, elige un camino y puede volver a preguntar. Eso cambia el modelo de seguridad completo, porque ya no se trata de restringir qué operaciones expone una herramienta, sino de acotar qué se le puede pedir a algo que razona.

La segunda diferencia es de opacidad, y va al revés de lo que parece: MCP funciona precisamente porque el agente conoce el esquema exacto de la herramienta que va a usar. A2A funciona precisamente porque no lo conoce: el agente remoto puede cambiar su modelo, su framework o su lógica interna sin romper la integración, siempre que su Agent Card siga declarando la misma habilidad. Eso es lo que deja a dos organizaciones evolucionar sus sistemas a ritmos distintos sin coordinarse en cada despliegue.

Los dos protocolos están hoy en la misma fundación. Sus mantenedores los describen como complementarios, y en la práctica lo son: un sistema realista usa los dos a la vez, MCP hacia dentro para que cada agente alcance sus datos y A2A hacia fuera para que ese agente colabore con otros. No compiten. Si quieres el detalle del primero, lo desarrollamos en la pieza sobre qué es MCP y cómo conecta un agente con sus herramientas.

Cómo funciona una tarea de A2A de principio a fin

El flujo tiene cuatro momentos y merece la pena verlos en orden, porque el vocabulario del protocolo, con sus tarjetas y sus identificadores de tarea, se entiende mucho mejor siguiendo una tarea real que leyendo definiciones sueltas.

Primero, el descubrimiento. El agente cliente recupera la Agent Card del agente remoto y comprueba qué habilidades declara y qué autenticación pide, y solo entonces crea la tarea, enviando un mensaje con el objetivo y recibiendo a cambio un identificador con el que podrá seguirla hasta el final. Después viene la ejecución: el agente remoto trabaja, publica estados y, si el resultado se produce por tramos, los va enviando por el canal de eventos hasta que entrega el resultado final empaquetado en lo que el protocolo llama artifact, que puede ser texto, datos estructurados o un fichero.

Esa secuencia importa por un detalle que se pasa por alto: entre el segundo y el tercer momento el control cambia de manos. Literalmente. El cliente ya no orquesta, espera. Si el agente remoto interpreta mal el objetivo, o decide un camino caro, o llama a una herramienta que no debía, el cliente lo descubre cuando llega el resultado. Diseñar ese punto es trabajo de arquitectura, no de integración. Ninguna librería lo resuelve sola.

La versión 1.0.0, publicada el 12 de marzo de 2026, añadió la pieza que faltaba para que esto funcione entre organizaciones. Son las Agent Cards firmadas criptográficamente. Con la tarjeta firmada, el agente que va a delegar puede verificar que quien dice ser un agente de un dominio lo es de verdad, en vez de fiarse de que la URL parezca legítima y de que el certificado del servidor esté en regla. En paralelo, el ecosistema se amplía con extensiones que no forman parte de la especificación: AP2, el Agent Payments Protocol de Google, define cómo un agente autoriza y ejecuta un pago en nombre de alguien, y se apoya en A2A sin ser parte de él. La última release etiquetada del repositorio es la 1.0.1, publicada el 28 de mayo de 2026 con tres correcciones y ninguna función nueva. La página de la especificación sigue anunciando la 1.0.0 como versión publicada.

Cuándo no necesitas A2A

Esta es la pregunta que el resto de la documentación disponible no hace, y es la que ahorra dinero. A2A resuelve un problema concreto y acotado: la comunicación entre agentes que cruzan una frontera de organización, de proveedor o de equipo con ciclo de vida propio. La palabra clave es frontera. Cuando no existe, el protocolo añade ceremonia sin añadir capacidad.

Tres situaciones donde la respuesta honesta es que no hace falta. La primera: dos agentes que son tuyos, viven en tu misma nube y los despliega el mismo equipo, un caso donde una llamada de función con tipos declarados, su contrato y sus tests, es más rápida de construir, más fácil de depurar y bastante más barata de operar. La segunda: un agente que solo necesita leer datos o ejecutar operaciones sobre sistemas que no razonan, un caso que es MCP de manual y donde montar A2A encima significa resolver un problema que no tienes. La tercera: un piloto que todavía no ha decidido qué agentes va a tener, porque adoptar el protocolo de interoperabilidad antes de saber con quién vas a interoperar significa fijar decisiones de arquitectura sobre supuestos que aún no se han contrastado.

El análisis independiente del protocolo ha puesto nombre a este patrón cuando se lleva al extremo. Lo llama arquitectura de disfraz. Consiste en adoptar el vocabulario de los sistemas distribuidos de agentes, con sus tarjetas y sus identificadores de tarea, sin tener ninguno de los problemas de frontera que justifican ese vocabulario. El síntoma es reconocible: el equipo mantiene canales de eventos para intercambios que ocurren dentro del mismo proceso.

La contrapartida también hay que decirla, porque el criterio de descarte no es una excusa para no adoptar nada. Cuando la frontera sí existe, el coste de no tener protocolo es una integración a medida por cada par de sistemas. Si cada agente tiene que hablar con todos los demás, el número de pares posibles es n(n−1)/2: un equipo con tres agentes de tres proveedores gestiona tres integraciones y con seis pasa a quince, así que ahí el protocolo deja de ser ceremonia y se convierte en lo que evita que el mapa de integraciones se vuelva ingobernable.

Quién gobierna A2A y qué respaldo real tiene

El recorrido institucional del protocolo es corto y está bien documentado. Google lo anunció el 9 de abril de 2025. El 23 de junio de ese año lo donó a la Linux Foundation, que creó un proyecto propio con gobernanza neutral y con Amazon Web Services, Cisco, Microsoft, Salesforce, SAP y ServiceNow entre los miembros fundadores. El 27 de agosto de 2026 dio otro paso: A2A fue aceptado como proyecto Growth Stage de la Agentic AI Foundation, la fundación dirigida por la Linux Foundation donde ya estaba MCP. Los dos protocolos comparten ahora gobernanza, que es lo que hace creíble el discurso de complementariedad.

La cifra que se cita en todas partes procede del comunicado del primer aniversario, del 9 de abril de 2026: más de ciento cincuenta organizaciones respaldan el estándar. Merece una lectura precisa. El comunicado habla de organizaciones que declaran apoyo, no de despliegues verificados en producción, y no desglosa unas de otras, mientras que el blog de Google publicado el mismo día habla de más de cien empresas tecnológicas, una cifra distinta que probablemente responda a otro criterio de conteo. Si la cifra se usa en una decisión, conviene citarla como apoyo declarado y atribuirla a su fuente.

Donde el respaldo es comprobable es en las integraciones. Microsoft lo soporta en Copilot Studio y en Azure AI Foundry, y Amazon lo hace a través de Bedrock AgentCore, lo que significa que un equipo que ya trabaja en cualquiera de esas plataformas tiene el camino de adopción abierto sin tener que construir el transporte por su cuenta. También significa que la decisión de adoptar A2A se está tomando, muchas veces, sin decidirla: llega dentro de la plataforma.

Qué capacidad de equipo exige operar agentes interoperables

Aquí es donde el tema deja de ser una cuestión de protocolo. Un agente que puede recibir encargos de agentes de otra compañía es una superficie expuesta con capacidad de decidir. Eso introduce tres trabajos que no existían antes en el equipo.

El primero es identidad. Las Agent Cards firmadas resuelven la verificación criptográfica, pero siguen dejando en manos de alguien la decisión de qué dominios se aceptan, qué habilidades se exponen hacia fuera y qué se hace exactamente cuando una firma no valida. Es gestión de confianza entre organizaciones. Está más cerca de la política de acceso que del desarrollo.

El segundo es acotación. Un agente remoto que interpreta un objetivo puede llamar a herramientas por su cuenta, y la instrucción que dispara esa llamada puede venir de un texto que nadie revisó. Ese vector tiene nombre y lo tratamos aparte en la pieza sobre prompt injection y quién audita ese agujero en un equipo. En un escenario multiagente el problema se compone, porque la instrucción maliciosa puede entrar por un agente, cruzar la frontera dentro de una tarea legítima y acabar ejecutándose en otro que nunca la recibió directamente.

El tercero es observabilidad. Una tarea que dura horas, cambia de estado varias veces y se resuelve dentro de otra organización necesita trazas, reintentos idempotentes y una respuesta clara a la pregunta de qué ha pasado exactamente cuando el resultado no llega. Ese trabajo se parece más a operar una integración distribuida que a construir un producto de IA. El perfil que lo sostiene es distinto.

El dato de mercado ayuda a poner ese requisito en contexto. Según el análisis de mercado de Shakers sobre 25.439 ofertas tech publicadas en España entre junio y agosto de 2026, la capa de orquestación que sí se pide hoy es LangChain, presente en 719 ofertas de las 21.641 que declaran tecnologías. Agent2Agent aparece, mencionado en la descripción, en siete. Como contraste de escala, Python figura en 7.777.

La lectura no es que el protocolo sea irrelevante. Es que la capacidad para operarlo no se pide hoy por su nombre: se construye sobre perfiles de ingeniería que ya trabajan con orquestación de agentes y sistemas distribuidos. Quien adopta A2A esperando encontrar en el mercado un perfil especializado con ese nombre va a buscar algo que el mercado todavía no etiqueta, y quien lo adopta sabiendo que lo que necesita es ingeniería de integración con criterio de seguridad está mirando el problema correcto.

Ese desajuste entre lo que la infraestructura ya permite y lo que los equipos pueden sostener tiene nombre y tiene medida. El nombre es implementation gap. La medida la puso BCG en enero de 2025, sobre 1.803 ejecutivos: el 75% situaba la IA entre sus tres prioridades estratégicas y solo un cuarto reportaba valor significativo de sus iniciativas. El protocolo no cierra esa diferencia, y ninguna capa de infraestructura la cierra sola, porque lo que hay al otro lado del último tramo no son estándares sino skills + agents operados por alguien con criterio. La cierra la gente que sabe desplegarlo, acotarlo y auditarlo, que es la misma capacidad que hace falta para que un agente pase de funcionar a ser fiable, y que desarrollamos en la pieza sobre qué equipo necesita una empresa para llevar agentes de IA a producción.

Preguntas frecuentes sobre el protocolo A2A

¿A2A sustituye a MCP?

No. Resuelven ejes distintos y sus mantenedores los describen como complementarios. MCP conecta un agente con sus herramientas y fuentes de datos, que son extremos pasivos. A2A conecta agentes entre sí, que son extremos que razonan y deciden. Un sistema realista usa MCP hacia dentro y A2A hacia fuera. Los dos están hoy bajo la gobernanza de la Linux Foundation.

¿Qué es una Agent Card?

Es un documento JSON que un agente publica en una ruta conocida de su dominio y que declara qué habilidades ofrece, por dónde se le habla y qué autenticación exige. Sirve para que otro agente lo descubra sin registro central. Desde la versión 1.0.0 puede ir firmada criptográficamente, de modo que quien la lee verifica que el agente pertenece de verdad al dominio que dice.

¿Quién mantiene el protocolo A2A?

La Linux Foundation, desde el 23 de junio de 2025, cuando Google le donó la especificación y los SDK. La gobernanza es neutral. Entre sus miembros fundadores están Amazon Web Services, Cisco, Microsoft, Salesforce, SAP y ServiceNow, que son competidores directos entre sí en varias capas del mercado. La versión estable 1.0.0 se publicó el 12 de marzo de 2026 y la última disponible es la 1.0.1, del 28 de mayo de 2026.

¿Cuántas empresas usan A2A?

El comunicado del primer aniversario de la Linux Foundation, de abril de 2026, habla de más de ciento cincuenta organizaciones que respaldan el estándar. Es apoyo declarado, no despliegues verificados, y el comunicado no desglosa unas de otras, mientras que el blog de Google del mismo día cita más de cien empresas tecnológicas con otro criterio de conteo. Conviene citar la cifra atribuyéndola.

¿Sobre qué tecnología funciona A2A?

Sobre tres transportes estándar: JSON-RPC sobre HTTP, HTTP+JSON/REST y gRPC. La versión 1.0 define las operaciones una vez y deja que cada transporte las lleve. Es una decisión de diseño con consecuencia práctica: la infraestructura de red, autenticación y observabilidad que ya existe sigue sirviendo, porque el tráfico es tráfico web con una gramática acordada encima.

¿Merece la pena adoptar A2A en un piloto?

Normalmente no. El protocolo aporta cuando el agente del otro lado cruza una frontera de organización, de proveedor o de equipo con ciclo propio, así que un piloto que aún no ha decidido qué agentes tendrá acaba fijando decisiones sobre supuestos. Si los dos agentes son tuyos y comparten nube y equipo, una llamada de función con tipos declarados es más rápida de construir y más barata de operar.