A2A. MCP. ACP. Misiones totalmente diferentes. Todas cruciales.
Aquí tenéis una explicación sobre cómo estos protocolos se conectan, complementan y compiten en el ecosistema de agentes.
Un resumen rápido:
- 📊 A2A – Comunicación entre agentes a través de proveedores, plataformas y nubes.
- 🧠 MCP – Protocolo de Contexto de Modelo para inyectar herramientas y datos estructurados en LLMs.
- 🛰️ ACP – Protocolo de prioridad local para agentes en dispositivos (piensa en edge, robótica, IA sin conexión).
La conclusión: Estos protocolos no son rivales, son piezas de un rompecabezas. Juntos, permiten sistemas de IA más inteligentes, modulares y resilientes.
¿Qué es MCP (Model Context Protocol)?
El Model Context Protocol (MCP), introducido por Anthropic, define una interfaz estandarizada para proporcionar contexto estructurado y en tiempo real a los modelos de lenguaje grande (LLMs).
Funcionalidades Principales
Inyección de datos contextuales: MCP te permite incorporar recursos externos, como archivos, filas de bases de datos o respuestas de API, directamente en el prompt o memoria de trabajo. Todo esto a través de una interfaz estandarizada, para que tu LLM se mantenga ligero y limpio.
Enrutamiento e invocación de funciones: MCP también permite que los modelos llamen herramientas de manera dinámica. Puedes registrar capacidades como searchCustomerData
o generateReport
, y el LLM puede invocarlas bajo demanda. Es como darle a tu IA acceso a una caja de herramientas, pero sin integrar las herramientas directamente en el modelo.
Orquestación de Prompts: En lugar de llenar tu prompt con todos los detalles posibles, MCP ayuda a ensamblar solo el contexto que importa. Piensa en una construcción modular de prompts sobre la marcha: contexto más inteligente, menos tokens, mejores resultados.
Características de implementación
- Opera sobre HTTP(S) con descriptores de capacidad basados en JSON.
- Diseñado para ser independiente del modelo: cualquier LLM con un runtime compatible puede aprovechar servidores compatibles con MCP.
- Compatible con gateways de API y estándares de autenticación empresarial (por ejemplo, OAuth2, mTLS).
Casos de uso en ingeniería
- Integraciones de LLM para APIs internas: Permite acceso seguro, de solo lectura o interactivo a datos empresariales estructurados sin exponer endpoints sin procesar.
- Agentes empresariales: Equipa agentes autónomos con contexto en tiempo real de herramientas como Salesforce, SAP o bases de conocimiento internas.
- Construcción dinámica de prompts: Adapta los prompts según la sesión del usuario, el estado del sistema o la lógica del pipeline de tareas.
¿Qué es ACP (Agent Communication Protocol)?
El Agent Communication Protocol (ACP) es un estándar abierto propuesto originalmente por BeeAI e IBM para habilitar la comunicación estructurada, el descubrimiento y la coordinación entre agentes de IA que operan en el mismo entorno local o de borde.
A diferencia de los protocolos orientados a la nube como A2A o los protocolos de enrutamiento de contexto como MCP, ACP está diseñado para la orquestación de agentes en tiempo real y de prioridad local con un mínimo de sobrecarga de red e integración estrecha entre agentes desplegados dentro de un runtime compartido.
Diseño y arquitectura del protocolo
ACP define un entorno de agentes descentralizado en el cual:
- Cada agente anuncia su identidad, capacidades y estado utilizando una capa de difusión/descubrimiento local.
- Los agentes se comunican a través de mensajería basada en eventos, a menudo utilizando un bus local o un sistema de comunicación entre procesos (IPC – inter-process communication).
- Un controlador de runtime (opcional) puede orquestar el comportamiento de los agentes, agregar telemetría y hacer cumplir políticas de ejecución.
Los agentes ACP típicamente operan como servicios o contenedores ligeros y sin estado con un sustrato de comunicación compartido.
Características de implementación
- Diseñado para entornos de baja latencia (por ejemplo, orquestación local, robótica, IA de borde sin conexión).
- Puede implementarse sobre gRPC, ZeroMQ o buses de runtime personalizados.
- Enfatiza la soberanía local: no se requiere dependencia de la nube ni registro de servicios externos.
- Soporta tipificación de capacidades y descriptores semánticos para el enrutamiento automatizado de tareas.
Casos de uso en ingeniería
- Orquestación de múltiples agentes en dispositivos de borde (por ejemplo, drones, clusters de IoT o flotas robóticas).
- Sistemas LLM de prioridad local coordinando invocaciones de modelos, entradas de sensores y ejecución de acciones.
- Entornos de runtime autónomos donde los agentes deben coordinarse sin infraestructura centralizada en la nube.
En resumen, ACP ofrece una capa de protocolo local para sistemas de IA modulares, priorizando la coordinación de baja latencia, la resiliencia y la composabilidad. Es una opción natural para despliegues autónomos, sensibles a la privacidad o de prioridad en el borde donde los protocolos orientados a la nube son imprácticos.
¿Qué es A2A (Agent-to-Agent Protocol)?
El Agent-to-Agent (A2A) Protocol, introducido por Google, es una especificación multiplataforma para habilitar que los agentes de IA se comuniquen, colaboren y deleguen tareas a través de sistemas heterogéneos.
A diferencia del enfoque de prioridad local de ACP o la capa de integración de herramientas de MCP, A2A aborda la interoperabilidad horizontal, estandarizando cómo los agentes de diferentes proveedores o runtimes pueden intercambiar capacidades y coordinar flujos de trabajo a través de la web abierta.
Descripción general del protocolo
A2A define un modelo de comunicación basado en HTTP donde los agentes se tratan como servicios interoperables. Cada agente expone una «Tarjeta de Agente» — un descriptor JSON legible por máquina que detalla su identidad, capacidades, endpoints y requisitos de autenticación.
Los agentes usan esta información para:
- Descubrirse entre sí programáticamente.
- Negociar tareas y roles.
- Intercambiar mensajes, datos y actualizaciones en streaming.
A2A es agnóstico a la capa de transporte en principio, pero actualmente especifica JSON-RPC 2.0 sobre HTTPS como su mecanismo central de interacción.
Componentes principales
- Tarjetas de Agente: Documentos JSON que describen las capacidades de un agente, endpoints, tipos de mensajes soportados, métodos de autenticación y metadatos de runtime.
- Interfaz Cliente/Servidor A2A: Cada agente puede funcionar como cliente (iniciador de tareas), servidor (ejecutor de tareas) o ambos, permitiendo el enrutamiento y la negociación dinámica de tareas.
- Intercambio de Mensajes y Artefactos: Soporta tareas multipartes con contexto, salida en streaming (a través de SSE) y artefactos persistentes (por ejemplo, archivos, fragmentos de conocimiento).
- Negociación de Experiencia de Usuario: Los agentes pueden adaptar el formato de los mensajes, la granularidad del contenido y la visualización para coincidir con las capacidades del agente receptor.
Arquitectura de seguridad
- Autorización basada en OAuth 2.0 y claves de API.
- Endpoints con alcance de capacidad: los agentes solo exponen funciones requeridas para interacciones declaradas.
- Los agentes pueden operar en modo «opaco»: ocultando la lógica interna mientras revelan servicios invocables.
Características de implementación
- Nativo de la web por diseño: construido sobre HTTP, JSON-RPC y seguridad web estándar.
- Independiente del modelo: funciona con cualquier sistema de agentes (LLM o de otro tipo) que implemente el protocolo.
- Soporta streaming de tareas y colaboración multi-turno con cargas útiles ligeras.
Casos de uso en ingeniería
- Ecosistemas de agentes multiplataforma donde los agentes de diferentes equipos o proveedores necesitan interoperar de manera segura.
- Orquestación distribuida de agentes en entornos de IA nativos de la nube (por ejemplo, Vertex AI, LangChain, HuggingFace Agents).
- Marcos de colaboración multi-agente, como flujos de trabajo de IA empresariales que abarcan múltiples sistemas (por ejemplo, CRM, RRHH, agentes de TI).
Comparativa de protocolos MCP, ACP y A2A
Característica | MCP | ACP | A2A |
---|---|---|---|
Enfoque principal | Inyección de contexto para LLMs | Coordinación local de agentes | Comunicación entre agentes multiplataforma |
Arquitectura | Modelo cliente-servidor (host-agente), runtime centralizado | Descentralizado, runtime local | Servidor centralizado con Tarjetas de Agente |
Alcance | Integración vertical (herramientas <-> modelo) | Interacción y ejecución de agentes de prioridad local | Integración horizontal (agente <-> agente) |
Mecanismo de descubrimiento | Registro de herramientas en servidor(es) | Difusión local / registro en runtime | Descubrimiento de agentes sobre HTTP(S) |
Protocolo de transporte | HTTP(S), JSON | IPC, ZeroMQ, gRPC (Flexible) | JSON-RPC 2.0 sobre HTTP(S) |
Modelo de seguridad | Autenticación a nivel de aplicación, sandboxing, seguridad de red privada | Sandboxing en runtime, seguridad de red privada | OAuth2.0, autenticación a nivel de aplicación |
Mejor para | Aplicaciones LLM con integraciones de datos y herramientas externas | Edge IA, sistemas embebidos; escenarios de prioridad sin conexión | Flujos de trabajo multi-agente en entornos distribuidos |
Caso de uso ejemplo | Conectar un LLM a APIs internas | Coordinación de IA en dispositivos con múltiples agentes pequeños | Agentes empresariales distribuidos colaborando |
¿Complementarios o Competitivos?
A2A + MCP
A2A y MCP no compiten entre sí, están resolviendo partes totalmente diferentes del rompecabezas de la IA agentica, y en realidad se complementan bastante bien.
Piensa en MCP como el protocolo que permite a los agentes de IA conectarse al mundo. Les da acceso a archivos, APIs, bases de datos, básicamente, todo el contexto estructurado que necesitan para hacer algo útil. Ya sea obteniendo datos de ventas en tiempo real o generando un informe personalizado, MCP maneja la conexión a herramientas y datos.
Ahora agrega A2A. Aquí es donde los agentes comienzan a colaborar. A2A les da un lenguaje compartido y un conjunto de reglas para descubrirse entre sí, delegar tareas y negociar cómo trabajarán juntos, incluso si están construidos por diferentes proveedores o funcionan en diferentes plataformas.
Entonces, aquí tienes una forma simple de pensarlo:
- MCP conecta la IA a las herramientas.
- A2A conecta la IA a otra IA.
Juntos, forman una base modular sólida para construir sistemas inteligentes y colaborativos.
¿Qué pasa con ACP?
Luego está ACP, que adopta un enfoque completamente diferente. Se trata de la coordinación de agentes de prioridad local, sin necesidad de la nube. En lugar de usar HTTP y descubrimiento basado en la web, ACP permite que los agentes se encuentren y hablen entre sí dentro de un runtime compartido.
Esto es perfecto para situaciones donde:
- Tienes un ancho de banda limitado o necesitas baja latencia (como en robótica o asistentes en el dispositivo).
- La privacidad es importante y quieres mantener todo fuera de línea.
- O estás desplegando en entornos desconectados de internet (por ejemplo, pisos de fábrica, nodos de borde).
ACP no está tratando de competir con A2A, simplemente llena un nicho diferente. Pero en algunos entornos, especialmente en entornos controlados, ACP podría reemplazar a A2A por completo, porque omite la sobrecarga de los protocolos nativos de la web y simplemente hace el trabajo localmente.
¿Convergencia o Fragmentación?
A medida que más equipos adoptan estos protocolos, se están formando algunos futuros posibles.
¿El mejor caso? Vemos convergencia. Imagina una plataforma unificada de agentes donde A2A maneja el ida y vuelta entre agentes, MCP gestiona el acceso a herramientas y datos, y los runtimes estilo ACP se conectan para escenarios de borde o sin conexión. Todo simplemente funciona, y los desarrolladores pueden construir sobre esto sin preocuparse por qué protocolo está haciendo qué detrás de escena.
¿El peor caso? Las cosas se fragmentan. Diferentes proveedores empujan sus propios sabores de A2A o MCP, y terminamos con un lío, como los primeros días de los servicios web, cuando nada hablaba con nada sin mucho código de pegamento.
¿El término medio? Las herramientas y middleware de código abierto podrían salvar el día. Estos proyectos se situarían entre los agentes y los protocolos, abstrayendo las diferencias y dando a los desarrolladores una API limpia y unificada, mientras traducen bajo el capó dependiendo de dónde y cómo funcionen tus agentes.
En resumen: estamos en una etapa temprana. Pero cómo construimos y adoptamos estos estándares ahora dará forma a si los agentes de IA se convierten en un ecosistema cohesivo o en un mosaico de silos.
Información basada en la publicación de Edwin Lisowski (Co-Founder @ Addepto & Technology Expert & Social Science Enthusiast) en Medium: «What Every AI Engineer Should Know About A2A, MCP & ACP«.