A2A entra en AAIF para que agentes de distintos proveedores puedan descubrirse y trabajar entre sí
Fecha efectiva / observada:
Qué ha cambiado
Agent2Agent (A2A), el protocolo abierto para que agentes de IA se descubran, intercambien tareas y colaboren entre distintos frameworks y proveedores, ha pasado a estar alojado por la Agentic AI Foundation (AAIF), bajo Linux Foundation. QUÉ HA CAMBIADO El 17 de agosto de 2026, AAIF anunció que A2A se incorpora como proyecto alojado de la fundación. El cambio afecta principalmente a gobernanza y hogar institucional. A2A ya existía y había alcanzado una versión estable antes de entrar en AAIF. AAIF afirma que el protocolo está respaldado por más de 150 organizaciones y que ya se usa en producción en ámbitos como cadena de suministro, servicios financieros y plataformas móviles. Estas cifras proceden de la propia fundación y deben seguir contrastándose con casos públicos y verificables. A2A YA HABÍA LLEGADO A 1.0 A2A publicó su versión 1.0 el 12 de marzo de 2026. La comunidad la presentó como la primera versión estable y orientada a producción del protocolo. Entre sus cambios principales están: - negociación de versiones; - soporte para varios transportes; - multi-tenancy; - Agent Cards firmadas; - mejoras de seguridad; - compatibilidad progresiva con versiones anteriores; - soporte para polling, streaming y webhooks. El changelog del proyecto registra además la versión 1.0.1 el 26 de mayo de 2026 con correcciones posteriores. QUÉ PROBLEMA INTENTA RESOLVER Cuando dos agentes pertenecen al mismo framework, coordinarlos puede ser relativamente sencillo. El problema aparece cuando: - fueron construidos con frameworks diferentes; - pertenecen a empresas distintas; - viven en plataformas diferentes; - necesitan delegarse trabajo sin conocer la implementación interna del otro. Sin un protocolo común, cada pareja de agentes puede necesitar una integración propia. A2A intenta ofrecer un contrato compartido para evitar ese acoplamiento. CÓMO SE DESCUBRE UN AGENTE A2A utiliza una Agent Card para describir públicamente información como: - nombre del agente; - capacidades; - habilidades; - interfaces disponibles; - protocolos soportados; - requisitos de autenticación; - documentación. La especificación define una ubicación estándar: https://dominio/.well-known/agent-card.json Un cliente puede consultar esa tarjeta antes de decidir cómo comunicarse con el agente. En A2A 1.0, una Agent Card puede firmarse digitalmente mediante JWS para que el cliente compruebe su autenticidad e integridad. IMPORTANTE: una Agent Card firmada demuestra que la tarjeta no ha sido alterada y puede vincularla con una clave determinada. No demuestra por sí sola que el agente sea seguro, competente o que sus respuestas sean correctas. QUÉ PUEDEN HACER DOS AGENTES Con A2A, un agente puede conocer las capacidades del otro y enviarle trabajo utilizando una estructura común. Dependiendo del caso, el resultado puede recibirse mediante: - respuesta directa; - polling; - streaming; - webhooks. El protocolo intenta mantener separada la interfaz pública del agente de su implementación interna. El agente receptor no necesita exponer cómo razona, qué framework utiliza o cómo organiza internamente sus herramientas para poder participar. MCP Y A2A NO SON LO MISMO Esta distinción es importante. MCP suele conectar un agente con herramientas, datos y contexto. A2A conecta agentes entre sí. Una arquitectura puede utilizar ambos: MCP → agente ↔ herramienta/contexto A2A → agente ↔ agente No son necesariamente competidores ni uno sustituye al otro. De hecho, el crecimiento simultáneo de MCP y A2A apunta a una arquitectura donde un agente puede usar MCP para trabajar con recursos y A2A para delegar una parte del trabajo a otro agente. QUÉ APORTA LA VERSIÓN 1.0 A2A 1.0 refuerza varios aspectos importantes para despliegues reales. NEGOCIACIÓN DE VERSIONES Un cliente y un servidor pueden acordar la versión compatible sin exigir un corte simultáneo de toda la infraestructura. VARIOS TRANSPORTES El protocolo admite mecanismos como JSON sobre HTTP, gRPC y JSON-RPC. MULTI-TENANCY Un mismo endpoint puede alojar múltiples agentes o tenants con separación lógica. AGENT CARDS FIRMADAS Las tarjetas pueden usar JWS para comprobar autenticidad e integridad. EXTENSIONES El protocolo permite ampliar capacidades sin obligar a introducir cada función nueva dentro del núcleo. INTEGRACIÓN CON INFRAESTRUCTURA WEB A2A intenta funcionar con patrones conocidos de balanceo, gateways, seguridad y observabilidad, en lugar de exigir una infraestructura completamente nueva. LO QUE LA PRODUCCIÓN YA ESTÁ ENSEÑANDO Después de la entrada de A2A en AAIF, se publicó una experiencia de producción de Eon especialmente útil para entender qué partes siguen abiertas. El equipo afirma que volvería a elegir A2A, pero detectó dos necesidades que el protocolo no resolvía de forma suficientemente directa para su caso: 1. IDENTIDAD DE LA PERSONA QUE ORIGINA LA PETICIÓN Cuando un agente delega a otro, no siempre basta con saber qué servicio está llamando. En sistemas con permisos distintos por usuario, también puede importar quién hizo la pregunta originalmente. Eon tuvo que transportar esa identidad mediante una convención propia sobre context_id. El propio equipo advierte de que esto funciona en su entorno porque controla ambos extremos y no debe copiarse ciegamente como si fuera una solución estándar. 2. PROCEDENCIA DE LA RESPUESTA El equipo también necesitaba conservar suficiente información para que otra persona pudiera comprobar después de dónde salió una respuesta. Para cubrir esa necesidad creó una extensión propia. Esto no significa que A2A “no funcione”. Significa que una especificación estable todavía puede encontrar requisitos nuevos cuando se usa en sistemas reales. QUÉ NO RESUELVE A2A POR SÍ SOLO A2A facilita interoperabilidad, pero no convierte automáticamente una red de agentes en confiable. No demuestra por sí solo: - que un agente sea honesto; - que una respuesta sea correcta; - que las herramientas internas sean seguras; - que la autorización entre organizaciones esté bien diseñada; - que la identidad del usuario final viaje correctamente en todos los casos; - que exista procedencia suficiente para auditar cada respuesta; - que no haya prompt injection o manipulación del agente. Es un protocolo de comunicación y coordinación, no una garantía completa de seguridad o verdad. A QUIÉN PUEDE INTERESAR Si desarrollas agentes: A2A puede evitar integraciones específicas con cada framework remoto. Si administras una plataforma: puede permitir que equipos distintos publiquen agentes con una interfaz común. Si trabajas entre organizaciones: puede facilitar delegación sin compartir la implementación interna de cada agente. Si trabajas en seguridad o auditoría: conviene revisar Agent Cards firmadas, autenticación, identidad delegada y procedencia antes de confiar en una topología multi-agente. Si eres usuario normal: su efecto será indirecto. Puede permitir que servicios distintos colaboren detrás de una aplicación, aunque tú no veas el protocolo. QUÉ PUEDES HACER AHORA Si quieres evaluar A2A: 1. Revisa la especificación 1.0 y el changelog. 2. Publica una Agent Card mínima de prueba. 3. Comprueba descubrimiento y negociación de versiones. 4. Prueba interacción con al menos dos implementaciones distintas. 5. Decide si necesitas polling, streaming o webhooks. 6. Revisa cómo transportarás identidad, permisos y procedencia. 7. No confundas una Agent Card firmada con una evaluación completa de confianza. 8. Si utilizas MCP, define claramente qué relación queda agente-herramienta y cuál agente-agente. RECURSOS Anuncio de A2A entrando en AAIF: https://aaif.io/blog/a2a-joins-aaif Anuncio de A2A 1.0: https://github.com/a2aproject/A2A/blob/main/docs/announcing-1.0.md Especificación: https://github.com/a2aproject/A2A/blob/main/docs/specification.md Repositorio: https://github.com/a2aproject/A2A Experiencia real de producción: https://aaif.io/blog/what-we-learned-putting-a2a-into-production QUÉ VIGILARÁ RADARABIERTO RA debe seguir: - evolución de A2A después de entrar en AAIF; - nuevas versiones del protocolo; - compatibilidad real entre implementaciones; - Agent Cards firmadas y gestión de claves; - Technology Compatibility Kit e Inspector; - extensiones para identidad, autorización y procedencia; - integración con MCP y otras piezas del ecosistema de agentes; - casos de producción independientes; - vulnerabilidades y fallos de interoperabilidad; - si el protocolo reduce integraciones propietarias sin crear nuevas dependencias difíciles de auditar. Esta señal debe mantenerse como historia viva. La entrada en AAIF consolida la gobernanza de A2A, pero su valor real dependerá de interoperabilidad demostrada, adopción independiente y de cómo resuelva los problemas que solo aparecen cuando agentes de organizaciones distintas empiezan a trabajar juntos.
Por qué puede importarte
A2A puede reducir integraciones específicas entre agentes de proveedores distintos y convertirse en una capa común para descubrimiento, delegación y seguimiento de tareas. Su relación complementaria con MCP y los problemas reales de identidad y procedencia detectados en producción lo convierten en una pieza relevante para la evolución de sistemas multi-agente abiertos.
Cómo ha evolucionado
Estado actual: actual. Añadiremos los cambios posteriores sin borrar este registro.
Qué todavía no sabemos
AAIF declara más de 150 organizaciones y despliegues en producción, pero RA debe seguir contrastando estas cifras con adopción independiente. La experiencia de Eon sobre identidad y procedencia corresponde a un despliegue concreto y no prueba que todos los usuarios encuentren los mismos límites. A2A 1.0 es estable, pero el ecosistema, sus extensiones y herramientas de compatibilidad siguen evolucionando.
Seguir el contexto
La señal conserva procedencia y relaciones internas para que puedas comprobar el origen y explorar cambios relacionados.
Esta ficha verificable es igual para todos. Puedes indicar si te afecta, si no se entiende, si quieres seguirla o si no te interesa. Para que seguir u ocultar cambie solo tu selección, crea Mi Radar.