Protocolo A2A (Agent2Agent) 2026: qué es, seguridad y pagos

La explicación oficial de A2A sobre su reparto de funciones con MCP es: «MCP es vertical y profundiza un único agente; A2A es horizontal y conecta agentes a través de fronteras». En A2A, la parte llamada es un agente «opaco»: razona por sí mismo y guarda su propio estado, el llamador no ve qué modelos o herramientas usa internamente, y ambas partes interactúan en varias rondas únicamente a través del ciclo de vida de una tarea (Task). Los documentos oficiales de Taiwán ya mencionan A2A: el Manual de referencia para aplicaciones de inteligencia artificial en el sector público V1.0 del Ministerio de Asuntos Digitales (fecha de entrega indicada en el documento: 115-01-28) dedica en la página 14 un apartado titulado «A2A: protocolo de comunicación entre agentes de IA», que explica que se centra en la comunicación «cliente-remoto».

La gobernanza de A2A se divide en tres etapas. El 2025-06-23 la Linux Foundation anunció que asumía el proyecto, con AWS, Cisco, Google, Microsoft, Salesforce, SAP y ServiceNow como miembros fundadores; el 2025-08-29, ACP, liderado por IBM, se fusionó en A2A y dejó de desarrollarse. El poder de decisión real reside en un Comité Directivo Técnico (TSC) de 9 puestos, uno por empresa: Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM y Bloomberg. Las propuestas se votan con gitvote en issues de GitHub etiquetados como TSC Review; por ejemplo, la #1942, que agrupó 41 issues en los ocho temas de v1.1, se aprobó el 2026-06-25 con 5 votos a favor y 0 en contra (umbral del 51%).

En agosto de 2026, A2A se incorporó a la Agentic AI Foundation (AAIF) como proyecto en etapa Growth Stage, en la misma fundación que MCP. Las fuentes no coinciden en la fecha de incorporación: el blog de AAIF y Axios indican 2026-08-17, el blog oficial y la página de la especificación de A2A indican 2026-08-27, y la noticia de Forbes está fechada el 08-19. Una posibilidad es que el 08-17 sea el anuncio público de la fundación y el 08-27 la publicación del proyecto, pero ninguna fuente confirma esta explicación; este artículo presenta ambas fechas sin elegir una por el lector. Diginomica cuenta A2A como el 5.º proyecto alojado en AAIF, tras MCP, goose, AGENTS.md y agentgateway; algunas fuentes secundarias subrayan que se trata solo de un ajuste organizativo y que las dos especificaciones no se han fusionado.

Los documentos de gobernanza de A2A establecen que «la composición del periodo estable se decidirá 18 meses después de la constitución». Contando desde junio de 2025, ese plazo vence hacia diciembre de 2026, y el anuncio de AAIF no aclara si el TSC se reorganizará; esto es una inferencia, e indica que la composición del TSC podría cambiar pronto, por lo que conviene seguirlo.

En A2A v1.0 se renombraron todos los métodos: message/send pasa a SendMessage, message/stream a SendStreamingMessage y tasks/resubscribe a SubscribeToTask, y se añade ListTasks. Las rutas REST adoptan el estilo AIP, por ejemplo POST /tasks/{id}:cancel, y se elimina el prefijo /v1. El formato de error HTTP pasa de application/problem+json de RFC 9457 a google.rpc.Status, con reason en mayúsculas y guiones bajos (por ejemplo TASK_NOT_FOUND) y domain fijado en "a2a-protocol.org". Las notas de investigación consideran que esta revisión equivale a rehacer A2A al estilo de la guía de diseño de API de Google; esto es una inferencia.

El mayor cambio incompatible del modelo de datos es el aplanamiento de Part. Se eliminaron TextPart, FilePart, DataPart y el campo discriminador kind; ahora un mismo Part contiene solo uno de text, raw (bytes), url o data, y el tipo se determina por qué campo está presente en lugar de leer kind; mimeType pasa a llamarse mediaType y file.fileWithUri pasa a url. Según informes de la comunidad, muchos analizadores siguen leyendo part.kind, y esa es la causa más habitual de los fallos de interoperabilidad entre 0.3 y 1.0. La Agent Card, por su parte, gira ahora en torno a supportedInterfaces[]: cada interfaz lleva su propio url, protocolBinding, protocolVersion y un tenant opcional; el cliente elige según el orden del array y SHOULD implementar un fallback.

La negociación de versiones tiene un valor por defecto en el que pocos reparan: si la cabecera A2A-Version va vacía, se interpreta como 0.3. El cliente solo envía Major.Minor y, si el servidor no la admite, responde −32009 VersionNotSupportedError; un mismo agente puede listar en supportedInterfaces interfaces con distintos protocolVersion para que 0.3 y 1.0 convivan. La migración oficial tiene tres fases: primero poder analizar ambos formatos, luego emitir 1.0 y leer 0.3, y finalmente quedarse solo con 1.0. Atlassian Forge y MuleSoft ya han publicado guías de migración de 0.3 a 1.0, lo que muestra que alguien está pagando de verdad el coste de los cambios incompatibles.

La semántica de las tareas tiene detalles que solo se descubren leyendo la especificación completa. El taskId siempre lo genera el servidor; si el cliente aporta el contextId, el agente solo puede aceptarlo o rechazarlo, no generar otro; si taskId y contextId no concuerdan, el agente MUST rechazarlo. Enviar mensajes a una tarea en cualquiera de los cuatro estados terminales (COMPLETED, FAILED, CANCELED, REJECTED) devuelve UnsupportedOperationError; para continuar hay que abrir una tarea nueva en el mismo context y enlazarla con la original mediante referenceTaskIds. La máquina de estados tiene dos estados de «interrupción», TASK_STATE_INPUT_REQUIRED y TASK_STATE_AUTH_REQUIRED, y un SendMessage bloqueante también retorna al llegar a un estado de interrupción.

