Guía de interoperabilidad de agentes de IA: arquitectura con MCP, A2A y AG-UI

Qué es la interoperabilidad de agentes de IA y cómo funcionan MCP, A2A y ACP. Guía práctica con ejemplos reales para equipos técnicos y CTOs.

Red de agentes de IA conectados con herramientas, contexto, protocolos y permisos

La interoperabilidad de agentes de IA se vuelve crítica cuando un agente útil deja de trabajar solo y debe descubrir capacidades, delegar tareas o usar datos fuera de su propio entorno. Sin contratos compartidos, cada conexión agrega lógica específica, dependencias y puntos de fallo.

El objetivo no es que cualquier agente confíe en cualquier otro, sino que sistemas distintos puedan colaborar con límites verificables. Esta guía separa las capas de MCP, A2A, ACP y AG-UI, muestra una arquitectura práctica y explica qué problemas todavía debe resolver el equipo. Hoy, los agentes forman parte de un panorama más amplio de tecnología inteligente aplicada a los negocios, donde la coordinación entre sistemas es tan importante como el modelo que los impulsa.

¿Qué es la interoperabilidad de agentes de IA?

Es la capacidad de agentes construidos con proveedores, modelos o frameworks distintos para descubrirse, intercambiar mensajes y coordinar trabajo mediante contratos comunes.

La integración conecta dos componentes concretos: por ejemplo, un agente de soporte llama a un endpoint interno para abrir un ticket. La interoperabilidad añade reglas reutilizables para que otros participantes entiendan capacidades, estados, artefactos y errores sin diseñar un adaptador nuevo para cada pareja. Una integración puede ser interoperable, pero una API aislada no lo es por sí sola.

Esta distinción mejora la comunicación entre agentes de IA sin borrar sus fronteras. Cada agente puede conservar su memoria, sus herramientas y su lógica propietaria; lo compartido es el contrato necesario para colaborar. Tampoco implica autonomía ilimitada: identidad, autorización y políticas siguen perteneciendo a la arquitectura.

Por qué es un problema real ahora

Los equipos están pasando de un asistente generalista a una fuerza de trabajo de agentes especializados: uno consulta inventario, otro prepara una propuesta y otro verifica condiciones. Si cada agente necesita enlaces directos con los demás, el número máximo de conexiones bidireccionales crece como N × (N - 1) / 2. Con cinco agentes hay diez pares posibles; con diez, cuarenta y cinco. Es una propiedad matemática, no una estimación de adopción.

El costo aparece en autenticación, formatos, reintentos, versiones y observabilidad repetidos. Una capa de protocolo reduce ese acoplamiento, aunque no elimina la integración con sistemas que carecen de interfaces estables.

Esto es distinto de RPA o un script. Un robot tradicional recorre una secuencia conocida y suele fallar si cambia la pantalla o el formato. Un agente interpreta contexto y puede elegir herramientas, pero esa flexibilidad introduce salidas no deterministas. Por eso necesita contratos de tarea, estados, límites de permisos y validaciones más explícitos, no menos ingeniería. Para el contexto de automatización, puede ampliarse en IA para automatizar procesos.

Comparación entre agentes de IA aislados y agentes conectados por protocolos, contexto y permisos
Los contratos comunes reducen conexiones específicas, pero no sustituyen seguridad ni gobierno.

Protocolos y estándares de agentes de IA

La comparación correcta es por capa. MCP, A2A y AG-UI pueden convivir en una misma solución; ACP debe evaluarse por su legado y su convergencia con A2A.

ProtocoloRelación principalQué estandarizaCuándo usarloLímite clave
MCPAgente o aplicación ↔ herramienta/datoRecursos, prompts, tools y negociación de capacidadesExponer sistemas y contexto con una interfaz comúnNo define colaboración completa entre agentes independientes
A2A / Agent2AgentAgente ↔ agenteDescubrimiento, tareas, mensajes, artefactos y estadosDelegar trabajo entre agentes opacos o de stacks distintosNo es framework, orquestador ni sustituto de MCP
ACPAgente ↔ agenteEnfoque REST y mensajería del proyecto BeeAIMantener o migrar implementaciones existentesSu desarrollo activo convergió con A2A; no elegirlo como estándar paralelo nuevo
AG-UIAgente ↔ interfaz/personaEventos, estado, streaming e interacción humanaMostrar progreso, pedir aprobación y manejar interrupcionesNo resuelve descubrimiento agente-agente ni acceso a datos

