A2A vs MCP: los dos protocolos que tu arquitectura de agentes necesita en 2026
Si estás diseñando un sistema con agentes de IA, la pregunta correcta no es "¿A2A o MCP?", sino "¿dónde encaja cada uno?". No compiten: resuelven capas distintas del stack. MCP conecta un agente con herramientas y datos; A2A conecta agentes entre sí. Un despliegue serio de 2026 suele usar los dos.
Esta confusión es habitual porque ambos son ahora proyectos de la Linux Foundation y ambos hablan de "interoperabilidad de agentes". Pero cada uno vive en un nivel diferente, y entender la frontera te ahorra sobre-ingeniería.
MCP, en una frase
El Model Context Protocol (MCP) estandariza cómo un agente accede a herramientas, datos y contexto: una base de datos, una API interna, un sistema de ficheros. Es la capa agente↔herramienta. Ya lo hemos tratado a fondo en MCP en producción: cuándo usarlo y en seguridad de MCP para proteger tu stack, así que aquí lo damos por conocido.
La analogía que se ha popularizado: si el ecosistema de agentes fuera hardware, MCP sería el USB-C que conecta un agente a sus periféricos.
A2A, en una frase
El Agent2Agent Protocol (A2A) estandariza cómo agentes distintos —potencialmente de organizaciones distintas y construidos con frameworks distintos— se comunican y coordinan entre sí. Es la capa agente↔agente.
Google lo presentó en abril de 2025 y lo donó a la Linux Foundation. Por su hito de un año, en abril de 2026, la fundación reportó cifras concretas:
- 150+ organizaciones respaldando el estándar (frente a 50+ un año antes), incluyendo AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP y ServiceNow.
- Versión 1.0, la primera especificación estable.
- SDKs en 5 lenguajes de producción: Python, JavaScript, Java, Go y .NET.
- 22.000+ estrellas en GitHub.
- Agent Cards firmadas para verificación criptográfica de identidad del agente.
- Soporte GA en Azure AI Foundry y Copilot Studio, Amazon Bedrock AgentCore y Google Cloud, con uso en producción en cadena de suministro, servicios financieros, seguros y operaciones de IT.
El dato relevante para un CTO: A2A ya no es un experimento. Tiene una v1.0, respaldo de los grandes cloud y despliegues productivos verificados.
MCP vs A2A: la tabla que aclara la frontera
| MCP | A2A | |
|---|---|---|
| Conecta | Agente ↔ herramientas y datos | Agente ↔ agente |
| Pregunta que responde | "¿Cómo accede mi agente a esta API/BD?" | "¿Cómo delega mi agente una tarea a otro agente?" |
| Cruza fronteras de organización | Normalmente no | Sí, es su razón de ser |
| Identidad | Del lado del cliente/tool | Agent Cards firmadas |
| Analogía | USB-C (periféricos) | Protocolo de red entre pares |
| Estado 2026 | Estándar de facto agente↔tool | v1.0 estable, adopción enterprise |
No es una decisión excluyente. Un agente puede usar MCP para leer tu CRM y, a la vez, exponerse por A2A para que otro agente le delegue trabajo.
Cómo se combinan en un sistema multiagente
El patrón dominante en 2026 es el orquestador–subagente: un agente coordinador descompone un objetivo en subtareas y las delega en agentes especializados, monitoriza su avance y agrega los resultados. Ahí es donde encajan ambos protocolos:
- El orquestador habla con los subagentes vía A2A —incluso si esos subagentes viven en otro equipo, otra nube u otro framework.
- Cada subagente usa MCP para tocar sus herramientas y datos concretos.
Es la diferencia entre el cableado interno de cada agente (MCP) y el protocolo que les permite cooperar (A2A). Si vienes de pensar en agentes como cajas aisladas, este es el salto mental; lo enmarcamos también en el impacto de los agentes de IA en el desarrollo de software.
Cuándo NO necesitas A2A
Adoptar A2A tiene un coste de complejidad y gobernanza que no siempre se justifica:
- Un solo agente. Si tu sistema es un agente con varias herramientas, MCP te basta. A2A resuelve un problema —la coordinación entre agentes— que todavía no tienes.
- Todo dentro de tu propio dominio y framework. Si tus "agentes" son módulos del mismo servicio que ya comparten memoria y despliegue, una llamada de función interna es más simple y barata que un protocolo entre pares.
- Sin madurez de gobernanza. A2A abre la puerta a que agentes externos deleguen trabajo en los tuyos y viceversa. Sin identidad, auditoría y control de permisos claros, estás ampliando tu superficie de ataque. Los mismos principios de seguridad que aplicamos a MCP valen aquí, elevados.
La regla práctica: no metas A2A hasta que tengas más de un agente que de verdad necesite cooperar y cruzar una frontera —de equipo, de organización o de framework—. Antes de eso, es complejidad prematura.
Conclusión
MCP y A2A no son alternativas; son dos capas de la misma pila. MCP da a cada agente acceso a sus herramientas; A2A permite que los agentes cooperen entre sí. En 2026, con A2A en v1.0 y soporte de los grandes cloud, la pregunta de arquitectura ya no es si estos protocolos importan, sino dónde trazas la frontera en tu sistema.
En Dribba diseñamos arquitecturas de agentes para producto real —con equipo senior in-house y foco en lo que de verdad hay que construir, no en lo que suena bien en un keynote—. Si estás decidiendo cómo estructurar tu capa de agentes, hablemos antes de escribir el primer orquestador.