Las garantías del streaming y de las notificaciones push son más débiles de lo que la mayoría cree. En 1.0 se eliminó el indicador final de TaskStatusUpdateEvent y ahora el «cierre de la conexión» señala el fin del stream, de modo que, para el cliente, una desconexión a mitad de tarea y una tarea completada se ven igual: hay que volver a llamar a GetTask o SubscribeToTask para distinguirlas; la especificación tampoco tiene un mecanismo de reanudación por ID de evento, que figura como tema #1986 de v1.1. La notificación push envía un StreamResponse por HTTP POST al webhook del cliente, con Content-Type application/a2a+json; la especificación solo exige que el agente intente el envío al menos una vez, con un tiempo de espera que SHOULD rondar los 10–30 segundos, y el receptor SHOULD procesarlo de forma idempotente y MUST verificar el taskId. Dicho de otro modo, el push es «al menos una vez, sin orden garantizado y con payload sin firma»; esta conclusión es una inferencia a partir de la especificación. La idempotencia también está a medias: SendMessage «puede» deduplicar por messageId, pero no está obligado.

Hay dos contradicciones entre fuentes sobre fechas y cantidades. Fecha de lanzamiento de v1.0: el CHANGELOG indica 2026-03-12, un artículo de revisión (arXiv:2507.10644 v4) indica enero de 2026 y el comunicado del primer aniversario de la Linux Foundation solo dice que v1.0 es la primera versión estable, sin fecha; este artículo adopta el CHANGELOG, que es la fuente primaria. Número de SDK: en 2026-04 la Linux Foundation habló de 5 lenguajes «production-ready», mientras que el anuncio oficial de A2A enumera 6 (Python, Go, Java, JS, .NET y Rust), aunque el SDK de Rust probado en detalle es una versión de la comunidad.

Durante el último año se ha oído a menudo que «como MCP añadió Tasks, A2A ya no hace falta», pero la versión 2026-07-28 de MCP va justo en sentido contrario. La versión 2025-11-25 de MCP sí incorporó Tasks experimentales (SEP-1686) para seguir solicitudes de larga duración, hacer sondeo y recuperar resultados más tarde, con estados (working, input_required, completed, failed, cancelled) que se corresponden casi uno a uno con los de A2A. Sin embargo, la versión 2026-07-28 eliminó la session y el handshake initialize y convirtió MCP en un protocolo sin estado (SEP-2567, SEP-2575), sacó Tasks del núcleo como extensión oficial io.modelcontextprotocol/tasks (SEP-2663), sustituyó las solicitudes iniciadas por el servidor por MRTR (InputRequiredResult junto con los inputResponses adjuntos al reenviar) (SEP-2322) y marcó Sampling, Roots y Logging como deprecated (SEP-2577).

Estos cambios significan que los mantenedores de MCP renunciaron deliberadamente a la vía agéntica de «que el servidor tome prestado el razonamiento del LLM del llamador»; esto es una inferencia. Si un servidor MCP quiere razonar por sí mismo tiene que traer su propio modelo, y en ese punto ya es en realidad un agente opaco con apariencia de herramienta. La Task de MCP resuelve «la recuperación diferida de una llamada larga a una herramienta», mientras que la Task de A2A resuelve «una colaboración de varias rondas en la que ambas partes pueden hacer preguntas», además del descubrimiento por Agent Card, la declaración de habilidades y el streaming de artifacts. También hay un caso de fallo en sentido inverso: si consultas deterministas como cotizar precios o consultar tipos arancelarios se fuerzan al ciclo de vida Task, Message y Artifact, aumentan la latencia y el coste de implementación, y el LLM del llamador no recibe el schema detallado de la herramienta; esto también es una inferencia. Las notas de investigación no encontraron registros reales de incidentes de «fallar por usar MCP para agente a agente» ni de «fallar por envolver herramientas con A2A».

En cuanto a adopción, además del número de topics en GitHub, una comparación no sistemática de PyPI muestra unos 10,9 millones de descargas del SDK de A2A frente a unos 257 millones del SDK de MCP. Fuentes secundarias señalan que los endpoints UCP de Shopify usan MCP como capa de transporte, es decir, los principales agentes de comercio se conectan por MCP. En cuanto a las plataformas en la nube: AWS AgentCore Runtime permite desplegar servidores A2A (JSON-RPC, POST /, puerto 9000, OAuth 2.0 o SigV4); el soporte de A2A en Microsoft Foundry entró en public preview en junio de 2026; Google Agent Registry lee las tarjetas well-known, pero el descubrimiento automático se limita al mismo proyecto. Entre los principales proveedores de modelos revisados en las notas de investigación, Anthropic no tiene por ahora soporte nativo de A2A, y el issue #104852 relacionado con Claude Code no se abrió hasta finales de octubre de 2026.

En la práctica, la elección es sencilla: si quieres que un asistente de IA invoque tus funciones deterministas (cotizaciones, consulta de tipos arancelarios, seguimiento de envíos), usa MCP; solo necesitas A2A cuando dos agentes que razonan cada uno por su cuenta y pertenecen a organizaciones distintas deben colaborar en varias rondas. El MCP público de HowBridge pertenece al primer caso; para conectarlo, consulta el tutorial de MCP de consolidación del sitio.

