A2A entra en la Agentic AI Foundation: los dos protocolos de agentes ya viven bajo el mismo techo neutral
Si estás construyendo o manteniendo un producto con agentes, esta semana ha pasado algo que afecta a tus decisiones de arquitectura: el protocolo A2A (Agent2Agent) de Google se ha movido a la Agentic AI Foundation (AAIF), la fundación de la Linux Foundation donde ya vivía MCP (Model Context Protocol). Por primera vez, los dos estándares que se han impuesto en la capa de agentes —uno para conectar agentes con herramientas, otro para que los agentes hablen entre sí— comparten gobernanza neutral.
La respuesta corta a "¿esto me obliga a cambiar algo hoy?" es no. Pero sí cambia el cálculo de riesgo a la hora de apostar por estos protocolos. Vamos al detalle.
Qué ha pasado exactamente
La noticia la adelantó Axios el 17 de agosto de 2026 y se formalizó en los días siguientes. Google creó A2A en abril de 2025 y lo donó a la Linux Foundation en junio de 2025; ahora lo ha trasladado dentro de la Agentic AI Foundation, la fundación específica de agentes que la Linux Foundation anunció en diciembre de 2025.
La AAIF nació anclada por tres proyectos —MCP (donado por Anthropic), goose (el runtime de agentes de Block) y AGENTS.md (de OpenAI)— y ahora suma A2A como cuarto proyecto. En menos de un año ha pasado de menos de 40 miembros a más de 250, con AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft y OpenAI entre los miembros platino. La gobernanza es de dos niveles: un Governing Board para estrategia y presupuesto, y un comité técnico (TSC) que aprueba proyectos y revisiones.
El titular real no es "hay una fundación más". Es que MCP y A2A dejan de depender de un único vendor y pasan a un comité técnico neutral. MCP, recordemos, creció a más de 10.000 servidores y 97 millones de descargas más rápido de lo que Anthropic podía gobernarlo en solitario.
Qué implica para tu producto
Aquí es donde separamos la señal del ruido. Tres lecturas prácticas:
1. Baja el riesgo de lock-in en la capa de protocolo, no en la de modelo. Que MCP y A2A estén bajo gobernanza neutral te da estabilidad para construir sobre ellos sin miedo a que un vendor cambie las reglas unilateralmente. Pero cuidado con el espejismo: esto no reduce tu dependencia del proveedor de LLM ni del gateway por el que pasan tus tokens. El lock-in que de verdad duele en producción sigue estando en el modelo y en la capa de orquestación, no en el formato del mensaje. Si te preocupa la dependencia de proveedor, el sitio donde mirar es tu gateway de LLM, no el protocolo.
2. MCP y A2A no compiten: resuelven capas distintas. Es el error conceptual más habitual que vemos en las llamadas de discovery. No eliges "uno u otro":
| MCP | A2A | |
|---|---|---|
| Para qué | Conectar un agente con herramientas, datos y sistemas | Que agentes independientes colaboren entre sí |
| Relación | Agente ↔ herramienta (capacidades) | Agente ↔ agente (a través de fronteras de confianza) |
| Madurez | Muy alta: miles de servidores en producción | Menor: adopción real pero más incipiente |
| Lo necesitas si… | Tu agente llama a APIs, bases de datos o servicios internos | Tienes varios agentes de distintos equipos/organizaciones que deben coordinarse |
3. Estándar gobernado ≠ estándar terminado. MCP ya cambió de especificación en julio de 2026 (la versión stateless), y A2A seguirá evolucionando dentro de la AAIF. Una fundación neutral aporta estabilidad de gobierno, pero no congela el protocolo. Si construyes sobre ellos, sigue haciendo falta una capa de abstracción propia para absorber cambios de versión sin reescribir medio backend.
Nuestra recomendación
Posición clara, con matices:
- Adopta MCP con confianza si aún no lo has hecho. Es el estándar de facto para dar herramientas a un agente, está probado en producción y ahora tiene gobierno neutral. Ya no hay excusa de "esperemos a ver si se consolida": se ha consolidado.
- No añadas A2A por FOMO. Si tu caso es un agente + sus herramientas —que es el 80% de los productos que vemos—, A2A no te aporta nada todavía; te añade complejidad. A2A tiene sentido cuando tienes varios agentes autónomos que colaboran, especialmente si cruzan fronteras de confianza entre equipos o empresas. Antes de meterlo, pregúntate si tu problema es de verdad multiagente o si un buen patrón de orquestación dentro de tu propio sistema lo resuelve más barato.
- No reescribas lo que funciona. Si tienes integraciones propietarias en producción que van bien, la existencia de una fundación no es motivo para migrar. La gobernanza neutral reduce tu riesgo futuro; no te obliga a mover nada hoy.
- Invierte en lo aburrido: seguridad y aislamiento. Dar a un agente acceso a herramientas vía MCP amplía tu superficie de ataque. Ese es el trabajo que de verdad marca la diferencia en producción, y va por delante de qué protocolo elijas (seguridad en MCP).
La consolidación de MCP y A2A bajo la AAIF es una buena noticia para quien construye con agentes: menos incertidumbre sobre qué estándares van a durar. Pero como casi todo en este ciclo, el diferencial no está en adoptar el protocolo de moda, sino en la ingeniería que pones alrededor.
En Dribba llevamos desde 2011 llevando esto a producción con equipo senior in-house. Si estás decidiendo cómo montar la capa de agentes de tu producto —qué protocolo, qué gateway, qué aislamiento— y quieres una opinión técnica sin humo, hablemos.
