Protocolos de agentes AI: MCP, A2A, ACP y AG-UI

Respuesta rápida

MCP, A2A, ACP y AG-UI no se reemplazan directamente. Resuelven límites distintos dentro de un sistema de agentes.

Protocolo	Problema principal	Límite típico
MCP	Cómo una app AI se conecta a herramientas, datos, prompts y contexto	Host/agente a servidor de herramientas o recursos
A2A	Cómo un agente delega trabajo a otro	Tareas agente a agente
ACP	Cómo exponer agentes como servicios interoperables	Interoperabilidad de servicios de agentes
AG-UI	Cómo un agente transmite estado y acciones a la UI	Backend de agente a frontend

En producción, la pregunta no es "¿cuál gana?", sino "¿qué límite queremos estandarizar?".

Por qué importan

Los sistemas tempranos de agentes suelen tener llamadas a herramientas, eventos de UI y delegación codificados dentro de una app. Sirve para prototipos, pero se vuelve frágil con varios equipos, herramientas, proveedores y frontends.

Los protocolos separan responsabilidades:

Herramientas y datos se exponen sin reescribir el agente.
Los agentes delegan sin revelar implementación interna.
Los frontends muestran progreso, herramientas y estados intermedios de forma consistente.
Seguridad puede razonar sobre permisos y auditoría.

La clave es elegir el protocolo para el límite correcto.

MCP: herramientas y contexto

MCP, Model Context Protocol, conecta aplicaciones AI con herramientas y contexto externos. Un host puede descubrir herramientas, llamarlas, leer recursos y usar plantillas de prompt.

Usa MCP cuando:

Una app AI necesita consultar base de datos, filesystem, API, repositorio o sistema interno.
Las herramientas deben reutilizarse en varios clientes.
Quieres exponer recursos y prompts de forma estándar.
Schemas y permisos de herramientas deben ser explícitos.

MCP es fuerte en el límite "agente llama herramienta". No es un protocolo completo de orquestación multiagente ni define cómo renderizar estado en UI.

AI app / agent host
  -> MCP client
  -> MCP server
  -> database, file system, API, internal tool

Consideraciones:

Herramientas pequeñas y bien descritas.
Evitar escritura amplia.
Loguear llamadas y argumentos.
Tratar salidas como datos no confiables.
Versionar schemas.

A2A: colaboración entre agentes

A2A, Agent-to-Agent, se enfoca en colaboración. Un agente puede publicar capacidades y aceptar tareas de otro agente u orquestador.

Usa A2A cuando:

Varios agentes especializados colaboran.
Un planner delega trabajo.
Agentes pertenecen a equipos o servicios distintos.
Tareas largas requieren estado, artefactos y progreso.

A2A es fuerte en el límite "un agente delega a otro". No reemplaza MCP; un agente A2A puede usar MCP internamente.

Orchestrator agent
  -> A2A task request
  -> Specialist agent
  -> status updates and artifacts

Consideraciones:

Definir qué puede hacer cada agente.
Validar respuestas.
Usar timeouts y presupuestos.
Registrar ownership e historial de handoff.
Evitar loops de delegación.

ACP: servicios de agentes interoperables

ACP suele discutirse como Agent Communication Protocol y busca que agentes sean descubribles e interoperables como servicios. Implementaciones concretas pueden variar, pero el objetivo es exponer capacidades de forma predecible.

Usa enfoques tipo ACP cuando:

Los agentes deben comportarse como servicios de red.
Importa el descubrimiento de capacidades.
Diferentes runtimes o vendors deben interoperar.
Necesitas un límite de servicio, no una llamada de librería.

ACP se solapa conceptualmente con A2A. Evalúa la implementación concreta: formato, autenticación, ciclo de vida, streaming, SDK y governance.

AG-UI: eventos de agente a interfaz