La Agent Card de A2A declara en securitySchemes uno de cinco esquemas de autenticación: API Key, HTTP Auth, OAuth2, OIDC y mTLS. La v1.0 eliminó los flujos implicit y password de OAuth, añadió Device Code y recomienda que todos los clientes usen PKCE. La especificación exige que el servidor «MUST authenticate every incoming request», pero la autorización es implementation-specific y las credenciales deben obtenerse por un canal fuera de banda (out-of-band); cuando una tarea entra en el estado AUTH_REQUIRED, la especificación señala expresamente que «Agents MUST NOT treat the state transition alone as authorization». La sección 13, «Consideraciones de seguridad», no menciona en absoluto prompt injection, delegación o token exchange ni OpenTelemetry, y tampoco incluye requisitos específicos de aislamiento entre tenants. Un análisis de Semgrep de la época de v0.3 señaló que A2A «supports but does not enforce Agent Card signing», que la duración y el scope de los tokens no están limitados por el protocolo y que una misma tarea puede tener varios streams en paralelo, de modo que un token de session robado puede escuchar en silencio el stream de la víctima.

Aunque la Agent Card esté firmada, hoy no está garantizado que pueda verificarse entre SDK distintos. El método de la especificación consiste en normalizar primero la tarjeta según RFC 8785 (JCS), excluyendo el campo signatures, y después aplicar JWS; el protected header MUST incluir alg y kid. El issue #2122 (abierto el 2026-08-10 y sin cerrar a 2026-10-31) documenta diferencias medidas: a2a-python 1.1.2 y @a2a-js/sdk 1.0.1 producen bytes normalizados distintos; Python escapa los caracteres no ASCII como \uXXXX, ordena por code point en lugar de por unidades UTF-16 y escribe los números como 1e-06, mientras que ECMAScript escribe 0.000001; la especificación exige que los campos REQUIRED aparezcan aunque tengan su valor por defecto, pero proto3 no tiene el concepto de presence y descarta description: "" y skills: []; además, typ es ambiguo. El PR #2319 corrigió los ejemplos de la especificación, pero la salida de a2a-go sigue siendo distinta. Otra limitación es que una firma verificada solo prueba que la tarjeta no fue alterada, no la identidad de quien la emite; la comunidad también ha señalado que la norma no tiene ningún mecanismo para vincular la tarjeta al entorno de ejecución que realmente hace la llamada.

Algunos ataques funcionan aun cumpliendo plenamente la especificación. A2ABreak (arXiv:2609.10871, v3 2026-10-24) usó un LLM para extraer de la especificación en lenguaje natural 37 estados, 76 transiciones y 929 enunciados formalizados, y encontró 11 vulnerabilidades nuevas, todas explotables «sin ningún defecto de implementación, por un adversario que cumple la norma»; por ejemplo, la inyección de context entre clientes por la falta de protección del context identifier, la pérdida de identidad tras varios saltos en la cadena de delegación y agentes que declaran capacidades no verificadas. Un estudio sobre colisiones de nombres (arXiv:2609.27624) señala que la norma define name como «human-readable metadata, not as a stable identity» sin establecer reglas para las colisiones; de las 7 implementaciones de código abierto que siguió el autor, 6 integraciones de tipo cliente enviarían las solicitudes a un endpoint controlado por el atacante, y el autor lo califica como una clase recurrente de vulnerabilidad de implementación, no como una vulnerabilidad general del protocolo. La prueba de concepto de session smuggling de Unit 42, de Palo Alto Networks, hecha con Google ADK, mostró cómo un agente malicioso usaba «preguntas de aclaración» para sonsacar las instrucciones del sistema e inducía al cliente a llamar a buy_stock para comprar 10 acciones sin autorización; Unit 42 aclaró que no es una vulnerabilidad del protocolo, que cualquier protocolo con estado y de varias rondas puede verse afectado y que no ha observado explotación en entornos reales. La comunidad también ha informado de que un servidor malicioso puede ocultar instrucciones en los campos description o skills de la Agent Card, que el LLM anfitrión ejecuta como si fueran instrucciones.

La evidencia académica sobre ataques entre agentes también respalda que «la confianza entre agentes no puede darse por supuesta». Triedman et al. (COLM 2025) observaron que contenido web malicioso puede secuestrar el flujo de control de sistemas multiagente; con GPT-4o, la ejecución de código arbitrario tuvo éxito en el 58%–90% de los ensayos. La revisión revisada por pares de Ferrag et al. en ICT Express (2026) recorre desde la prompt injection hasta los ataques a nivel de protocolo, abarcando MCP y A2A.

Los números de CVE de la tabla siguiente se han copiado tal cual de las notas de investigación. Las propias notas advierten que la numeración es inusual y que algunas entradas solo figuran en una única base de datos (por ejemplo, CVE-2026-90790 no tiene un GHSA correspondiente en el repo de a2a-python y solo aparece en OpenCVE). Las consultas de advisories de los repos a2a-js, a2a-go y a2a-dotnet devolvieron resultados vacíos, pero puede deberse a falta de permisos y no implica necesariamente que no haya vulnerabilidades. De esta tabla se extraen tres lecciones, que son inferencias: primera, la Agent Card es una entrada que el atacante puede controlar, hasta el punto de que la otra parte puede decidir el nombre de una cabecera; segunda, la norma solo dice «SHOULD validar la URL del webhook», y por eso los SDK de dos lenguajes sufrieron SSRF; tercera, la norma dice que «la autorización la decide la implementación», y el SDK de Java más popular no aplicaba autorización por defecto, cuyo parche además fue eludido por diferencias de la plataforma Android.

