Protocolos Agent-to-Agent: cómo MCP y A2A están redefiniendo la interoperabilidad multi-agente

Hace seis meses, 'sistema multi-agente' significaba una malla artesanal de endpoints HTTP sostenida por adaptadores, lógica de reintentos y fe. Hoy, dos protocolos están cambiando eso: Model Context Protocol (MCP) y Agent-to-Agent (A2A). Resuelven problemas distintos, se componen de forma elegante y la mayoría de los equipos los está implementando mal.

El problema de interoperabilidad que nadie quería resolver

Durante los últimos dos años, todo equipo serio de IA redescubrió el mismo dolor: los agentes no hablan con nada de forma estándar. Cada framework — LangChain, LlamaIndex, AutoGen, CrewAI — inventó su propia convención de invocación de herramientas. Cada proveedor lanzó su propio esquema JSON de 'function calling'. Resultado: toda integración era a medida, toda migración era una reescritura, y todo 'sistema multi-agente' era en realidad un único framework haciéndose pasar por muchos agentes.

La industria ya vivió esto antes. Tuvimos SOAP hasta que REST estandarizó la comunicación servicio-a-servicio. Tuvimos formatos propietarios de contenedores hasta que OCI estandarizó el runtime. Tuvimos orquestación atada al proveedor hasta Kubernetes. La capa agéntica era el próximo lugar esperando su protocolo — y ahora tiene dos.

MCP: el USB-C del tooling de agentes

Model Context Protocol (MCP) responde una pregunta acotada: ¿cómo descubre e invoca un agente las herramientas, recursos y prompts disponibles? La analogía que quedó — y quedó por una buena razón — es USB-C. Cualquier cliente MCP-compatible puede conectarse con cualquier servidor MCP-compatible sin código de pegamento a medida.

Un servidor MCP expone tres primitivas: tools (funciones que el agente puede llamar), resources (datos que el agente puede leer) y prompts (instrucciones plantilladas que el servidor puede inyectar). El transporte es JSON-RPC 2.0, usualmente sobre stdio para servidores locales o HTTP con Server-Sent Events para remotos. Nada más. La simplicidad es el punto.

• Un agente, muchos servidores MCP: tu agente de código basado en Claude puede conectarse simultáneamente a un servidor MCP de GitHub, uno de Postgres, uno de filesystem y uno interno de Jira — sin una sola línea de adaptador custom.
• Control de capacidades del lado del servidor: el servidor MCP define qué puede ver y hacer el agente. No le entregás credenciales al agente; corrés el servidor con esas credenciales y exponés una superficie de herramientas acotada.
• Contexto componible: los resources de MCP permiten que un agente traiga contexto fresco (archivos, filas de base de datos, respuestas de API) en tiempo de razonamiento, en vez de cargar todo en el system prompt.
• Sin lock-in de SDK: MCP es un protocolo de cable. Podés escribir un servidor en Python, Rust, TypeScript, Go o cualquier lenguaje que hable JSON-RPC.

En Xcapit construimos agentes de IA donde toda capacidad externa vive detrás de un servidor MCP. No es una elección estilística — es de gobernanza. Cuando una herramienta vive detrás de un servidor MCP, tenés un único punto auditable para autorización, rate limiting y logging. Cuando vive dentro del código del agente, no tenés nada de eso.

A2A: el protocolo para cuando un solo agente no alcanza

Agent-to-Agent (A2A) resuelve un problema que MCP nunca fue pensado para resolver: ¿cómo dos agentes — posiblemente de distintos proveedores, construidos con distintos frameworks, corriendo distintos modelos — negocian, delegan y colaboran en una tarea? A2A trata a cada agente como un servicio peer con una 'agent card' descubrible (capacidades, requisitos de autenticación, habilidades) y define las formas de mensaje para el ciclo de vida de una tarea: submitted → working → input-required → completed → failed.

El protocolo es deliberadamente conservador en lo que estandariza. No prescribe cómo razona un agente, qué modelo usa o cómo planifica. Estandariza solo los bordes donde los agentes se encuentran: identidad, handoff de tareas, streaming de estado, intercambio de artifacts. Todo lo interno al agente sigue siendo tu decisión de implementación. Eso está perfectamente bien.

