Adopción del protocolo A2A 2026–2028: quién se suma y quién no

La adopción de A2A describe hasta qué punto se impone el protocolo Agent2Agent como estándar abierto para la comunicación entre agentes de IA autónomos. A fecha de 2026, A2A está bajo el paraguas de la Linux Foundation y cuenta con el respaldo de Google, Microsoft, AWS, Salesforce, SAP, ServiceNow y Cisco. Este artículo analiza los impulsores, los obstáculos y los escenarios de adopción hasta 2028, expresamente como previsión, no como un hecho comprobado.

Aviso importante antes de empezar: todo lo que va más allá de los hechos que hoy se pueden demostrar (tasas de adopción, cuotas de mercado, fechas de una interoperabilidad productiva entre proveedores) es una valoración con márgenes de incertidumbre considerables. Las previsiones sobre IA a un horizonte de 18 a 24 meses son frágiles. Las direcciones estructurales son más sólidas que los hitos concretos.

Respuestas rápidas

• ¿Quién se suma? Los grandes proveedores de plataformas: Google (iniciador), Microsoft, AWS, Salesforce, SAP, ServiceNow y Cisco como miembros fundadores. En total, más de 150 organizaciones respaldan el estándar (datos de abril de 2026). Eso convierte a A2A en el estándar de facto para la colaboración entre agentes de distintas plataformas.
• ¿Quién no se suma (todavía) del todo? OpenAI no es miembro fundador. En agosto de 2025, un maintainer de OpenAI declaró que no había planes inmediatos para A2A en el Agents SDK. En la Agentic AI Foundation, OpenAI es cofundador y ha aportado AGENTS.md. Anthropic impulsa sobre todo MCP y se acerca a A2A mediante patrones de puente. Incluso miembros fundadores con un ecosistema propio fuerte, como Salesforce (Atlas) y Microsoft (handoffs de Copilot Studio), solo usan A2A por ahora en el perímetro y se reservan la orquestación interna.
• ¿Cuál es el mayor riesgo? La fragmentación por extensiones propietarias de AgentCard. No una guerra entre proveedores, más bien una diferenciación progresiva dentro del estándar.

Qué es A2A y dónde encaja en el stack de protocolos

Google presentó el protocolo Agent2Agent en abril de 2025 en Cloud Next, con más de 50 socios, y lo donó a la Linux Foundation el 23 de junio de 2025 durante el Open Source Summit North America en Denver. Google entregó la especificación, los SDK (Python, TypeScript) y las herramientas para desarrolladores. Los miembros fundadores del proyecto de la Linux Foundation son AWS, Cisco, Google, Microsoft, Salesforce, SAP y ServiceNow.

Técnicamente, A2A se basa en JSON-RPC 2.0 sobre HTTPS, con streaming mediante Server-Sent Events y notificaciones push opcionales para tareas de larga duración. Cada agente publica una AgentCard, un documento JSON con el endpoint, las capacidades, las skills compatibles, las modalidades y los esquemas de autenticación. Las tareas siguen un ciclo de vida definido (submitted → working → input-required → completed | failed | canceled). El paso conceptual decisivo: la lógica interna del agente remoto sigue siendo opaca. A2A define cómo hablan los agentes entre sí, no cómo piensan. Así, un agente de Salesforce puede llamar a un agente de SAP sin que ninguno revele al otro sus prompts, modelos o memoria.

A2A no está solo. Junto con MCP forma un stack convergente:

• MCP (Model Context Protocol, publicado originalmente por Anthropic en noviembre de 2024 y donado el 9 de diciembre de 2025 a la Agentic AI Foundation bajo la Linux Foundation) regula la relación de agente a herramienta.
• A2A regula la relación de agente a agente.

La lectura oficial, que Google, Salesforce y Microsoft defienden de forma coherente, es: «MCP para las capacidades, A2A para la colaboración». La propia guía de Microsoft lo formula sin rodeos: MCP para el acceso a herramientas y datos, Linux Foundation A2A para la mensajería entre agentes de distintas plataformas.

Los impulsores institucionales: por qué A2A tiene viento a favor estructural

El impulsor más importante es la gobernanza de la Linux Foundation. Es la protección estructural más fuerte imaginable contra una guerra entre proveedores y contra el control unilateral. El proyecto competidor de IBM, ACP, ya se integró en A2A el 29 de agosto de 2025 bajo LF AI & Data. El equipo de ACP detuvo el desarrollo activo y aportó su tecnología a A2A. El resultado es un stack de protocolos abiertos pequeño y coherente en lugar de una guerra de estándares.