El problema de la identidad de los agentes se está dividiendo, fuera de A2A, en tres capas. La primera es la identidad de la carga de trabajo, que responde a «qué programa es este»: los autores de draft-klrc-aiagent-auth proceden de empresas como Amazon, Zscaler, Ping Identity y OpenAI; el borrador fue adoptado por el grupo de trabajo WIMSE del IETF y sustituido por draft-ietf-wimse-aims, y su enfoque es aplicar la familia existente de WIMSE y OAuth 2.0, «sin inventar un protocolo nuevo». La segunda es la autorización y la delegación, que responde a «en nombre de quién y qué puede hacer»: el ejemplo de Ping Identity registra toda la ruta de delegación con el claim act del token exchange de RFC 8693 y limita el siguiente salto con may_act; pero RFC 8693 se diseñó originalmente para intercambios entre servidores «después de que el consentimiento ya se ha producido», y no cubre de forma nativa el consentimiento del usuario hacia un agente concreto.

La tercera capa es la identidad verificable de cara al exterior, que responde a «cómo puede confiar en él un desconocido». Cloudflare Web Bot Auth firma las solicitudes HTTP con Ed25519 y RFC 9421, pero Cloudflare no verifica por ahora el nonce, y la protección contra la reproducción se basa sobre todo en una validez corta de alrededor de 1 minuto; el borrador ANS v2 valida el dominio con ACME y define tres niveles: Bronze, Silver (con DANE) y Gold (con registro de transparencia SCITT). A2A solo aborda la firma de tarjetas de esta capa, y además esa firma es opcional. Los productos comerciales ya se han adelantado: Okta Agent SSO se lanzó oficialmente el 2026-08-24 y usa ID-JAG; Microsoft Entra Agent ID no admite ID-JAG de forma nativa y las fuentes discrepan sobre su fecha de disponibilidad general (2026-04 o 2026-05). Por eso, al usar A2A entre empresas, lo más probable es que cada parte tenga que convertir tokens en su propia frontera; esto es una inferencia.

Los gobiernos también están intentando cubrir este vacío. El CAISI del NIST de EE. UU. anunció el 2026-02-17 la AI Agent Standards Initiative, con tres pilares: estándares liderados por la industria, protocolos de código abierto liderados por la comunidad e investigación sobre seguridad e identidad de agentes; sin embargo, la página de la iniciativa solo habla en términos genéricos como «interoperable agent protocols» y no nombra A2A ni MCP. El proyecto «Software and AI Agent Identity and Authorization» del NCCoE del NIST publicó el 2026-09-29 un resumen de comentarios sobre su documento conceptual, con más de 600 entidades o personas participantes. La entrada de blog del NIST del 2026-10-27, «Design Tenets for Agent Identity Management Systems», propone 10 principios de diseño, entre ellos que los agentes tengan identidad propia, vinculada a quien los inicia y con permisos que se reduzcan en cada nivel de delegación; mínimo privilegio; autorizaciones de corta duración y revocables; intervención humana activada según el riesgo; mandates firmados que delimiten el alcance de las acciones, y registros inalterables. Se trata de una entrada de blog, no de un estándar formal.

La investigación académica va en la misma dirección. South et al. proponen ampliar OAuth 2.0/OIDC con credenciales específicas para agentes y establecer cadenas de delegación auditables; una versión de posición del mismo trabajo se incluyó en el ICML 2025 Position Paper Track. Chan et al. defienden en FAccT 2024 tres tipos de medidas para aumentar la visibilidad de los agentes: identificadores de agente, monitorización en tiempo real y registros de actividad.

AP2 ya no es la versión que se recuerda de 2025. La v0.2.0 cambió el mecanismo a Checkout Mandate y Payment Mandate, cada uno con dos fases, open y closed, implementados con SD-JWT; el open mandate guarda la clave pública del agente en el claim cnf. La novedad principal es el flujo Human-Not-Present: el usuario firma primero el open mandate con su propia clave en una interfaz de confianza y fija las restricciones; después, el agente firma el closed mandate con su clave de agente, y ambos quedan vinculados mediante sd_hash; el comercio o el proveedor de credenciales puede devolver unresolved_constraint para devolver el flujo a «persona presente». La especificación también recomienda que el comercio firme el Checkout JWT con firmas no deterministas (ECDSA) y no con Ed25519, para prevenir ataques de tablas arcoíris. Lo más importante es que la especificación de AP2 deja fuera de alcance (out of scope) la gestión de disputas, así como su conservación y consulta, y solo se compromete a ofrecer un rastro de auditoría criptográfico no repudiable. Las notas de investigación observan además que el método de extensión que recomienda la especificación de AP2 son los extension points de UCP, mientras que A2A ni siquiera se trata en el cuerpo de la especificación; el posicionamiento de AP2 se está desplazando de «extensión de A2A» a «capa de seguridad dentro de los protocolos de comercio»; esto es una inferencia.

Las extensiones de pago se acoplan a A2A mediante el propio mecanismo de extension de A2A: se declaran en AgentCapabilities como AgentExtension (uri, description, required, params) y el cliente solicita activarlas con la cabecera A2A-Extensions; una extensión no puede modificar las estructuras de datos del núcleo ni añadir valores de enum, solo puede operar mediante metadata, los cambios incompatibles exigen una URI nueva y, ante una versión no admitida, «MUST NOT fall back». a2a-x402 (spec v0.1) es una extensión de este tipo: el comercio envía payment-required, el cliente firma y responde payment-submitted, y el comercio, tras liquidar en cadena, responde payment-completed.

