MCP vs. A2A: lo que los equipos empresariales deben estandarizar antes de conectar agentes de IA

Conectar un agente de IA a un sistema de negocio es relativamente sencillo.

Conectar varios agentes a decenas de herramientas, fuentes de datos, proveedores, flujos de aprobación y procesos de negocio es donde la arquitectura empieza a fragmentarse.

Un equipo crea un conector personalizado para Salesforce. Otro construye una integración separada para SharePoint. Un proveedor implementa su propio agente con amplio acceso a la API. Un segundo agente empieza a delegar tareas al primero. Pronto, nadie puede explicar con claridad: qué agente puede acceder a qué datos; quién autorizó cada acción; qué sistema es responsable del resultado final; cómo se reintentan las tareas fallidas; si la misma acción puede ejecutarse dos veces; y cómo se puede revertir un cambio incorrecto.

MCP y A2A resuelven partes de este problema.

No lo resuelven por completo.

MCP puede estandarizar la forma en que una aplicación de IA accede a herramientas, recursos y prompts reutilizables. A2A puede estandarizar la forma en que agentes independientes se descubren entre sí, delegan trabajo, intercambian información y gestionan tareas. Ninguno de los dos protocolos define su proceso de negocio, su política de autorización, la propiedad de los datos, las reglas de aprobación ni el modelo de rendición de cuentas.

El protocolo es infraestructura.

El modelo operativo sigue siendo su responsabilidad.

Use cada protocolo para un tipo de relación distinto:

La arquitectura oficial de MCP define hosts, clientes y servidores, y los servidores exponen herramientas, recursos y prompts mediante un protocolo común. A2A está diseñado para la colaboración entre agentes independientes y potencialmente opacos, sin exigirles que revelen su memoria interna, su implementación o sus herramientas. (Model Context Protocol)

Son complementarios:

MCP equipa a un agente. A2A conecta ese agente con otros agentes.

Pero estandarizar la comunicación no hace que el sistema conectado sea correcto, seguro ni económicamente justificado.

Qué cambia realmente MCP

Antes de MCP, cada aplicación de IA solía necesitar una integración personalizada para cada capacidad externa: un conector para un CRM; otro para un repositorio de documentos; otro para una base de datos; otro para un servicio interno; y otro para un sistema de tickets.

Cada integración podía usar una autenticación, un manejo de errores, unos esquemas y una lógica de descubrimiento distintos.

MCP introduce un protocolo compartido mediante el cual un servidor puede exponer tres categorías principales: Herramientas - operaciones ejecutables; Recursos - datos de contexto que la aplicación puede leer; y Prompts - plantillas de interacción reutilizables.

Esto puede reducir la cantidad de código de integración específico de cada aplicación y facilitar el descubrimiento y la reutilización de capacidades. Sin embargo, el protocolo se centra de forma explícita en el intercambio de contexto y el acceso a capacidades; no define la lógica de negocio de la aplicación de IA ni cómo debe gobernar esas capacidades. (Model Context Protocol)

En la práctica

Un agente de operaciones de ingresos podría usar servidores MCP separados para buscar cuentas en el CRM; leer documentación de ventas aprobada; obtener reglas de precios de productos; crear una tarea en borrador; y solicitar una actualización del pipeline.

El agente no necesita un diseño de integración único para cada capacidad. Interactúa a través de una interfaz común.

Eso tiene valor.

Pero plantea una nueva pregunta:

¿Quién decide cuáles de esas capacidades debe recibir el agente?

MCP estandariza la conexión. No decide el modelo de permisos.

Qué cambia realmente A2A

A2A resuelve un problema distinto.

Una empresa puede tener varios agentes especializados: un agente de investigación de ventas; un agente de precios; un agente de revisión de cumplimiento; un agente de soporte al cliente; y un agente de entrega de proyectos.

Estos agentes pueden haber sido creados por equipos distintos, usar frameworks distintos o ejecutarse en plataformas de proveedores distintas.

A2A ofrece un modelo común mediante el cual los agentes pueden publicar sus capacidades; descubrir otros agentes; enviar y recibir mensajes; gestionar tareas colaborativas; devolver resultados estructurados o artefactos; y admitir interacciones síncronas, en streaming y de larga duración.

El protocolo está diseñado para que un agente pueda colaborar sin exponer su razonamiento interno, su memoria ni los detalles de su implementación. (A2A Protocol)

En la práctica

Un agente de ventas recibe una solicitud:

Prepare una propuesta para esta cuenta y verifique que los precios estén permitidos.