• Agent Cards: un documento JSON público en /.well-known/agent.json que declara qué puede hacer un agente, cómo autenticarse y qué habilidades expone. El descubrimiento se vuelve trivial.
• Ciclo de vida de tareas tipado: cada intercambio A2A es una Task con una máquina de estados definida. Se acabaron los loops de polling ad-hoc y los reintentos de webhook sin documentar.
• Streaming por defecto: el trabajo de agente de larga duración emite actualizaciones de estado y artifacts parciales vía SSE. Tu UI no finge que el agente es una función síncrona.
• Cross-vendor por diseño: un agente construido sobre Claude puede invocar a un agente construido sobre Gemini, que a su vez invoca uno construido sobre un modelo abierto — sin que ninguno conozca los internos del otro.

La composición: MCP adentro, A2A afuera

El modelo mental que le cae a todo equipo que hemos acompañado: MCP es cómo un agente alcanza sus capacidades. A2A es cómo un agente alcanza otros agentes. Viven en planos distintos de la arquitectura, y un sistema maduro usa ambos.

Concretamente, en un proyecto reciente implementamos un sistema de revisión de documentos legales con cuatro agentes: un agente de Intake (Python, Claude Sonnet), un Analizador de Cláusulas (Rust, Claude Opus), un Verificador de Cumplimiento (TypeScript, modelo abierto fine-tuneado) y un Summarizer (Python, Gemini). Cada agente expone sus habilidades vía A2A. Cada agente internamente alcanza sus herramientas — búsqueda vectorial, OCR, registros de compliance, almacenamiento documental — vía MCP. El orquestador no sabe cómo funciona ningún agente; solo envía tareas y recibe resultados por streaming. Los agentes no saben sobre qué corren sus peers; se llaman entre sí por agent card.

Ese desacople es lo que hace que la arquitectura sobreviva los próximos dos años. Cuando salga Gemini 3 o DeepSeek R2 supere a todos en extracción de cláusulas, cambiás los internos del Analizador de Cláusulas. Nada más cambia. Sin reescritura del orquestador, sin migración de base de datos, sin sprint del 'platform team'.

Errores que aprendimos a los golpes

• No pongas lógica de negocio en el servidor MCP. Es un borde de protocolo, no una capa de dominio. Las reglas de dominio van en el servicio detrás del servidor MCP, no en las definiciones de herramientas.
• No te saltes la identidad de agente. Un caller A2A necesita autenticarse, y la autenticación tiene que ser servicio-a-servicio (mTLS, OIDC client credentials, JWTs firmados), no 'una API key en el header' reciclada de tus días de REST.
• No loguees solo la respuesta final. Para toda tarea A2A, logueá la historia completa de transiciones de estado y cada llamada a herramienta MCP con sus argumentos. Cuando un agente alucina una decisión, necesitás reconstruir el camino de razonamiento — y solo podés hacerlo si lo capturaste.
• No mezcles capas de transporte arbitrariamente. Los servidores MCP sobre stdio están bien para tooling de desarrollador; los de producción deben ser HTTP+SSE con auth apropiada. A2A siempre debe ser HTTPS con agent cards firmadas.
• No expongas todo. Que un agente pueda llamar cualquier herramienta MCP no significa que deba. Aplicá menor privilegio en el servidor: un Analizador de Cláusulas no necesita acceso de escritura a tu CRM.
• No construyas un 'orquestador' custom hasta haber probado A2A. El primer instinto es escribir un agente supervisor con lógica de delegación hardcodeada. El modelo de tareas A2A, con agent cards apropiadas, usualmente reemplaza el 80% de ese código.

Qué viene después

Tres movimientos ya se ven en el ecosistema. Primero, MCP está absorbiendo primitivas de gobernanza — metadata de autorización, declaraciones de rate limit, estimaciones de costo — que lo hacen viable como backbone para industrias reguladas, no solo tooling de desarrolladores. Segundo, A2A está creciendo un modelo de delegación de autoridad para que el agente B pueda actuar en nombre del agente A con alcance acotado, que es la pieza faltante para workflows agénticos cross-organización. Tercero, la capa de verificación: agent cards firmadas, artifacts de tareas firmados y atestaciones on-chain de acciones de agentes — que es el puente hacia agentes de IA verificables y la conversación de gobernanza sobre la que José Trajtenberg escribe por separado.

La verdad incómoda es que la mayoría de las empresas construyendo sistemas de agentes hoy están escribiendo código que será obsoleto en dieciocho meses. No porque los agentes estén mal — porque el pegamento entre ellos es a medida. Si estás arquitectando un sistema multi-agente en 2026, la pregunta ya no es '¿qué framework?' — es '¿qué protocolos, y cómo los gobierno?'.

Si tu equipo está evaluando MCP, A2A o cómo envolver ambos en una capa de gobernanza de grado productivo, hablemos. Ya cometimos los errores para que tu equipo no tenga que hacerlo.