El número de transacciones de x402 procede sobre todo de volumen inflado artificialmente. Chainalysis contabiliza más de 100 millones de transacciones x402 acumuladas en la cadena Base hasta el primer trimestre de 2026, pero el pico del cuarto trimestre de 2025 estuvo «impulsado en su mayor parte por el meme coin farming», y la retención semanal cayó del 87% al 5%. Coinbase afirmó a finales de abril de 2026 unos 165 millones de transacciones y un acumulado de unos US$ 50 millones, lo cual es una alegación del proveedor; Artemis, en cambio, considera que más del 95% son señales del protocolo o pruebas; otro sitio de seguimiento estima el volumen comercial real en unos US$ 28.000 al día.

Lo que hacen en la práctica las redes de tarjetas y las plataformas es «aceptar varios protocolos y usar la autenticación reforzada con la persona presente como válvula de seguridad». En marzo de 2026, OpenAI devolvió el Instant Checkout de ChatGPT al modelo de Apps de los comercios; según su portavoz, «Instant Checkout is moving to Apps». Visa anunció el 2026-07-02 que en Europa ya hay agentes que han completado compras reales, con más de 30 entidades emisoras colaboradoras, y todas las transacciones usaron Payment Passkeys para cumplir la autenticación reforzada de clientes (SCA). El marco de responsabilidad sigue vacío: Chargebacks911 advierte que la infraestructura de disputas y responsabilidad está «largely unaddressed»; Taylor Wessing analiza que, en el marco de la UE, una compra de un agente que supere las condiciones fijadas por el cliente se consideraría, en principio, una operación no autorizada; Ant International, Visa y Mastercard no empezaron hasta el 2026-09-10 a explorar un marco interoperable de Know-Your-Agent. En la UE, PSD3/PSR solo ha llegado a la posición en primera lectura aprobada por el Consejo el 2026-10-29 y aún no se ha publicado en el Official Journal; una búsqueda por palabras clave en la exposición de motivos del PSR del Consejo no encuentra disposiciones sobre IA ni agentes autónomos; la CFPB de EE. UU. tampoco tiene orientaciones sobre pagos de agentes.

La investigación académica señala otro punto ciego. Debi et al. (IEEE IMNS 2026) hicieron pruebas de red team con un agente de compras basado en AP2: la prompt injection indirecta y directa permitió manipular el orden de los productos y extraer datos sensibles del usuario, lo que muestra que los mandates firmados no protegen el razonamiento previo a la firma; Jiang et al. (arXiv:2609.00060) analizaron formalmente x402, MPP, ACP y AP2 con Tamarin y señalaron las dependencias de seguridad que surgen al repartirse la intención, los permisos de delegación y la liquidación entre varias partes. La agentificación del sector logístico va hoy por MCP: el servidor MCP de Flexport permite que el asistente de IA del cliente reserve espacio de carga con tarifas pactadas y obtenga un booking ID. Las notas de investigación no encontraron ningún caso de liquidación de fletes con AP2 o x402.

El comunicado del primer aniversario de la Linux Foundation, del 2026-04-09, dice que A2A cuenta con más de 150 organizaciones de apoyo y con despliegues en producción en cadena de suministro, finanzas, seguros y operaciones de TI; se trata de una alegación del proveedor: el comunicado no nombra a ningún usuario ni aporta procesos ni indicadores de resultados. Los ejemplos más citados, el artículo de Microsoft Agent Framework para .NET y el codelab de concierge de compras de Google, son ejemplos de código y no informes de despliegue. Tyson Foods se presenta a menudo como caso de A2A en la cadena de suministro, pero apis.io le asigna una puntuación de 0/8 en su A2A Agent Card, y lo que ofrece a sus socios comerciales siguen siendo EDI y API.

La refutación más directa son las pruebas reales. En abril de 2026, un autor tomó de registros públicos 50 agentes que afirmaban admitir A2A: solo unos 0–2 ofrecían una tarjeta válida en la ruta well-known y 0 respondieron correctamente a una task; el mismo autor envió el 2026-09-09 24 solicitudes a 12 organizaciones y el 2026-10-27 36 solicitudes a 18 organizaciones, y en ambos casos obtuvo 0 tarjetas. La muestra la eligió el autor, no es un censo, pero la tendencia es coherente. Lo que realmente funciona es la interoperabilidad dentro de una misma plataforma en la nube: AWS AgentCore, Microsoft Foundry y Google Agent Registry.

La evidencia sobre las propias arquitecturas multiagente también es desfavorable para A2A entre organizaciones. MAST (NeurIPS 2025 Datasets & Benchmarks Track) analizó 1.642 trazas de ejecución e identificó 14 modos de fallo agrupados en tres categorías: diseño del sistema, desalineación entre agentes y verificación de tareas; las tasas de fallo de los 7 sistemas multiagente de código abierto más avanzados del estudio oscilaban entre el 41% y el 86,7% (los autores advierten que no se pueden comparar directamente benchmarks distintos). «Towards a Science of Scaling Agent Systems», de autores de Google Research, el MIT y otros, probó 180 configuraciones en sus versiones v1/v2 y en la del blog de Google: los multiagentes independientes amplifican los errores 17,2 veces y los de coordinación central 4,4 veces, y en tareas de razonamiento secuencial todas las variantes multiagente empeoraron entre un 39% y un 70%; la v3 del 2026-04-08 se amplió a 260 configuraciones y 6 benchmarks y mantuvo las conclusiones de 17,2 y 4,4 veces. El blog de ingeniería de Anthropic (no es un artículo revisado por pares) explica que su sistema de investigación multiagente supera en un 90,2% a Claude Opus 4 como agente único, pero consume unas 15 veces más tokens que una conversación normal, y señala como poco adecuados los dominios que «requieren que todos los agentes compartan el mismo contexto o en los que hay muchas dependencias entre agentes». A2A entre organizaciones reúne justamente todas estas condiciones desfavorables: las partes no comparten contexto, no hay un verificador común y los procesos comerciales (cotizar → pedir → pagar → enviar) son secuenciales; esto es una inferencia.