El segundo impulsor es la integración en las plataformas empresariales que las empresas europeas ya utilizan. Aquí A2A ya es, en su mayoría, una función del producto (datos de octubre de 2026):

• Salesforce Agentforce 360 usa A2A como handshake entre proveedores para delegar en agentes de terceros, mientras que los traspasos internos se quedan en el Atlas Reasoning Engine.
• SAP Joule incorpora A2A bidireccional: los agentes de terceros podrán llamar a agentes de Joule y viceversa. La disponibilidad general de las funciones A2A en Joule está prevista para el T4 2026. Los agentes del nuevo Joule Studio, que SAP presentó en Sapphire 2026, deberán admitir MCP y A2A de forma nativa. Según SAP, Anthropic Claude se convertirá en una capacidad principal de razonamiento y de agentes en Joule.
• Microsoft Copilot Studio y Microsoft Foundry (antes Azure AI Foundry) han integrado A2A.
• Google Gemini Enterprise, en el que Agentspace se integró en octubre de 2025, incorpora agentes externos mediante A2A.
• ServiceNow Now Assist también usa A2A, y el runtime de AWS Bedrock AgentCore aloja servidores A2A.

Esto es lo central: los entornos de SAP, Salesforce, Microsoft y ServiceNow son los puntos de entrada en los que las empresas se encuentran por primera vez con A2A.

Los obstáculos: dónde se atasca realmente la adopción

Obstáculo 1: fragmentación por extensiones propietarias. Es el riesgo abierto más importante. La gobernanza protege el núcleo, pero cada miembro fundador (Salesforce, SAP, Microsoft, Google, AWS, ServiceNow, Cisco) tiene incentivos comerciales para diferenciarse con extensiones de AgentCard, estados de tarea propios o capacidades «A2A-plus». Si las AgentCards se vuelven específicas de cada proveedor, se pierde justo la portabilidad que justifica la elección del protocolo. Por eso, la señal a vigilar en 2026 es concreta: ¿seguirá siendo AgentCard un documento JSON portable o se volverá específico de cada proveedor?

Obstáculo 2: la competencia de ecosistemas propietarios. Muchos despliegues «multiagente» son en realidad un único agente con muchas integraciones de herramientas. Nosotros lo llamamos multiagente de marketing. Estos sistemas no necesitan A2A en absoluto. Mientras la orquestación interna (Salesforce Atlas, handoffs de Copilot Studio, SAP Joule internamente) siga siendo propia de cada plataforma y A2A solo se use en el perímetro, la profundidad real de uso de A2A será menor de lo que sugieren los anuncios.

Obstáculo 3: cuestiones sin resolver de gobernanza y de límites de confianza. Cada peer A2A es opaco para los demás. Eso es bueno para la confidencialidad, pero complica las pistas de auditoría, los límites de confianza y, en el contexto europeo, la soberanía de los datos. Si un agente de Salesforce llama a un agente de SAP que, a su vez, lanza un paso de razonamiento de Claude mediante A2A, el flujo de datos de una sola tarea puede cruzar varias fronteras de encargados del tratamiento y de residencia de datos. Según el art. 28 del RGPD, esto alarga la cadena de encargados del tratamiento. Si un salto transfiere datos personales a un tercer país, se aplican además los arts. 44–49 del RGPD: si el país de destino no cuenta con una decisión de adecuación conforme al art. 45, ese salto necesita su propia evaluación de la transferencia. Los saltos dentro de la UE y el EEE no requieren esa evaluación. Esto frena la adopción en producción en los sectores regulados.

Diferencias: MCP frente a A2A, AGNTCY y NANDA

Una confusión frecuente es interpretar A2A como competidor de MCP, AGNTCY o NANDA. Es un error. Los papeles están claramente repartidos:

• AGNTCY (Cisco, donado a la Linux Foundation el 29 de julio de 2025) no es un protocolo competidor, sino la capa de identidad, descubrimiento y observabilidad por encima de una malla A2A. Los agentes A2A y los servidores MCP se pueden localizar a través de los directorios de AGNTCY.
• NANDA (MIT Media Lab) es sobre todo un proyecto de investigación: una visión a largo plazo para una identidad descentralizada de agentes, no un protocolo usado en producción en los stacks de las empresas europeas (datos de 2026).

Nuestra valoración para las decisiones de arquitectura en 2026: MCP + A2A es el stack convergente del sector. AGNTCY es el complemento racional cuando importa la identidad entre proveedores. NANDA va a la lista de vigilancia, no a la ruta crítica.

Mapa de actores: posición y señal

La siguiente tabla es una instantánea prospectiva basada en las señales documentadas (datos de 2026), no una hoja de ruta garantizada.

Escenarios hasta 2028