AG-UI se enfoca en el frontend. Estandariza cómo un backend de agente transmite mensajes, llamadas a herramientas, cambios de estado, progreso y eventos relevantes para UI.

Usa AG-UI cuando:

Construyes una UI de asistente o copilot.
El frontend debe mostrar herramientas, pasos intermedios o progreso.
Usuarios deben aprobar acciones en la UI.
El estado del agente debe sincronizarse con React, Vue u otros frameworks.

AG-UI es fuerte en el límite "backend de agente habla con UI". No define el workflow interno ni el hosting de herramientas.

Agent backend
  -> event stream
  -> frontend UI
  -> user approval / input
  -> backend resumes

Consideraciones:

Mantener tipos de evento estables.
Separar estado visible de secretos internos.
Manejar reconexiones y streams parciales.
Hacer aprobaciones explícitas y auditables.
No dejar que eventos frontend salten permisos del servidor.

Cómo encajan

Los protocolos suelen complementarse:

User interface
  <-> AG-UI events
Agent application / orchestrator
  <-> A2A or ACP for agent collaboration
Specialist agent
  <-> MCP for tools, resources, and prompts
Business systems

Un sistema de soporte puede usar AG-UI para progreso y confirmación, A2A para delegar a un agente financiero y MCP para herramientas de órdenes, pagos y tickets.

Comparación

Dimensión	MCP	A2A	ACP	AG-UI
Límite	Agente a herramientas/contexto	Agente a agente	Servicio de agente	Agente a UI
Objeto	Tool, resource, prompt	Task, message, artifact	Capability, agent, message	Event, state, action
Mejor para	Integración de herramientas	Delegación	Interoperabilidad	Frontends interactivos
¿Reemplaza lógica de app?	No	No	No	No
¿Se combinan?	Sí	Sí	Sí	Sí
Riesgo	Herramientas demasiado poderosas	Delegación sin límites	Implementaciones divergentes	Fuga de estado o seguridad

Guía de decisión

Elige MCP si el problema principal es conectar herramientas o datos.

Elige A2A si un agente necesita delegar tareas a otro.

Elige ACP si agentes deben exponerse como servicios con discovery de capacidades.

Elige AG-UI si construyes una UI interactiva con progreso, aprobaciones y estado intermedio.

Errores comunes

Tratar protocolos como frameworks

Los protocolos definen límites de comunicación. No reemplazan orquestación, evaluación, seguridad, despliegue ni diseño de producto.

Usar multiagente para simples herramientas

Si el agente solo consulta una base o API, MCP puede bastar. No agregues delegación si el problema no la necesita.

Exponer demasiado

Un servidor de herramientas debe exponer operaciones estrechas. "Ejecutar SQL arbitrario" o "ejecutar shell" requiere control fuerte.

Confiar en salidas sin validar

La comunicación entre agentes necesita validación. Los artefactos devueltos son datos que deben revisarse.

Convertir eventos de UI en permisos

La aprobación en frontend es señal de interacción, no control de seguridad completo. El backend debe aplicar permisos.

Checklist de producción

Área	Preguntas
Autenticación	¿Quién puede llamar el endpoint?
Autorización	¿Qué tools, agents, tasks o acciones UI están permitidas?
Auditoría	¿Puedes reconstruir quién pidió qué?
Timeouts	¿Qué pasa si una herramienta o agente se queda colgado?
Presupuestos	¿Hay límites de modelo, tools y profundidad?
Validación	¿Inputs y outputs tienen schema?
Observabilidad	¿Los traces conectan UI, agente, tool y task?
Versionado	¿Puedes cambiar schemas sin romper clientes?

Resumen

MCP, A2A, ACP y AG-UI se entienden mejor como protocolos de límites. MCP estandariza herramientas y contexto, A2A colaboración entre agentes, ACP servicios interoperables y AG-UI eventos de frontend. Un sistema maduro puede usar varios, pero cada uno debe introducirse solo donde crea un límite más claro y seguro.