En ingeniería hay aún más vacíos que en la especificación. Cuando A2A delega en el siguiente agente, la traza se rompe: el SDK de Python solo crea spans locales y no hay una forma estándar de propagar el W3C Trace Context entre agentes (Issue #2103). El SDK de Rust de la comunidad informó de 7 fallos en el TCK que, tras compararlos, se atribuyeron a defectos del propio conjunto de pruebas; el mismo informe indica que los SDK de JS, Go y Java pasan 21/21 en ambos bindings. El tráfico de agentes en el lado del consumidor también es aún pequeño: HUMAN Security calcula que el tráfico de agentes creció un 7.851% interanual en 2025, pero solo el 2,3% se produjo en páginas de pago; fuentes secundarias que citan datos de Cloudflare Radar de agosto de 2026 indican que los bots de IA suponen alrededor del 7% de las solicitudes HTML, y de ellos las «acciones en tiempo real en nombre del usuario» solo el 5,8%; al multiplicar ambos se obtiene alrededor del 0,4%, cálculo que es una inferencia aún no confirmada con los datos originales. Akamai, por su parte, advierte que los sitios de comercio electrónico solo monitorizan más del 90% de los bots de IA, mientras aumenta la actividad de agentes fraudulentos. Las notas de investigación no encontraron pruebas de que agentes personales como ChatGPT, Gemini o Claude llamen por A2A a agentes de empresas en general, aunque esto solo indica ausencia de evidencia en contra, no una confirmación oficial.

Las entrevistas de gobiernos y organismos internacionales muestran, en cambio, que la demanda es real. La página 16 de OECD Artificial Intelligence Papers No. 65 recoge que los profesionales entrevistados prefieren protocolos abiertos y señalan que los protocolos de comunicación de agente a agente como A2A son un impulsor importante de la coordinación multiagente, a la vez que temen quedar atados al ecosistema de un único proveedor.

Taiwán: la Ley Básica de Inteligencia Artificial tiene 20 artículos. El artículo 3 define la inteligencia artificial como «sistemas con capacidad de funcionamiento autónomo», lo que puede abarcar a los agentes de IA, aunque la palabra «agente» no aparece en el texto; el artículo 4 enumera siete principios, entre ellos la autonomía y supervisión humanas, la transparencia y explicabilidad, y la rendición de cuentas; el artículo 16 encarga al Ministerio de Asuntos Digitales impulsar un marco de clasificación de riesgos alineado con los estándares internacionales; el artículo 17 exige al gobierno definir la atribución de responsabilidades y las condiciones de imputación para la IA de alto riesgo, y establecer mecanismos de recurso, compensación o seguro; el artículo 18 exige a los organismos completar los ajustes normativos correspondientes en los dos años siguientes a la entrada en vigor. Con base en el artículo 16, el Ministerio de Asuntos Digitales publicó el 115-07-07 el Marco de Clasificación de Riesgos de la Inteligencia Artificial v1.0 (oficio de Estrategia Digital n.º 1150015933, en vigor desde su publicación), cuyo tipo de riesgo B6, «comportamiento de agentes autónomos de IA fuera de lo autorizado», dice: «Los sistemas multiagente tienen más probabilidades de que los agentes se activen entre sí y produzcan reacciones en cadena que ni desarrolladores ni usuarios previeron, lo que dificulta que los humanos intervengan y corrijan a tiempo». Las directrices sobre IA generativa en instituciones médicas, comunicadas por el Ministerio de Salud y Bienestar el 115-05-29, establecen explícitamente que los sistemas de agentes de IA «aún no se incluyen entre los sujetos de aplicación de estas directrices».

Las leyes vigentes de Taiwán también se aplican a los escenarios con agentes. El artículo 4 de la Ley de Protección de Datos Personales establece que quien recopila, trata o utiliza datos personales por cuenta de otro se considera, dentro del ámbito de esta ley, equivalente a la entidad que encarga; por tanto, confiar datos personales a un agente no exime de responsabilidad por «ser la IA la que lo hace»; el artículo 21 regula las restricciones a las transferencias internacionales. Hay que tener en cuenta que varios artículos modificados el 114-11-11 (incluida la nueva versión del artículo 21 y el nuevo artículo 20-1) ya se han promulgado pero aún no han entrado en vigor; la fecha de entrada en vigor la fijará el Yuan Ejecutivo. La Ley de Firma Electrónica no menciona la IA ni los agentes; si una firma realizada por un agente en nombre de alguien puede presumirse firma de la propia persona no está previsto expresamente en la ley, y este artículo no puede confirmarlo.

China: la Administración Estatal de Regulación del Mercado y la Administración de Normalización de China, mediante el anuncio de normas nacionales n.º 22 de 2026, aprobaron y publicaron el 2026-05-22 la serie GB/Z 185.1–185.7-2026, «Inteligencia artificial — Interconexión de agentes inteligentes», compuesta por 7 documentos técnicos orientativos (arquitectura general, código de identidad, gestión de identidad, descripción de agentes, descubrimiento de agentes, interacción entre agentes e invocación de herramientas por agentes); la plataforma nacional de servicio público de información sobre normas indica su estado como «vigente», el texto completo se hizo público el 2026-06-18 y la Administración Estatal de Regulación del Mercado celebró además una rueda de prensa temática el 2026-06-26. El nombre de protocolo que usan los documentos oficiales es AIP (protocolo de interconexión de agentes inteligentes); ninguna de las páginas oficiales consultadas menciona A2A ni MCP, y no está demostrado si son compatibles. Las Opiniones de Implementación sobre la Aplicación Normalizada y el Desarrollo Innovador de los Agentes Inteligentes, emitidas conjuntamente el 2026-05-08 por la Administración del Ciberespacio de China, la Comisión Nacional de Desarrollo y Reforma y el Ministerio de Industria y Tecnología de la Información, vinculan en un solo paquete la promoción de AIP, una plataforma de registro de agentes y la identidad digital de los agentes, y exigen que «las operaciones ejecutadas por agentes no excedan el ámbito autorizado por el usuario». Esta vía difiere de la de la comunidad A2A, donde «no hay un registro central oficial».

UE: la AI Act (Regulation (EU) 2024/1689) entró en vigor el 2024-08-01; las obligaciones de los modelos de IA de uso general se aplican desde el 2025-08-02, y la aplicación general y las obligaciones de transparencia desde el 2026-08-02; las obligaciones de alto riesgo ya se han aplazado mediante el Regulation (EU) 2026/1744 (publicado en el Official Journal el 2026-07-24): las del anexo III hasta el 2027-12-02 y las del anexo I hasta el 2028-08-02. En cuanto a PSD3 y PSR, el Consejo aprobó su posición en primera lectura el 2026-10-29; falta la segunda lectura del Parlamento Europeo y no se han publicado en el Official Journal.

EE. UU., Singapur y Reino Unido: CISA, la NSA y otras agencias de los Cinco Ojos publicaron el 2026-04-30/05-01 «Careful Adoption of Agentic AI Services», que recomienda limitar los permisos de acceso y empezar por casos de uso de bajo riesgo y no sensibles; la CFPB de EE. UU. no tiene orientaciones específicas sobre pagos de agentes, y la propuesta de norma interpretativa relacionada de 2025 se retiró el 2025-05-15. El Model AI Governance Framework for Agentic AI v1.5 de la IMDA de Singapur (publicado el 2026-05-20 y actualizado el 06-05) nombra directamente en la sección 1.1.1 a A2A para la comunicación entre agentes y a MCP para la comunicación entre agentes y herramientas, y señala que la delegación recursiva y la identidad entre organizaciones son las carencias actuales. La guía de la CMA del Reino Unido publicada el 2026-03-09 (actualizada el 10-30) dice que «if an AI agent you use does something illegal, you are responsible», es decir, que la empresa responde de los actos ilegales de los agentes que utiliza; la consulta pública de la ICO del Reino Unido sobre IA agéntica cierra el 2026-11-20.

El issue #1942 agrupó 41 issues en los ocho temas de v1.1; la memoria de los agentes entre tareas (#893) queda fuera de este seguimiento. Más que la lista de temas, lo que mejor indica el rumbo son los issues con más comentarios: #1672, verificación de la identidad del agente en la Agent Card (unos 658 comentarios); #1829, firma de mensajes con Ed25519 y RFC 9421; #2028, delegación con actor-chain; #2121, propagación de costes y presupuestos; y #1815, uso de HTTP 402 para indicar «pago requerido». Todos son problemas de confianza y de comercio; junto con el nuevo proceso de gobernanza de extensiones, las notas de investigación consideran más probable que lleguen como extensiones y no como modificaciones del núcleo de la especificación; esto es una inferencia.

Hoy no existe una respuesta abierta y desplegada a «cómo encuentra un agente personal al agente de una empresa». La documentación oficial de A2A dice claramente que los registros curados quedan fuera del alcance de A2A; la propuesta de Agent Registry de la Discussion #741 lleva mucho tiempo estancada, y los revisores cuestionan la premisa de que «sean los propios proveedores quienes gestionen sus entradas». Para encontrar agentes a partir de un dominio, el IETF tiene cuatro borradores individuales que compiten entre sí: DNS-AID (registros SVCB que apuntan a /.well-known/agent-card.json), AID (consulta de registros TXT _agent), ADP y DAN, y ninguno ha sido adoptado por un grupo de trabajo; el borrador landscape de julio de 2026 también señala que el espacio de nombres requiere coordinación. Por el lado de MCP, el MCP Registry sigue en versión de vista previa desde septiembre de 2025.

Tampoco hay un marco para la auditoría y la responsabilidad entre organizaciones. La especificación de A2A solo incluye requisitos de nivel SHOULD sobre el registro de fallos de autenticación y la limitación de tasa, y las fuentes se contradicen sobre el grado de estabilidad de las convenciones semánticas GenAI de OpenTelemetry. Con las herramientas actuales, la unidad mínima de auditoría que se puede conservar es, probablemente: el taskId y el contextId del propio lado, la huella de la firma de la Agent Card de la otra parte y la cadena de delegación act del token que presenta; cada parte los guarda por su cuenta y se concilian después; esto es una inferencia. Las notas de investigación tampoco encontraron ningún estudio empírico de denial-of-wallet cuyo objetivo sea «agotar el presupuesto de LLM de la otra parte».

La situación actual de A2A se parece mucho a la de HTTP en sus inicios: el formato ya está estandarizado, pero cada uno tiene que añadir por su cuenta la capa de confianza; la diferencia es que esta vez la parte llamada razona por sí misma y la otra parte puede llegar a convencerla. Por eso el cuello de botella no está en la ingeniería, sino en «quién responde del comportamiento del agente», y esa cuestión está hoy repartida entre el IETF (identidad), la FIDO Alliance (intención de pago), las redes de tarjetas (disputas) y los reguladores de cada país, fuera del alcance del TSC de A2A. De ahí se infiere que, en los próximos años, la forma más probable de interoperabilidad entre agentes de distintas empresas será «una envoltura A2A alrededor de llamadas a herramientas deterministas»: la parte llamada parece un agente, pero por dentro es una API, y el razonamiento real solo ocurre dentro de la propia frontera de confianza.

Las orientaciones gubernamentales van en la misma dirección. CISA, la NSA y otras agencias de los Cinco Ojos recomiendan empezar por casos de uso de bajo riesgo y no sensibles y limitar los permisos de acceso; el marco de la IMDA de Singapur sitúa como aspectos centrales «que las personas asuman una responsabilidad efectiva» y los controles técnicos; el Ministerio de Asuntos Digitales de Taiwán clasifica como riesgo B6 las reacciones en cadena por activación mutua entre agentes; y la CMA del Reino Unido afirma expresamente que la empresa responde de los actos ilegales de los agentes que utiliza.

La tabla siguiente clasifica las opciones de adopción para una empresa general según la solidez de la evidencia. «Hacer» significa que, con la evidencia actual, el riesgo es bajo y el beneficio claro; «Se puede hacer» significa que el coste es bajo pero no hay casos medidos; «Aplazar» y «No hacer» incluyen su motivo y se reevaluarán cuando aparezcan las condiciones desencadenantes.

Las consultas centrales del comercio electrónico transfronterizo y la logística —cuánto cuesta el envío, cuántos impuestos se pagan, cuál es la clasificación arancelaria de un producto y qué requisitos de importación tiene— son de por sí cálculos deterministas, justo el tipo de servicio que más necesitan los agentes externos y en el que menos se equivocan. La experiencia del blog de ingeniería de Anthropic es que reescribir las descripciones de las herramientas redujo un 40% el tiempo de finalización de tareas de los agentes posteriores; la experiencia de OpenAI al devolver Instant Checkout a las Apps de los comercios muestra que, al final, la transacción vuelve al propio proceso del comercio. Por eso, el orden de preparación debería ser: primero, que las páginas web y los datos estructurados sean legibles; después, convertir las herramientas deterministas en MCP; incluir en las respuestas de las herramientas una URL de continuación que devuelva la transacción al propio proceso; y solo al final plantearse una reserva de presencia en A2A.

Una tarjeta A2A de reserva significa publicar una tarjeta en /.well-known/agent-card.json cuyas skills correspondan a las herramientas deterministas existentes de cotización, impuestos o procesos, y que por detrás llame directamente a código sin ejecutar ningún LLM. Es una opción de bajo coste con «valor de opción», pero hoy no existe ningún caso medido de una pyme que haya obtenido tráfico o ingresos gracias a ello; esto es una inferencia. Si de verdad se abre un endpoint A2A, como mínimo hay que: abrir solo habilidades de solo lectura, no confiar en ningún campo de la tarjeta de la otra parte, rechazar IP privadas en las URL push y registrar taskId, contextId, la identidad del llamador y traceparent.

Lo que hace hoy HowBridge (todo lo siguiente puede comprobarse en la página para desarrolladores de HowBridge): HowBridge ofrece un MCP público sin clave y sin OAuth (https://0523.tw/mcp/public) con 8 herramientas de solo lectura e idempotentes, que cubren la presentación de la marca y los servicios de HowBridge, la estimación del coste de envío de consolidación de China a Taiwán (marítimo exprés/aéreo), la estimación de impuestos de importación de Taiwán, la búsqueda de candidatos de clasificación arancelaria CCC a partir del nombre del producto, los tipos arancelarios y requisitos de importación por código CCC, el recargo por sobredimensión en la entrega dentro de Taiwán, y el proceso de consolidación y las normas de declaración simplificada; admite 120 solicitudes por minuto por IP y ya está inscrito en el MCP Registry oficial (nombre tw.0523/lucky-public); la respuesta de la estimación de envío incluye una URL de continuación (continue_url) para que el usuario siga en el sitio oficial. El MCP para miembros (https://0523.tw/mcp) usa autorización OAuth 2.1 y ofrece 6 herramientas de solo lectura que solo pueden leer las facturas, paquetes, prealertas, liquidaciones de impuestos y declaraciones de importación del propio miembro autorizado, con un límite por defecto de 60 solicitudes por minuto y 5.000 al día. La página para desarrolladores de HowBridge enumera actualmente como puntos de acceso la API de datos de miembros, el MCP para miembros y el MCP público; no hay ningún endpoint A2A, y este artículo no implica que HowBridge ya admita A2A.

Si quieres que un asistente de IA te ayude a estimar el coste de enviar de China a Taiwán, puedes usar directamente en la web la calculadora de envío de consolidación, la calculadora de aranceles de importación y la búsqueda de clasificación arancelaria; las herramientas y el MCP público usan la misma lógica de cálculo, las estimaciones son solo orientativas, el coste de envío final es el de la factura emitida tras medir el paquete al ingresar en almacén y los impuestos son los que determine la aduana.