Escenario A: convergencia (la dirección más probable). MCP + A2A se consolidan como un mundo de dos protocolos. Desde nuestro punto de vista, un estado limpio de dos protocolos es la situación más probable en 2027. AgentCard sigue siendo portable; AGNTCY se encarga de la identidad y la observabilidad allí donde importa la federación entre proveedores. La adopción crece impulsada por los entornos de SAP, Salesforce y Microsoft.

Escenario B: fragmentación silenciosa. A2A sigue siendo formalmente el estándar, pero las extensiones propietarias de AgentCard y las funciones «A2A-plus» crean un lock-in de facto. La interoperabilidad entre proveedores funciona en la demo, pero no en producción a través de varios entornos corporativos. Entre A y B decide una pregunta abierta: ¿ofrecerán SAP Joule, Agentforce y Copilot Studio antes de que termine 2026 un A2A real entre proveedores en producción, o el número de despliegues multiagente en producción en todo el DAX 40 seguirá siendo de un solo dígito?

Escenario C: dominio de plataformas en lugar de protocolo. Si una o dos plataformas de hiperescaladores hacen tan dominante su orquestación interna que A2A queda como una función marginal, la importancia estratégica del estándar abierto disminuye. Es menos probable dada la amplia coalición fundadora, pero no se puede descartar.

Ejemplo concreto: la economía de los saltos A2A en un gran grupo europeo

Una aseguradora opera una arquitectura multiagente jerárquica, como hace Allianz con «Project Nemo» (siete agentes especializados en siniestros por deterioro de alimentos tras catástrofes naturales, en producción en Australia desde julio de 2025, desplegado en menos de 100 días, con una reducción documentada del 80 % del tiempo de tramitación y liquidación en siniestros admisibles por deterioro de alimentos inferiores a 500 AUD y human-in-the-loop en el pago). Si trasladamos esto a un caso entre proveedores:

```
Solicitud del cliente
→ Agente principal de Agentforce (Salesforce, internamente Atlas)
→ Salto A2A 1 → Agente de cobertura de SAP Joule (frontera de encargado + posible transferencia internacional)
→ Salto A2A 2 → Paso de razonamiento de Claude (frontera de encargado + posible transferencia internacional)
→ Agente de auditoría (traza completa, un ID de traza para todos los saltos)
→ Una persona decide el pago
```

Cada salto A2A que transmite datos personales a otro proveedor de servicios es un eslabón más en la cadena de contratos de encargo del tratamiento. Si además un salto lleva a un tercer país sin decisión de adecuación, necesita su propia evaluación de la transferencia. El ejemplo anterior tiene dos saltos: dos eslabones más en la cadena de contratos de encargo y, si ambos llevan a terceros países de ese tipo, dos evaluaciones de impacto de la transferencia. Si todos los encargados permanecen en la UE o en el EEE, no hace falta la evaluación de la transferencia, pero la cadena sigue siendo más larga. Este cálculo se pasa por alto con facilidad en el diseño multiagente. La consecuencia operativa: fijar las versiones de los modelos en los flujos de producción, registrar todos los prompts de subagentes, las llamadas a herramientas y las AgentCards utilizadas, y correlacionarlos mediante un único ID de traza.

Para agencias y responsables de decisiones B2B

Para los responsables de decisiones B2B: trata A2A en 2026 como un estándar probable, pero no garantizado. La secuencia por defecto más racional es estandarizar la política de servidores MCP, implantar A2A primero dentro de un mismo entorno, publicar AgentCards y solo después ampliarlo a un segundo entorno. Incluye en los contratos de compra esta pregunta: ¿garantiza el contrato de Agentforce, Joule o Copilot Studio la interoperabilidad A2A y la fidelidad al estándar MCP, y qué ocurre en caso de salida? Guarda entre el 15 y el 25 % del presupuesto de IA como reserva activada por disparadores para eventos de protocolo y de proveedor.

Para las agencias de marketing y de IA, A2A es la mayor palanca de estrategia de producto: publica una AgentCard para cada agente que conviertas en producto, de modo que los entornos de tus clientes puedan llamar a tus agentes directamente desde Agentforce, Joule o Copilot Studio, sin integraciones a medida. Quien construye desde el primer día agentes localizables vía A2A no queda atrapado para siempre detrás de una integración especial.

Blck Alpaca acompaña desde Viena a empresas de toda Europa justo en esta decisión: arquitecturas multiagente soberanas y auditables basadas en MCP y A2A, con una separación clara entre hechos documentados y valoraciones prospectivas. Habla con nosotros antes de comprometerte con una herramienta con 24 meses de antelación. La dirección está clara; los detalles siguen moviéndose.