A2A vs MCP: Dos protocolos complementarios para el emergente ecosistema de agentes

La creciente adopción de los agentes de IA — entidades de software autónomas o semiautónomas que realizan razonamiento y acciones en nombre de los usuarios — está dando lugar a una nueva capa en la arquitectura de aplicaciones.

A principios de 2025, surgieron dos protocolos distintos para abordar esto — A2A (Agente-a-Agente) y MCP (Protocolo de Contexto de Modelo). Una manera simple de entender sus roles es:

A2A: Cómo interactúan los agentes entre sí

MCP: Cómo interactúan los agentes con herramientas o contexto externo

referencia: https://google.github.io/A2A/#/topics/a2a_and_mcp

Abordan el desafío central de construir sistemas con múltiples agentes, múltiples LLM y múltiples fuentes de contexto — todos necesitando colaborar.

Una manera de enmarcarlo es: “MCP proporciona integración vertical (aplicación a modelo), mientras que A2A proporciona integración horizontal (agente a agente)

Ya seas desarrollador o no, cualquier persona que construya productos de IA o sistemas agentivos debe entender la arquitectura fundamental — porque define cómo diseñamos productos, interacciones de usuario, ecosistemas y crecimiento a largo plazo.

Este artículo introduce ambos protocolos de manera simple y fácil de entender, y destaca puntos clave para desarrolladores y constructores de productos de IA.

¿Qué es A2A (Agente-a-Agente)?#

A2A (Agente-a-Agente) es un protocolo abierto desarrollado por Google y más de 50 socios de la industria. Su propósito es permitir la interoperabilidad entre agentes — independientemente de quién los construyó, dónde están alojados o qué marco usan.

Mecanismo del protocolo A2A#

A2A utiliza JSON-RPC 2.0 sobre HTTP(S) como mecanismo de comunicación, con soporte para Eventos Enviados por el Servidor (SSE) para transmitir actualizaciones.

Modelos de comunicación A2A#

A2A define un modelo estructurado para cómo interactúan dos agentes. Un agente toma el rol de agente “cliente”, que inicia una solicitud o tarea, y otro actúa como el agente “remoto”, que recibe la solicitud e intenta cumplirla. El agente cliente primero puede realizar un descubrimiento de capacidades para determinar qué agente es el más adecuado para un trabajo dado.

Aquí surge una pregunta, cómo los agentes se descubren entre sí. Cada agente puede publicar una Tarjeta de Agente (un documento de metadatos JSON, normalmente alojado en una URL estándar como /.well-known/agent.json) que describe sus capacidades, habilidades, puntos finales de API y requisitos de autenticación.

Al leer una Tarjeta de Agente, un agente cliente puede identificar un agente compañero adecuado para la tarea en cuestión – esencialmente un directorio de lo que ese agente sabe o puede hacer. Una vez elegido un agente objetivo, el agente cliente formula un objeto Tarea para enviar.

referencia: https://google.github.io/A2A/#/

Gestión de tareas#

Toda interacción en A2A está orientada a realizar tareas. Una tarea es un objeto estructurado (definido por el esquema del protocolo) que incluye detalles de la solicitud y rastrea su estado.

En A2A, cada agente desempeña uno de dos roles:

• Agente Cliente: inicia una tarea
• Agente Remoto: recibe y procesa la tarea

Las tareas pueden incluir cualquier forma de trabajo: generar un informe, recuperar datos, iniciar un flujo de trabajo. Los resultados se devuelven como artefactos, y los agentes pueden enviar mensajes estructurados durante la ejecución para coordinarse o aclarar.

Colaboración y negociación de contenido#

A2A admite más que simples solicitudes de tareas — los agentes pueden intercambiar mensajes ricos y de múltiples partes que incluyen texto, JSON, imágenes, video o contenido interactivo. Esto permite la negociación de formato basada en lo que cada agente puede manejar o mostrar.

