Arquitecturas de agentes: A2A y MCP bajo la AAIF

La Fundación Linux AAIF y la convergencia de protocolos

Cuando los sistemas multiagente superan los scripts de un solo proceso, chocan directamente con dos fronteras de integración distintas:

1. ¿Cómo llega un LLM de forma fiable a las herramientas y a las fuentes de datos estructurados?
2. ¿Cómo colaboran, a través de fronteras organizativas, agentes autónomos construidos sobre frameworks dispares?

Al principio, los desarrolladores intentaron estirar protocolos únicos para resolver ambos problemas. Algunos equipos probaron a adaptar el Model Context Protocol como capa de negociación de agentes entre redes, o a usar APIs HTTP personalizadas que generaban dependencia de proveedor.

La secuencia de acontecimientos trajo el consenso de la industria:

• Junio de 2025: Google aportó A2A a la Fundación Linux, y su especificación se desarrolla de forma abierta en el repositorio a2aproject/A2A.
• Agosto de 2025: el ACP de IBM unió fuerzas con A2A, convergiendo en la especificación del protocolo A2A unificada.
• Diciembre de 2025: la Fundación Linux lanzó la Agentic AI Foundation (AAIF), anclada en MCP de Anthropic como estándar de conectividad entre modelos y herramientas, junto con goose de Block y AGENTS.md de OpenAI.
• Agosto de 2026: A2A fue aceptado en la AAIF como proyecto en fase de crecimiento (Growth Stage), lo que sitúa ambos protocolos bajo la misma gobernanza.

En lugar de competir, los estándares se reparten con claridad a lo largo de ejes ortogonales.

MCP Norte-Sur vs A2A Este-Oeste

El modelo mental del diseño moderno de agentes empresariales se corresponde directamente con la topología de red clásica:

Norte-Sur: la capa de ejecución MCP

• Dirección: vertical (agente ↔ herramienta / datos internos).
• Patrón de control: invocación determinista estricta. El modelo del agente es el maestro; la herramienta es una capacidad pasiva.
• Alcance: infraestructura privada tras el cortafuegos: bases de datos relacionales, sistemas ERP internos, acceso al sistema de archivos, utilidades CLI locales.
• Contrato: un JSON Schema por herramienta que describe parámetros y valores de retorno, intercambiado mediante JSON-RPC.

Este-Oeste: la capa de colaboración A2A

• Dirección: horizontal (agente ↔ agente par).
• Patrón de control: delegación asíncrona de objetivos. El llamante indica qué debe lograrse; el receptor decide cómo conseguirlo.
• Alcance: colaboración entre equipos, entre empresas y entre nubes.
• Contrato: la Agent Card (agent-card.json), que define identidad, capacidades, habilidades en lenguaje natural, interfaces compatibles y requisitos de seguridad.

Interoperabilidad entre LangGraph, CrewAI y Google ADK

Antes de la convergencia de protocolos, un agente empresarial escrito en LangGraph no podía delegar fácilmente una tarea a un equipo de investigación de CrewAI ni a un flujo de Google ADK sin adaptadores de API a medida.

Con A2A como interfaz externa, cada framework conserva su propio motor de razonamiento interno y comparte una forma universal de ser invocado:

1. LangGraph (coordinador): actúa como agente principal de cara al cliente y gestiona ciclos complejos de estado del grafo.
2. CrewAI (equipo especializado): opera un equipo multirrol de análisis de mercado y expone una interfaz A2A en https://crew.example.com/a2a.
3. Google ADK (trabajador): gestiona los flujos de análisis y traducción de documentos.

Cuando el coordinador de LangGraph determina que se necesita una investigación de mercado, este:

• Lee la Agent Card de CrewAI desde /.well-known/agent-card.json.
• Inspecciona el array skills para verificar que el agente gestiona la habilidad market-analysis.
• Envía una tarea mediante JSON-RPC sobre HTTPS.
• Recibe actualizaciones de estado en tiempo real mediante eventos enviados por el servidor (SSE).

El papel de Agent Card en redes multiagente