MCP: herramientas y datos con un contrato común

¿Qué es MCP? El Model Context Protocol es un protocolo abierto para que aplicaciones con modelos accedan a contexto y capacidades externas. La especificación oficial del protocolo MCP, consultada el 1 de septiembre de 2026, define hosts, clientes y servidores, usa mensajes JSON-RPC 2.0 y permite que un servidor exponga resources, prompts y tools.

Un agente de análisis podría usar un servidor MCP para consultar una base documental y otro para ejecutar una función de cálculo. El host conserva la orquestación y decide qué información entrega. MCP estandariza el enchufe; no garantiza que una tool sea segura, que sus datos sean correctos ni que el agente deba ejecutarla. La propia especificación exige consentimiento, control de acceso y tratamiento desconfiado de descripciones de herramientas.

A2A / Agent2Agent: delegación entre agentes

A2A trata al agente remoto como una unidad opaca capaz de aceptar tareas y devolver mensajes o artefactos. Una Agent Card describe en JSON su identidad pública, endpoint, habilidades, modalidades y esquemas de seguridad. El agente cliente puede descubrir una capacidad sin conocer el prompt, la memoria o las tools internas del proveedor.

Google presentó A2A el 9 de abril de 2025 y el proyecto pasó a la Linux Foundation el 23 de junio de 2025, según las referencias de IBM en español. Al 1 de septiembre de 2026, el sitio oficial de A2A lo describe bajo un comité técnico con representantes de varias compañías. Es una señal de gobernanza abierta, no prueba de compatibilidad automática: dos implementaciones aún deben coincidir en versión, extensiones, autenticación y semántica del dominio.

ACP y AG-UI: convergencia e interfaz humana

ACP nació en BeeAI como protocolo abierto de comunicación entre agentes, con convenciones HTTP/REST y operación asíncrona. Su situación cambió: la página de IBM sobre ACP, consultada el 1 de septiembre de 2026, advierte que ACP se fusionó con A2A bajo la Linux Foundation, que el equipo está cerrando el desarrollo activo y que los usuarios deben seguir rutas de migración. Por eso ACP conserva valor histórico y técnico, pero no debe presentarse como opción vigente equivalente para una arquitectura nueva.

AG-UI cubre otra frontera: la conexión bidireccional y basada en eventos entre un backend agéntico y una interfaz. Permite transmitir estado, resultados parciales, llamadas a herramientas e interrupciones para aprobación humana. Puede complementar A2A detrás del coordinador y MCP en los especialistas; no reemplaza ninguno.

Cómo se ve en la práctica

Flujo de solicitud, coordinación, especialización, verificación y resultado entre agentes de IA
Un flujo interoperable conserva contexto, delega trabajo y devuelve evidencia antes del resultado.

Consideremos un escenario ilustrativo basado en patrones de arquitectura, no un caso de cliente de HitOcean. Una empresa recibe una solicitud para preparar una propuesta de servicio. El agente coordinador valida alcance y deriva el análisis técnico a un especialista. Ese especialista usa MCP para leer requisitos autorizados y consultar una herramienta de estimación. Luego entrega un artefacto estructurado a un agente verificador mediante A2A.

El verificador contrasta supuestos, marca datos faltantes y devuelve estado y evidencia. Si el riesgo supera una política, AG-UI presenta la interrupción a una persona para aprobar, editar o rechazar. El resultado final conserva un identificador de tarea, fuentes utilizadas y decisiones de autorización. El patrón puede implementarse como desarrollo de software a medida, pero el protocolo no decide por sí mismo quién coordina ni qué política aprobar.

Desafíos abiertos

  • Memoria: compartir toda la conversación aumenta exposición y ruido. Conviene transferir contexto mínimo, versionado y con procedencia, no clonar memorias privadas.
  • Identidad y confianza: una Agent Card anuncia capacidades, pero debe existir autenticación fuerte, autorización por tarea y validación de la organización o workload que opera el agente.
  • Seguridad: prompt injection, tools maliciosas y escalamiento de privilegios pueden propagarse por la cadena. Cada salto debe tratar entrada, metadata y artefactos como no confiables.
  • Gobierno: hace falta asignar dueño, propósito, datos permitidos, retención, presupuesto y mecanismo de apagado a cada agente.
  • Observabilidad: una traza distribuida debe correlacionar solicitud, delegaciones, tool calls, costos, estados y revisión humana sin registrar secretos.
  • Estándares en evolución: las especificaciones y SDK cambian. Fijar versiones, ejecutar pruebas de contrato y aislar el protocolo detrás de adaptadores reduce el impacto.

