Hablemos de su proyecto
Protocolos agénticos

MCP, A2A y AGNTCY: entender la interoperabilidad de los agentes de IA en 2026

Todos los protocolos agénticos no resuelven el mismo problema. Apilarlos sin una necesidad clara aumenta la superficie de ataque y la complejidad operativa.

MCP, A2A y AGNTCY: entender la interoperabilidad de los agentes de IA en 2026

El ecosistema agéntico se dota de protocolos abiertos para evitar que cada framework y proveedor invente sus propios conectores. MCP, A2A y AGNTCY se citan a menudo juntos, pero no resuelven el mismo problema. MCP conecta principalmente una aplicación de IA con herramientas y datos. A2A organiza los intercambios entre aplicaciones agénticas. AGNTCY desarrolla bloques de infraestructura para el descubrimiento, la identidad, la mensajería y la observabilidad de ecosistemas de agentes.

Combinarlos puede ser pertinente a gran escala. Apilarlos en un simple asistente interno crea una complejidad y una superficie de seguridad innecesarias.

A2A v1.0 es presentada por su proyecto como una versión estable lista para la producción; MCP publicó la especificación el 28-07-2026. La madurez y las interfaces AGNTCY deben ser verificadas para cada componente.

Por qué la interoperabilidad se está convirtiendo en un tema

Una empresa puede utilizar varios modelos, marcos y productos. Un agente comercial quizás deba solicitar un análisis a un agente documental y luego utilizar una herramienta de CRM. Sin contrato común, cada interacción es una integración específica.

La interoperabilidad apunta a:

  • descubrimiento de capacidades;
  • descripción de tareas ;
  • intercambio de mensajes y artefactos;
  • gestión de trabajos largos;
  • identidad ;
  • seguridad;
  • observabilidad ;
  • portabilidad entre proveedores.

No reemplaza el modelo de dominio, las reglas de autorización ni la gobernanza de los datos.

MCP: conectar una aplicación de IA a capacidades

MCP estandariza la manera en que un cliente descubre y utiliza herramientas, recursos y extensiones expuestas por un servidor. Es adecuado cuando una aplicación agéntica debe consultar un repositorio, llamar a una API de negocio o iniciar una capacidad supervisada.

El servidor puede permanecer como una fachada sobre un servicio existente. Las herramientas deben ser estrechas, autorizadas y observables. MCP no transforma un servicio en un agente autónomo; hace que sus capacidades sean consumibles de manera estandarizada.

La especificación 2026-07-28 adopta un núcleo sin estado y un marco de extensiones, lo que facilita ciertos despliegues a gran escala.

A2A: colaborar entre agentes

A2A apunta al intercambio entre aplicaciones agénticas que pueden construirse con diferentes frameworks y mantener su funcionamiento interno opaco. Un agente publica un mapa de capacidades, recibe una tarea, intercambia mensajes y devuelve artefactos o un estado.

El protocolo es pertinente cuando un agente delega una tarea a otro actor que posee su propia autonomía, su ciclo de vida y eventualmente su organización. Maneja mejor los trabajos largos y las interacciones que la llamada de una simple herramienta.

A2A v1.0 marca una estabilización del contrato. La adopción no exime de verificar la identidad, el titular, la autorización, la confidencialidad y el resultado.

AGNTCY: infraestructura abierta para un Internet de agentes

El proyecto AGNTCY, acogido por la Linux Foundation, desarrolla componentes alrededor del descubrimiento, la identidad, la mensajería y la observabilidad. Su Open Agentic Schema Framework propone una taxonomía para describir capacidades, dominios y relaciones.

Este nivel se vuelve interesante cuando se deben encontrar, calificar y operar numerosos agentes a través de equipos u organizaciones. No es una obligación para usar MCP o A2A. Los componentes y su madurez deben evaluarse individualmente.

¿Qué protocolo para qué problema?

Necesidad Opción mínima probable
Llamar a una función de negocio estable API clásica
Exponer herramientas a varios clientes de IA MCP
Delegar una tarea a una aplicación agéntica A2A
Descubrir y gobernar a numerosos agentes registro/infraestructura dedicada
Orquestar algunos componentes internos marco o flujo de trabajo interno
Intercambiar con un socio API o A2A según autonomía y duración

Comparación de los roles de MCP, A2A y de una infraestructura agéntica de descubrimiento y observabilidad.

API clásica o protocolo agéntico

Una API sigue siendo preferible cuando la operación es determinista, el contrato estable y los actores conocidos. Es más fácil de probar, asegurar y explotar.

Un protocolo agéntico aporta valor cuando se descubren las capacidades, las tareas evolucionan, los intercambios son largos o varios proveedores deben colaborar. El criterio no es el uso de un LLM, sino la naturaleza del contrato.

Una arquitectura combinada