El agente de ventas puede usar MCP para obtener la cuenta y la oportunidad desde el CRM; delegar la verificación de precios a un agente de precios mediante A2A; recibir un artefacto de precios estructurado; delegar una revisión de políticas a otro agente; combinar los resultados aprobados; preparar un borrador de propuesta; y solicitar aprobación humana antes de cualquier comunicación externa.

Aquí, MCP y A2A resuelven capas de integración distintas.

User or business event
        ↓
Orchestrating agent
        ├── MCP → CRM tools and data
        ├── MCP → document repository
        ├── A2A → pricing agent
        │           └── MCP → pricing system
        └── A2A → policy-review agent
                    └── MCP → approved policy sources

La arquitectura es interoperable.

Todavía no está gobernada.

Lo que los protocolos dejan sin resolver

La mayoría de los planes de implementación pasan por alto esta distinción.

MCP y A2A no definen automáticamente lo siguiente.

Significado de negocio

Una herramienta puede exponer una operación llamada:

update_opportunity_stage

El protocolo no determina: qué significa cada etapa del pipeline; si los criterios de entrada y salida están documentados; quién es responsable de la oportunidad; si el cambio es financieramente significativo; ni si un gerente debe aprobarlo.

Una herramienta estandarizada puede ejecutar igualmente un proceso de negocio mal definido. La distinción entre agentes de IA y automatización es importante aquí: cuanta más autonomía tiene un sistema, con más claridad debe definirse el proceso subyacente antes de que cualquier protocolo lo conecte con datos de producción.

Rendición de cuentas

Si el Agente A delega trabajo al Agente B, ¿quién responde por un resultado incorrecto?

Las respuestas posibles incluyen al responsable de negocio del Agente A; al responsable de producto del Agente B; al equipo de plataforma; al empleado que inició la tarea; y al proveedor que opera el agente remoto.

El protocolo transporta la tarea. No asigna la responsabilidad gerencial.

Identidad empresarial

La autenticación demuestra que un sistema o usuario ha presentado una identidad válida.

La autorización determina qué puede hacer esa identidad.

La parte difícil es la correspondencia entre: el usuario humano; la aplicación que inicia la solicitud; el agente orquestador; el agente remoto; la credencial de la herramienta; y la operación de negocio final.

Un agente remoto no debería heredar privilegios amplios solo porque un orquestador de confianza se comunicó con él.

Política de aprobación

Un protocolo puede transportar una solicitud de aprobación.

No puede determinar qué acciones deberían requerir aprobación.

Eso depende de: el impacto financiero; la reversibilidad; las consecuencias para el cliente; la sensibilidad de los datos; la relevancia legal; las políticas para empleados o proveedores; y la confiabilidad del caso de uso específico.

Calidad de los datos

MCP puede facilitar el acceso a datos de CRM inexactos.

A2A puede facilitar que varios agentes propaguen el error resultante.

Ninguno de los dos protocolos resuelve: registros duplicados; políticas contradictorias; documentos obsoletos; responsables faltantes; métricas sin definir; ni reglas incorrectas sobre la fuente de verdad.

Expectativas de nivel de servicio

A2A puede admitir tareas de larga duración, pero la empresa todavía debe decidir: cuánto tiempo puede durar una tarea; cuándo se considera abandonada; qué ocurre después de un tiempo de espera agotado; si se puede usar un resultado parcial; cómo se cancela una tarea; y si es seguro reintentar la operación.

Economía unitaria

La interoperabilidad puede aumentar el número de interacciones entre agentes.

Una sola solicitud de negocio puede desencadenar: varias llamadas al modelo; múltiples operaciones de recuperación; tareas de agentes remotos; reintentos; llamadas de validación; y revisión humana.

Un flujo multiagente técnicamente exitoso puede seguir siendo irracional desde el punto de vista económico.

Lo que la empresa todavía tiene que estandarizar

Antes de conectar agentes en producción, defina la arquitectura en ocho capas.

Saltarse las capas superiores y empezar por los servidores, los SDK y los protocolos crea integración sin control. Nuestra guía para evaluar un agente de IA antes de producción ofrece un enfoque estructurado para reunir la evidencia y los criterios de aceptación que deberían existir antes de que cualquier arquitectura de agentes entre en funcionamiento.

Seguridad en MCP: la herramienta forma parte del límite de confianza

Un servidor MCP no es simplemente un conector neutral.

Sus definiciones de herramientas pueden influir en lo que el modelo cree que hace la capacidad. El servidor también puede recibir datos, ejecutar código, acceder a archivos o llamar a sistemas remotos.