En esta arquitectura, la Agent Card es la pieza clave. Convierte un agente aislado en un nodo descubrible de la web agéntica global:

• Identidad y proveedor: confirma quién es el propietario del agente y enlaza con las credenciales de confianza.
• Declaración de habilidades: comunica competencias en lenguaje natural y modalidades de entrada/salida (texto, audio, cargas JSON).
• Interfaces compatibles: declara los bindings de protocolo (JSONRPC, HTTP+JSON o gRPC) y los endpoints.
• Esquemas y requisitos de seguridad: detalla la autenticación necesaria —como credenciales de cliente OAuth 2.0 o TLS mutuo— y qué esquemas debe satisfacer un llamante.

Puede inspeccionar cada atributo del estándar canónico v1.0 en nuestra referencia del esquema de Agent Card.

Guía de despliegue en producción

Al construir agentes empresariales sobre los estándares A2A y MCP, siga esta secuencia:

1. Herramientas internas: implemente sus conexiones de datos con servidores MCP estándar. Mantenga esos endpoints privados.
2. Redactar la Agent Card: prepare su agent-card.json declarando las habilidades públicas que su agente ofrece a otros equipos.
3. Validar los metadatos: pase su tarjeta por el validador de Agent Card para verificar el cumplimiento de la interfaz y eliminar los errores de sintaxis comunes.
4. Desplegar el endpoint well-known: aloje el archivo en /.well-known/agent-card.json con HTTPS, cabeceras CORS válidas y un control de caché adecuado.
5. Establecer la interconexión: facilite el dominio de su agente a equipos externos, permitiendo el descubrimiento automático de capacidades sin ingeniería bilateral a medida.

Preguntas frecuentes

¿Por qué IBM fusionó ACP en A2A?

Para evitar la fragmentación. A2A de Google y ACP de IBM apuntaban ambos a la interoperabilidad entre agentes, así que en agosto de 2025 IBM Research y Google anunciaron que ACP uniría fuerzas con A2A bajo la Fundación Linux. El responsable de ACP se incorporó al Comité Directivo Técnico de A2A y los conceptos de ACP se aportaron a A2A. Eso ocurrió unos meses antes de que existiera la AAIF, y la propia A2A se unió a la AAIF en agosto de 2026.

¿Puede un agente consumir herramientas MCP y a la vez exponer una Agent Card de A2A?

Sí, es el patrón estándar en producción. Internamente, el agente se conecta a bases de datos y APIs privadas mediante MCP; externamente, anuncia sus capacidades de alto nivel y sus endpoints a otros agentes mediante una Agent Card de A2A.

¿Cómo exponen una interfaz A2A los agentes de LangGraph o CrewAI?

Un agente envuelve la lógica de invocación de su grafo o equipo dentro de un servidor A2A, se describe en una Agent Card servida en /.well-known/agent-card.json y atiende solicitudes mediante uno de los bindings del protocolo (JSON-RPC, gRPC o HTTP+JSON). Varios frameworks incluyen utilidades que hacen ese envoltorio.

¿En qué se diferencia la seguridad de MCP y la de A2A?

Con MCP, la aplicación anfitriona configura de antemano cada conexión con un servidor, por lo que la confianza se establece por conexión (los servidores remotos usan autorización basada en OAuth). A los agentes A2A los descubren desconocidos de otras organizaciones, de modo que la propia Agent Card declara los esquemas y requisitos de seguridad aceptados (OAuth 2.0, OpenID Connect, claves de API, TLS mutuo) y puede llevar firmas JWS para la integridad.

¿Qué herramientas ayudan a construir y probar esta pila de dos capas?

AgentCard.net ofrece el explorador de esquemas, el generador y el validador para la capa de descubrimiento de A2A, que se integra sin fricciones junto a sus servidores MCP existentes.

Referencias

1. Especificación del protocolo A2A (a2a-protocol.org)a2a-protocol.org
2. Repositorio del protocolo A2A (a2aproject/A2A)github.com/a2aproject/A2A
3. Especificación de Model Context Protocolmodelcontextprotocol.io/