La interoperabilidad resuelve sintaxis y parte del ciclo de trabajo; no crea una ontología compartida ni demuestra que dos agentes entiendan “prioridad” de la misma forma.

Cómo empezar

  1. Elegí un flujo acotado. Documentá entrada, salida, responsable, datos sensibles y condición de éxito antes de sumar protocolos.
  2. Dibujá fronteras. Separá interfaz, coordinador, especialistas, tools y sistemas de registro; identificá dónde cambia la identidad.
  3. Usá MCP para capacidades, no para disfrazar agentes. Si el componente ofrece una función o un dato bajo control del host, MCP suele ser la primera opción.
  4. Incorporá A2A cuando exista delegación real. Tiene sentido si el participante remoto administra su propia tarea, estado o artefactos y debe permanecer opaco.
  5. Combiná ambos solo donde aporte desacoplamiento. Un agente A2A puede usar servidores MCP internamente sin exponerlos al coordinador.
  6. Definí controles antes del piloto. Aplicá mínimo privilegio, credenciales de corta duración, allowlists, límites de gasto y aprobación para acciones irreversibles.
  7. Probá degradación y cambio. Simulá timeouts, respuestas inválidas, versiones incompatibles y revocación; medí éxito de tarea, latencia, costo y porcentaje de escalamiento humano.

Para equipos que todavía están delimitando autonomía, la guía de agentes inteligentes simples ayuda a separar reglas reactivas de agentes con planificación.

Conclusión

Una arquitectura interoperable no es una malla donde todo puede hablar con todo. Es un conjunto de fronteras explícitas: MCP equipa agentes con tools y datos; A2A permite delegar entre agentes; AG-UI conecta el trabajo con una persona; ACP orienta migraciones hacia A2A. El valor aparece cuando esos contratos se acompañan con identidad, políticas, trazas y pruebas.

Si el siguiente paso es revisar la arquitectura completa, conviene hacerlo antes de sumar otra conexión puntual.

¿Ya construiste agentes sueltos en tu operación y necesitás que hablen entre sí? Conversemos en una consultoría gratuita de IA.

Preguntas frecuentes

¿Qué es un agente de IA?

Un agente de IA es un sistema que recibe un objetivo, interpreta contexto, decide pasos y utiliza herramientas para producir un resultado dentro de límites definidos. Puede operar con reglas, modelos o ambos; llamarlo agente no implica que sea autónomo en toda situación.

¿Cuál es la diferencia entre MCP y A2A?

MCP estandariza cómo una aplicación o agente accede a herramientas, recursos y prompts. A2A estandariza cómo un agente descubre capacidades de otro, le delega una tarea y recibe estados o artefactos. Uno equipa al agente; el otro coordina agentes independientes.

¿Es posible la interoperabilidad entre proveedores hoy?

Sí, en alcances controlados y con implementaciones compatibles de los protocolos, pero no es automática. Hay que acordar versiones, esquemas de autenticación, semántica de datos, políticas y pruebas de contrato. Los estándares reducen adaptadores; no eliminan la ingeniería de dominio.

¿Qué es MCP y para qué sirve?

MCP es el Model Context Protocol, un estándar abierto para exponer herramientas y fuentes de contexto a aplicaciones con modelos mediante una arquitectura host-cliente-servidor. Sirve para reutilizar conectores y controlar qué capacidades externas puede invocar cada agente.

¿Interoperabilidad e integración son lo mismo?

No. Una integración une componentes específicos, a menudo con código punto a punto. La interoperabilidad usa contratos compartidos para que múltiples componentes colaboren sin rediseñar cada pareja. Toda solución interoperable necesita integraciones, pero no toda integración crea interoperabilidad.

¿Conviene elegir MCP, A2A o combinarlos?

Elegí MCP cuando el problema sea acceso a una herramienta o dato; A2A cuando un agente independiente deba aceptar y administrar trabajo delegado. Combinarlos es razonable si los agentes colaboran mediante A2A y cada especialista usa MCP para sus capacidades internas.

¿Querés aplicarlo en tu empresa?