La guía actual de seguridad de MCP de OWASP recomienda: acceso con el mínimo privilegio; credenciales separadas y con alcance limitado; validación de las entradas y salidas de las herramientas; aislamiento de los servidores; confirmación para acciones destructivas o sensibles; registro centralizado; verificación del origen y las dependencias de los servidores; y protección contra cambios en las definiciones de herramientas. (OWASP Cheat Sheet Series)

Un diseño riesgoso

Un servidor MCP recibe: administración completa del CRM; acceso a la unidad compartida; permiso para enviar correos; credenciales de facturación; y acceso irrestricto a la red.

Luego, mediante su prompt, se le indica al agente que "use esto con responsabilidad".

El prompt está funcionando como el principal límite de seguridad.

Eso no es suficiente.

Un diseño más seguro

Las capacidades están separadas: crm.read_account; crm.create_update_draft; crm.apply_approved_update; email.create_draft; email.send_approved_draft; y billing.read_invoice_status.

Cada operación tiene: un esquema acotado; un efecto secundario explícito; credenciales con alcance limitado; validación; un evento de auditoría; y una política de aprobación cuando corresponde.

El modelo puede elegir entre capacidades seguras.

No recibe autoridad irrestricta con la petición de que se autorregule.

Seguridad en A2A: la delegación no debe ampliar la autoridad

La arquitectura multiagente introduce la transitividad de la confianza.

El Agente A tiene permiso para realizar una tarea.

El Agente A llama al Agente B.

El Agente B llama a una herramienta o a otro agente.

Una suposición común pero peligrosa es:

Como el Agente A era de confianza, todo lo que delega también debería serlo.

Eso puede ampliar los privilegios más allá de la autoridad del usuario original.

Un contrato de delegación más sólido debería incluir: la identidad que inicia la solicitud; el propósito de negocio; el alcance permitido; la clasificación de datos admitida; el vencimiento de la tarea; el estado de aprobación; el costo o esfuerzo máximo; el artefacto esperado; y la prohibición de seguir delegando, cuando corresponda.

Cada participante posterior en la cadena debería permanecer dentro del límite de confianza original.

Evite ejecuciones duplicadas e irreversibles

Los sistemas de agentes suelen operar sobre infraestructura asíncrona.

Los mensajes pueden reintentarse. Las conexiones pueden fallar después de que una operación se completa con éxito. Es posible que un cliente no sepa si la acción remota se completó.

Esto crea un problema crítico:

Reintentar la tarea puede repetir la acción de negocio.

En operaciones de lectura, esto puede ser inofensivo.

En reembolsos, pedidos, mensajes a clientes, cambios de acceso o actualizaciones del CRM, puede provocar un incidente material.

El diseño de producción debería incluir identificadores únicos de tareas y operaciones; claves de idempotencia; estados de tarea explícitos; confirmación de los efectos secundarios; separación entre preparación y ejecución; aprobaciones vinculadas a parámetros; y acciones compensatorias para los cambios reversibles.

Un estado de "agente completado" no es suficiente.

El sistema debe saber qué operación de negocio se completó.

¿API, webhook, MCP o A2A?

No toda integración debe usar el protocolo más reciente.

Regla práctica

Use la arquitectura menos compleja que cumpla el requisito.

Un webhook no queda obsoleto porque exista MCP.

Una API directa no es inferior porque exista A2A.

No se debe crear un segundo agente solo para que el sistema parezca más agéntico.

Lista de verificación para la implementación empresarial

Antes de permitir tráfico MCP o A2A en producción, confirme:

En qué se resume la decisión

La cuestión estratégica es más amplia que:

¿Deberíamos adoptar MCP o A2A?

La mejor secuencia es: ¿Qué proceso de negocio estamos cambiando? ¿Requiere que el agente acceda a herramientas, que colabore con otros agentes, o ambas cosas? ¿Cuál es la arquitectura mínima que puede resolverlo? ¿Qué límites de confianza cruzará la arquitectura? ¿Qué controles quedan fuera del protocolo? ¿Cómo demostrará la empresa que el nuevo diseño es más seguro o más económico que el proceso actual?

MCP y A2A pueden reducir la inconsistencia en las integraciones.

También pueden facilitar que un proceso poco claro se conecte a más sistemas a mayor velocidad.

Estandarice el proceso, las responsabilidades, la identidad, los permisos, las aprobaciones y el modelo de auditoría antes de estandarizar la capa de comunicación.

La consultoría en IA y automatización de procesos abarca el diseño de la arquitectura de agentes, desde el mapeo de procesos y los límites de confianza hasta la identidad, los permisos y los controles de producción, antes de conectar los protocolos a sistemas en vivo.

Solicite un diagnóstico gratuito para evaluar qué tan preparada está su integración de agentes y definir el modelo operativo que su arquitectura todavía necesita.