Por ejemplo, un agente remoto podría devolver un gráfico como datos en bruto o una imagen, o solicitar abrir un formulario interactivo. Este diseño admite comunicación flexible y agnóstica a la modalidad, sin requerir que los agentes compartan herramientas o memoria internas.

Ejemplo de caso de uso#

Aquí tienes un ejemplo del mundo real de cómo podría usarse A2A en un escenario empresarial:

Un nuevo empleado es contratado en una gran empresa. Múltiples sistemas y departamentos están involucrados en la incorporación:

• RRHH necesita crear un registro y enviar un correo electrónico de bienvenida
• TI necesita aprovisionar una laptop y cuentas de la empresa
• Instalaciones necesita preparar un escritorio y una credencial de acceso

Tradicionalmente, estos pasos se manejan manualmente o a través de integraciones estrechamente acopladas entre sistemas internos.

En lugar de APIs personalizadas entre cada sistema, cada departamento expone su propio agente usando el protocolo A2A:

Un sistema multiagente — llamémoslo OnboardingPro (por ejemplo, onboarding-agent.company.com) — coordina todo el flujo de trabajo de incorporación.

1. Descubrimiento: Lee el .well-known/agent.json de cada agente para entender capacidades y autenticación.
2. Delegación de tareas:
   • Envía una tarea createEmployee al agente de RRHH.
   • Envía tareas setupEmailAccount y orderHardware al agente de TI.
   • Envía assignDesk y generateBadge al agente de Instalaciones.
3. Actualizaciones en streaming: Los agentes transmiten el progreso de vuelta utilizando Eventos Enviados por el Servidor (por ejemplo, “laptop enviada”, “escritorio asignado”).
4. Colección de artefactos: Resultados finales (por ejemplo, credencial PDF, correos electrónicos de confirmación, credenciales de cuenta) se devuelven como artefactos A2A.
5. Finalización: El OnboardingPro notifica al gerente de contratación cuando la incorporación se completa.

¿Qué es MCP (Protocolo de Contexto de Modelo)?#

MCP (Protocolo de Contexto de Modelo), desarrollado por Anthropic, aborda un problema diferente: cómo las aplicaciones externas pueden proporcionar contexto estructurado y herramientas a un agente basado en un modelo de lenguaje en tiempo de ejecución.

En lugar de habilitar la comunicación inter-agente, MCP se enfoca en la ventana de contexto — la memoria de trabajo de un LLM. Su objetivo es:

• Inyectar dinámicamente herramientas, documentos, funciones API o estado del usuario relevantes en la sesión de inferencia de un modelo
• Permitir que los modelos llamen funciones o recuperen documentos sin codificar rígidamente el prompt o la lógica

Arquitectura clave de MCP#

Para entender MCP, primero necesitas entender la arquitectura general — cómo funcionan todas las partes juntas.

Anfitrión MCP: “La IA con la que estás hablando”#

Piensa en el Anfitrión MCP como la propia aplicación de IA — como Claude Desktop o tu asistente de codificación.

Es la interfaz que estás usando — el lugar donde escribes o hablas.

Quiere obtener herramientas y datos que ayuden al modelo a dar mejores respuestas.

Cliente MCP: “El conector”#

El Cliente MCP es la pieza de software que conecta tu anfitrión de IA (como Claude) con el mundo exterior. Es como una centralita — gestiona conexiones seguras, uno a uno, con diferentes Servidores MCP. Cuando la IA quiere acceder a algo, lo hace a través del cliente.

Es útil pensar en herramientas como ChatGPT, Claude chat, o Cursor IDE como anfitriones MCP — proporcionan la interfaz con la que interactúas. Detrás de escena, utilizan un cliente MCP para conectarse a diferentes herramientas y fuentes de datos a través de servidores MCP.

referencia: https://modelcontextprotocol.io/introduction

Servidor MCP: “El proveedor de herramientas”#

Un Servidor MCP es un programa pequeño y enfocado que expone una herramienta o capacidad específica — como:

• Buscar archivos en tu computadora
• Consultar datos en una base de datos local
• Llamar a una API externa (como clima, finanzas, calendario)