Un escenario posible:

  1. un agente coordinador recibe un objetivo;
  2. descubre un agente especializado a través de un registro ;
  3. le delega una tarea con A2A;
  4. El agente especializado utiliza MCP para acceder a herramientas internas;
  5. La infraestructura recopila identidad, rastros y estados;
  6. una política valida el resultado antes de la acción.

Cada capa debe tener una responsabilidad. La misma necesidad no debe estar encapsulada en varios protocolos sin razón.

Descubrimiento y confianza

Descubrir una tarjeta de agente o un servidor no significa confiar en él. El registro conserva propietario, versión, procedencia, certificaciones posibles, capacidades, políticas y estado de aprobación.

La identidad debe funcionar a través de las fronteras. Una organización puede exigir un contrato, una lista autorizada y una autenticación mutua antes de cualquier intercambio.

Las capacidades anunciadas están verificadas. Un agente no recibe más datos porque afirma poseer una habilidad.

Autorización y delegación

Cuando un agente delega, no debe transmitir un token general. La delegación precisa:

  • ordenante;
  • beneficiario;
  • tarea;
  • recursos ;
  • duración;
  • presupuesto ;
  • acciones ;
  • posibilidad de subdelegación.

El servicio final vuelve a verificar los derechos. La cadena de delegación es visible en la auditoría.

Tareas, mensajes y artefactos

Una tarea larga posee un estado, actualizaciones, una cancelación y un resultado. Los mensajes no deben confundirse con comandos autorizados. Los artefactos — documento, informe, código o datos — tienen un tipo, un origen y derechos.

El orquestador debe poder gestionar un agente no disponible, un resultado parcial o un retraso. No supone que una respuesta conversacional equivalga a un éxito de negocio.

Semántica de las capacidades

Dos agentes pueden ambos declarar « búsqueda » al mismo tiempo que producen resultados incompatibles. Los esquemas, taxonomías y contratos comerciales siguen siendo necesarios. OASF puede ayudar a describir capacidades, pero la empresa debe definir sus propios requisitos de calidad y de datos.

Las versiones y extensiones se negocian. Un cambio de capacidad desencadena una nueva calificación.

Observabilidad distribuida

Una tarea atraviesa varios agentes, protocolos y herramientas. El identificador de correlación, las marcas de tiempo y los estados deben seguir el recorrido sin exponer los prompts sensibles.

Las métricas incluyen:

  • plazo total y por actor;
  • delegaciones;
  • errores;
  • repeticiones;
  • costos;
  • aprobaciones ;
  • resultados rechazados;
  • políticas aplicadas.

Un sistema multiagente sin rastreo de extremo a extremo es difícil de diagnosticar y facturar.

Seguridad

Los principales riesgos son:

  • agente o servidor malicioso;
  • carta de capacidad engañosa;
  • delegación excesiva;
  • inyección en los mensajes;
  • exfiltración por una herramienta;
  • artefacto peligroso ;
  • bucle de delegación;
  • consumo descontrolado;
  • confusión de inquilino.

Los controles incluyen listas autorizadas, presupuestos, profundidad máxima, validación de esquemas, sandbox, aprobaciones, límites de red y mecanismo de corte.

Evitar los bucles y las explosiones de costo

Un agente puede delegar a otro que a su vez delega. El orquestador fija profundidad, número de tareas, duración, tokens, herramientas y presupuesto. Las subdelegaciones están permitidas explícitamente.

Una tarea debe poder ser cancelada y los recursos liberados. Los reintentos son idempotentes y limitados.

Gobernanza de versiones

MCP, A2A y los componentes AGNTCY evolucionan. La organización mantiene una matriz de compatibilidad, entornos de prueba y una política de actualización. Las depreciaciones se tratan como cambios de API.

Los SDK simplifican la implementación pero no deben ocultar la versión realmente soportada.

Comenzar por la arquitectura mínima

Un primer agente interno puede usar APIs existentes y algunas herramientas MCP. A2A se vuelve relevante cuando otro agente autónomo, posiblemente externo, debe colaborar. Una infraestructura de descubrimiento distribuida aparece cuando el número de actores y las fronteras lo requieren.

Este progreso evita construir un «Internet de agentes» para automatizar un solo flujo de trabajo.

Estándares al servicio de una gobernanza

Los protocolos abiertos mejoran la portabilidad y reducen las integraciones específicas. No reemplazan las elecciones de confianza, calidad y responsabilidad.

Partitech puede diseñar una arquitectura mínima, desarrollar servidores MCP, integrar A2A y evaluar los bloques de infraestructura agéntica. El objetivo es una interoperabilidad útil, comprobable y segura, no una acumulación de estándares.

Hablemos de su proyecto

Definir una arquitectura agéntica interoperable y gobernada con Partitech. Contacte a Partitech.

Compartir este artículo