Google apila APIs, MCP y A2A para su IA empresarial

Google ordena su oferta de IA empresarial en tres capas que no se sustituyen entre sí: APIs para llegar a los sistemas que ya están en producción, MCP para que un modelo invoque herramientas y A2A para que un agente delegue trabajo en otro agente. Así lo describe Techzine Global en su repaso de la arquitectura que la compañía propone a sus clientes corporativos.

El matiz no es cosmético. Buena parte del mercado vende las tres siglas como si fueran intercambiables y no lo son: cada una resuelve un problema distinto y cada una falla de una manera distinta. Quien monta integraciones para empresas lo nota en la primera semana de proyecto.

Tres capas que no compiten entre sí

La capa de APIs es la más antigua y la menos vistosa. Es donde viven el ERP, el CRM, el sistema de facturación y el core bancario que nadie va a reescribir para que hable con un modelo. Google lleva años trabajando ese terreno con Apigee y el argumento sigue siendo el de siempre: gobierno, cuotas, autenticación y trazabilidad. Un agente sin esa capa debajo no tiene a qué llamar.

MCP se sitúa encima. El Model Context Protocol, publicado por Anthropic a finales de 2024 y adoptado hoy por buena parte de la industria, estandariza cómo un modelo descubre y usa herramientas externas: un servidor MCP expone tools, resources y prompts, y cualquier cliente compatible los consume sin escribir un conector a medida. La especificación está en modelcontextprotocol.io. Que Google lo asuma en su discurso corporativo confirma algo que ya se veía venir: MCP dejó de ser cosa de un solo proveedor.

A2A (Agent2Agent) es la tercera pieza y la más joven. Google la presentó en abril de 2025 con medio centenar de socios y la cedió después a la Linux Foundation. Cubre un hueco que MCP no toca: qué ocurre cuando el interlocutor no es una herramienta determinista sino otro agente, con su propio estado, sus propios permisos y su propia opacidad. Ahí hacen falta descubrimiento de capacidades, negociación de tareas y un rastro de quién pidió qué a quién.

Por qué importa para quien integra

La lectura práctica es que la pregunta de si hay que elegir entre MCP y A2A está mal planteada. En una integración real conviven las tres capas: el agente usa MCP para consultar un CRM a través de una API gobernada, y recurre a A2A solo cuando necesita que otro dominio, otro equipo u otro proveedor ejecute algo que él no controla.

Conviene ser honesto con la madurez de cada nivel. Las APIs REST llevan más de una década en producción y sus patrones de seguridad están resueltos. MCP tiene un ecosistema amplio y una especificación que se mueve rápido, con la autorización como la parte que más ha cambiado en el último año. A2A sigue siendo terreno de pilotos: son pocos los equipos que tienen dos agentes de proveedores distintos negociando tareas en producción y con auditoría seria.

Para un responsable técnico la consecuencia es de orden, no de tecnología. Antes de conectar agentes hace falta el inventario de APIs, los permisos por servicio y los logs. Un servidor MCP mal acotado convierte un problema de producto en un problema de seguridad: si no se diseña con cuidado, acaba concediendo lectura y escritura con la identidad del proceso que lo ejecuta y no con la del usuario final.

Lo que vemos en proyecto

En las integraciones que hemos montado, la mayor parte del esfuerzo sigue estando por debajo del protocolo: normalizar datos, acotar permisos, decidir qué operación es reversible y cuál exige confirmación humana. La capa de agentes se lleva los titulares y la capa de APIs se lleva las horas.

El planteamiento de tres capas nos parece correcto y bastante poco sorprendente, que es justo lo que se le pide a una arquitectura empresarial. La pregunta interesante no es si MCP y A2A van a convivir, sino cuántas organizaciones tienen la capa de APIs lo bastante ordenada como para que la conversación sobre agentes tenga algún sentido.