Cada servidor sigue el protocolo MCP, por lo que la IA puede entender lo que puede hacer y cómo llamarlo.

Fuentes de datos locales: “Tus propios archivos y servicios”#

Algunos Servidores MCP se conectan a cosas en tu propia máquina — como:

• Documentos y carpetas
• Proyectos de código
• Bases de datos o aplicaciones locales

Esto permite que la IA busque, recupere o calcule cosas sin cargar tus datos en la nube.

Servicios remotos: “APIs y herramientas en línea”#

Otros Servidores MCP están conectados a Internet — hablan con:

• APIs (por ejemplo, Stripe, Notion, GitHub)
• Herramientas SaaS
• Bases de datos de la compañía en la nube

Así que la IA puede decir, por ejemplo: “Llama al servidor de GitHub y obtén la lista de PR abiertos.”

MCP ahora admite la conexión a servidores MCP remotos. Esto significa que un cliente MCP puede ganar capacidades más poderosas. En teoría,

Con el conjunto correcto de servidores MCP, los usuarios pueden convertir cada cliente MCP en una “aplicación para todo”.

referencia: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

Poniéndolo todo junto#

Ahora usemos un diagrama para ver cómo todo trabaja junto.

1. Pides algo complejo a la IA
2. La IA (el anfitrión) pide ayuda al cliente
3. El cliente llama al servidor MCP adecuado — quizás uno que revise archivos o acceda a una API
4. El servidor envía de vuelta datos o ejecuta una función
5. El resultado fluye de vuelta al modelo para ayudar a completar la tarea

A2A vs MCP — Comparación#

Cómo trabajan juntos#

Más que ser alternativas, A2A y MCP son complementarios. En muchos sistemas, ambos se usarán juntos.

Ejemplo de flujo de trabajo#

1. Un usuario envía una solicitud compleja en una interfaz de agente empresarial.
2. El agente orquestador usa A2A para delegar subtareas en agentes especializados (por ejemplo, análisis, RRHH, finanzas).
3. Uno de esos agentes usa MCP internamente para invocar una función de búsqueda, obtener un documento o calcular algo usando un modelo.
4. El resultado se devuelve como un artefacto a través de A2A, permitiendo colaboración de agente a agente con acceso a herramientas modulares.

Esta arquitectura separa la comunicación inter-agente (A2A) de la invocación de capacidades intra-agente (MCP) — haciendo el sistema más fácil de componer, escalar y asegurar.

Conclusión#

A2A trata sobre agentes hablando con otros agentes a través de una red — de manera segura, asincrónica y centrada en tareas.

MCP trata sobre inyectar capacidades estructuradas en una sesión de modelo, dejando que los LLM razonen sobre herramientas y datos contextualmente.

Usados juntos, dan soporte a sistemas multiagente composables que son tanto extensibles como interoperables.

Cómo la infraestructura base de MCP + A2A podría dar forma al futuro de los mercados de productos de agentes#

Por último, quiero hablar sobre cómo esta base técnica central podría dar forma al futuro del mercado de IA — y lo que significa para las personas que construyen productos de IA.

El cambio de la interacción humano-computadora#

Un claro ejemplo de este cambio se puede ver en los flujos de trabajo de desarrollo y servicio. Con servidores MCP ahora integrados en IDEs y agentes de codificación, la forma en que los desarrolladores interactúan con las herramientas está cambiando fundamentalmente.

Anteriormente, un flujo de trabajo típico implicaba buscar el servicio correcto, configurar el alojamiento, leer documentación, integrar APIs manualmente, escribir código en el IDE y configurar funciones a través de un panel de bajo código. Era una experiencia fragmentada, que requería cambios de contexto y sobrecarga técnica en cada paso.

Ahora, con agentes de codificación conectados por MCP, gran parte de esa complejidad puede abstraerse. Los desarrolladores pueden descubrir y usar herramientas más naturalmente a través de prompts conversacionales. La integración de APIs se está convirtiendo en parte del flujo de codificación en sí mismo — a menudo sin necesitar una interfaz de usuario separada o una configuración manual. (Solo piensa en lo complejos que pueden ser los paneles de AWS o Microsoft). La interacción se vuelve más fluida — más sobre guiar el comportamiento que sobre ensamblar características.

En este modelo, la interacción del usuario o del desarrollador se desplaza de configurar características a orquestar comportamientos. Esto también cambia el rol del diseño de productos.

En lugar de usar UIs para “cubrir” desafíos técnicos (por ejemplo, “esto es demasiado difícil de codificar, hagamos un panel de configuración”), ahora necesitamos:

• Pensar en la experiencia de extremo a extremo
• Diseñar cómo y cuándo las interacciones de IA + usuario deben unirse
• Dejar que la IA maneje la lógica, y guiar a los usuarios a través de la intención y el flujo

El desafío se convierte en decidir cuándo y cómo deben unirse la IA y la entrada del usuario, dejar que la IA maneje la lógica, y guiar a los usuarios a través de la intención y el flujo y cómo insertar las interacciones correctas en el momento adecuado.

Usé un servicio de desarrollo y producto API como ejemplo para mostrar cómo podría cambiar la interacción del usuario — pero lo mismo se aplica al software empresarial. Durante mucho tiempo, las herramientas empresariales han sido complejas y difíciles de usar. La interacción en lenguaje natural tiene el potencial de simplificar muchos de esos flujos de trabajo.

Paradigmas productivos agentivos y su impacto en SaaS#

Estamos comenzando a ver un número creciente de servidores MCP emerger. Imagina que Airbnb ofrece un servidor MCP de reservas, o Google Maps expone un servidor MCP de mapas. Un agente (como cliente MCP) podría conectarse a muchos de estos servidores a la vez — desbloqueando flujos de trabajo que anteriormente requerían integraciones personalizadas o aplicaciones estrechamente ligadas.

Comparado con la era de SaaS, donde las integraciones a menudo eran manuales y rígidas, este modelo permite flujos de trabajo más autónomos y conexiones fluidas entre servicios. Aquí hay dos ejemplos:

1. Diseñar a partir de documentos

   Escribes un PRD en Notion. Un agente de Figma lee el documento y automáticamente crea un wireframe que dispone los conceptos centrales — sin necesidad de entrega manual.

2. Investigación de competidores, de principio a fin

   Pides un análisis de competidores. Un grupo de agentes busca en la web, se suscribe a servicios relevantes en tu nombre (con autentificación segura), recopila los resultados y entrega los artefactos de vuelta — ya organizados en tu espacio de trabajo de Notion.

Desafíos con límites de autenticación y autorización#

Con el aumento de conexiones de agente a agente, conexiones de cliente MCP a servidor MCP, hay muchas necesidades subyacentes sobre autenticación y autorización porque el agente actuará en nombre de humanos y usuarios y las credenciales deben ser aseguradas en este camino.

Hasta ahora hay varios escenarios específicos de este nuevo aumento de agente a agente y MCP.

1. Agente vs SaaS y Aplicación Web
2. Cliente MCP (Agente) vs Servidor MCP
3. Usuario vs Agente
4. Agente vs Agente

Otro caso de uso interesante es la federación de identidad múltiple que Google mencionó:

Por ejemplo, el Usuario U está trabajando con el Agente A que requiere el identificador del sistema A. Si el Agente A luego depende de la herramienta B o el Agente B que requiere el identificador del sistema B, el usuario puede necesitar proporcionar identidades para ambos sistemas A y B en una sola solicitud. (Supongamos que el sistema A es una identidad LDAP empresarial y el sistema B es una identidad de proveedor SaaS).

Logto es un proveedor de OIDC y OAuth, bien adecuado para el futuro de las integraciones de IA.

Con su infraestructura flexible, estamos ampliando activamente sus capacidades y hemos publicado una serie de tutoriales para ayudar a los desarrolladores a comenzar rápidamente.

¿Tienes preguntas?

Contáctanos — o sumérgete y explora lo que puedes construir con Logto hoy.