Cómo MCP y A2A cambian el diseño de la automatización con IA

Respuesta rápida

MCP y A2A hacen que la automatización con IA se parezca menos a escribir prompts y más a diseñar conexiones. MCP trata el acceso a herramientas y datos. A2A trata los traspasos entre agentes. En producción siguen mandando permisos, logs, aprobaciones, excepciones y responsabilidad.

Puntos clave

MCP encaja con el acceso de agentes a herramientas y datos.
A2A encaja con el traspaso de trabajo entre agentes especializados.
La interoperabilidad reduce fricción técnica, pero no elimina la responsabilidad operativa.
Conviene empezar por lectura y borradores antes de permitir acciones aprobadas.
Los criterios de fallo aparecen cuando se pierde dueño, no hay logs o la acción no se puede revertir.

Ideal para: Responsables de producto, operaciones, planificación de servicios y seguridad que llevan automatización con IA a flujos reales.
Tema: Automatización
Última revisión: 15 jun 2026

Herramientas cubiertas

Model Context Protocol
Agent2Agent Protocol
Google ADK
OpenAI Agents SDK
Responses API

Mapa del flujo

Un mapa práctico para convertir esta guía en un flujo de automatización.

01 Entrada
Define primero la tarea repetida, los datos necesarios, el responsable y el criterio de éxito.
02 Paso de IA
Usa IA en pasos con límites claros: redacción, clasificación, resumen, enrutamiento o llamadas a herramientas.
03 Revisión humana
Mantén aprobaciones, excepciones, límites de coste y decisiones sensibles bajo revisión humana.
04 Salida
Convierte el resultado en una checklist, un prompt guardado, un SOP o una automatización monitorizada.

Herramientas del flujo

Model Context Protocol
Agent2Agent Protocol
Google ADK
OpenAI Agents SDK
Responses API

Puntos de enfoque

MCP
A2A
automatización con IA
agentes de IA
automatización de flujos

Diagrama de automatización con IA con sistemas de negocio, conectores, traspasos entre agentes, aprobaciones, logs y excepciones — Añadir MCP y A2A no consiste solo en conectar más sistemas. El diseño debe decir qué solicitud va a qué herramienta, qué agente traspasa el trabajo y dónde termina un fallo.

Nota operativa

No conviertas una elección de herramienta en un atajo operativo.

Si la entrada, la revisión y el registro de errores no están claros, la automatización solo acelera el desorden.

Punto de decisión

Qué regla operativa sigue siendo válida aunque cambien las herramientas.

Ayuda a decidir dónde encajan MCP y A2A, dónde debe quedar la aprobación humana y cómo mantener visibles logs y excepciones.

Evidencia a revisar

8 Fuentes consultadas

Verifica funciones y precios cambiantes con las fuentes enlazadas y las páginas oficiales.

Primer movimiento

Comparativas

Empieza con un piloto pequeño y amplía solo cuando el punto de revisión esté claro.

Qué dejar claro antes del rollout

MCP encaja con el acceso de agentes a herramientas y datos.
A2A encaja con el traspaso de trabajo entre agentes especializados.
La interoperabilidad reduce fricción técnica, pero no elimina la responsabilidad operativa.
Conviene empezar por lectura y borradores antes de permitir acciones aprobadas.

Ruta de workflow

Dónde encaja esta guía

Usa esta sección para conectar la guía que estás leyendo con el workflow más amplio que apoya.

Decisiones de stack Elige el stack que encaja con la madurez operativa del equipo.

Una ruta para comparar plataformas de automatización, builders de apps, builders de agentes, contabilidad y asistentes de IA.

Abrir ruta de workflow

Mejor encaje: equipos que deciden entre comprar una herramienta simple, construir un flujo interno o adoptar una plataforma más amplia
No es ideal si: Necesitas instrucciones paso a paso más que un marco de decisión.

Después de ver varios intentos de automatización con IA, el prompt deja de ser el centro. Un modelo puede resumir un correo, clasificar un ticket, preparar una respuesta o sacar datos de un documento. Eso sirve. Pero el trabajo real empieza cuando el agente necesita mirar CRM, historial de pagos, tickets anteriores, políticas internas o registros de seguridad.

Ahí entran MCP y A2A. MCP se entiende mejor como la parte de acceso a herramientas y datos. A2A se entiende mejor como la parte de traspaso entre agentes. Suena técnico, pero en operación se vuelve bastante terrenal: quién puede leer, quién puede escribir, quién recibe el caso, quién aprueba y qué queda registrado.

Miro primero esas preguntas. No el nombre del protocolo. No la promesa del proveedor. Si al conectar más agentes el flujo queda menos explicable, la automatización se vuelve difícil de defender ante operaciones, soporte, finanzas o seguridad.

MCP y A2A no son la misma pieza

MCP resuelve una parte del acceso. Un agente necesita leer documentos, estado de clientes, historial de tickets, notas de producto o políticas internas. La idea es que esa conexión no dependa siempre de integraciones improvisadas.

A2A resuelve otra parte: cómo se pasan trabajo los agentes. Un agente de soporte detecta un problema de facturación y lo pasa a un agente de cobros. Un agente de seguridad encuentra una señal en logs y la pasa a uno de operaciones. Un agente de investigación reúne datos y otro prepara el informe.

Área	Pregunta inicial	Riesgo práctico
MCP	A qué herramientas y datos puede acceder el agente	Los permisos pueden crecer más de lo necesario
A2A	Qué agente recibe la siguiente parte del trabajo	La responsabilidad puede perderse entre traspasos
API tradicional	Qué regla dispara qué acción	Las reglas se vuelven frágiles con muchas excepciones
Revisión humana	Dónde se detiene el flujo	Sin criterio, la revisión se convierte en rehacer trabajo

Por eso no trataría MCP y A2A como simples funciones de productividad. Cambian la arquitectura del flujo.

De una lista de herramientas a un mapa de rutas

Muchos planes de automatización empiezan con una lista: correo, CRM, tickets, base de datos, constructor de flujos, canal de avisos. Esa lista sigue haciendo falta, pero ya no alcanza si los agentes pueden buscar contexto y traspasar tareas.

Hace falta un mapa de rutas. Debe decir qué entrada inicia el flujo, qué agente la lee primero, qué sistemas consulta, cuándo pasa el caso a otro agente, dónde entra una aprobación humana, dónde se guardan los logs y a qué cola va una excepción.

Pensemos en una queja de facturación. Un cliente dice que canceló el mes pasado, pero volvió a recibir un cargo. El agente de soporte lee el mensaje, abre un ticket y consulta CRM y pagos mediante MCP. Hasta ahí estamos en lectura. Si hay que emitir un reembolso, cambiar un contrato o prometer algo al cliente, cambia el riesgo. El caso puede pasar a un agente de facturación, pero con el motivo del traspaso, los datos revisados, lo que falta por confirmar y el umbral de aprobación.

El valor no está en que la respuesta suene elegante. El valor está en que el caso avance sin perder contexto.

Criterio práctico: primero límites, después conexiones

Si tuviera que llevarlo a producción, partiría el flujo en tres zonas.

La primera zona es solo lectura. Buscar en documentación, leer estado de cliente, resumir historial de tickets, consultar la política vigente, revisar logs. Aquí MCP puede ahorrar tiempo real, porque el agente reúne material que antes alguien abría a mano.

La segunda zona son borradores. Respuesta al cliente, nota interna, solicitud de aprobación, tarea, resumen operativo. Aquí la IA suele tener buen retorno. Pero el borrador debe traer evidencia. Si recomienda un reembolso, tiene que mostrar qué registro y qué regla usó.

La tercera zona es ejecución. Reembolsos, correos finales al cliente, cambios de permisos, despliegues, borrado de datos, cambio de estado de cuenta. Aquí iría despacio. A2A puede coordinar agentes, pero coordinar no significa aprobar. La ejecución necesita umbrales, logs, rollback, alertas y un responsable.

No lo elegiría como primer movimiento cuando la regla todavía vive en la cabeza de una persona, cuando cada equipo resuelve distinto o cuando una acción incorrecta cuesta mucho revertirla. En ese contexto, más conexión puede traer más trabajo de revisión.

Los ejemplos muestran dónde se rompe

En un flujo de leads, un agente recibe el formulario, busca datos de la empresa, revisa el historial en CRM, enriquece la cuenta y propone prioridad. MCP mejora la capa de consulta. A2A permite que un agente de investigación pase contexto a un agente comercial que prepara un borrador de correo.

El problema no es si el correo está bien escrito. El problema es si la prioridad refleja cómo vende la organización. Sector, presupuesto, cargo, contacto previo, campaña activa, encaje del producto y capacidad del equipo pesan a la vez. Si el equipo comercial no entiende el score, vuelve a revisarlo. Por eso deben quedar visibles el puntaje, los motivos, las razones de descarte y el siguiente paso.

En cierre financiero pasa algo parecido. Un agente puede reunir facturas, cruzar transacciones, sugerir categorías y marcar recibos faltantes. Pero la clasificación final, las excepciones y los cambios sensibles necesitan aprobación. Para auditoría o impuestos, “lo decidió la IA” no sirve como registro. Debe quedar la fuente, la regla aplicada y quién aceptó el resultado.

En seguridad el margen es menor. Un agente puede leer logs, detectar patrones raros y preparar acciones candidatas. Cambiar permisos o reglas de firewall automáticamente es otra categoría. Cuantas más herramientas puede usar un agente, más importantes son los permisos mínimos y la trazabilidad.

Criterios de fallo que sí importan

Un flujo conectado puede verse bien en la primera prueba y aun así fallar en operación. Yo miraría estas señales antes de ampliar autonomía.

Señal de fallo	Acción inmediata
Los agentes se pasan el mismo caso	Reducir rutas y nombrar un dueño final
El revisor no entiende la respuesta	Guardar llamadas a herramientas, fuentes y motivo del traspaso
La revisión no baja	Volver a lectura y borradores
Los permisos se expanden	Rehacer la tabla de mínimos por rol de agente
Las excepciones llegan tarde	Mover antes la cola de excepciones y las alertas
No hay rollback	Detener escrituras hasta tener recuperación y aprobación

La automatización más débil es la que solo se ve bien cuando todo sale bien. En operación debe ser legible cuando falla. Quién pidió el trabajo, qué herramienta se usó, por qué se traspasó, quién aprobó y dónde quedó el resultado.

La página que haría antes de construir

Antes de montar nada, haría una página.

Campo	Qué escribir
Entrada	Correo, formulario, ticket, documento, log o evento
Primer agente	Quién lee, clasifica y enruta
Herramientas MCP	Sistemas con lectura y escritura separadas
Traspaso A2A	Condiciones para pasar a otro agente
Aprobación humana	Importes, riesgos, clientes o acciones que deben detenerse
Logs	Llamadas, fuentes, motivo de traspaso, aprobador, resultado
Excepción	Cola o responsable para casos ambiguos o fallidos
Métrica	Tiempo ahorrado, retrabajo, error, intervención humana

Si esta página queda vacía, el flujo no está listo. Cambiar de modelo no lo arregla. Añadir otro agente tampoco.

MCP y A2A son importantes porque sacan la automatización con IA del terreno del prompt y la llevan al diseño del flujo. Eso es bueno. También exige más disciplina. Primero lectura, luego borradores con evidencia, después traspasos y finalmente ejecución con aprobación. Ese orden no es vistoso, pero evita errores caros.

Un orden de adopción más realista

No conectaría todos los sistemas en la primera semana. Elegiría primero un flujo de solo lectura: resumir historial de soporte, preparar investigación de leads o revisar datos para un informe operativo. La métrica no sería si la respuesta suena bien, sino si baja el tiempo de revisión de la persona responsable.

Después pasaría a borradores con evidencia. El agente no solo escribe; muestra fuentes, criterios descartados y puntos que una persona debe revisar. Si esa fase no reduce retrabajo, abrir una cadena amplia con A2A es prematuro.

La ejecución vendría al final y con aprobación. Importes, impacto en clientes, seguridad, borrado de datos y comunicación externa deben quedar como puntos de parada. En operación suele funcionar mejor diseñar primero dónde se frena el sistema y después ampliar lo que puede hacer.

Preguntas frecuentes

Qué debería mirar primero, MCP o A2A?

Si el problema es acceso a herramientas y datos, MCP. Si el problema es dividir roles entre agentes, A2A. En cualquier caso empezaría por lectura y borradores.

En qué se diferencia de una API tradicional?

La API tradicional suele seguir reglas fijas. MCP y A2A permiten que los agentes reúnan contexto y pasen trabajo. Eso da flexibilidad, pero también exige más trazabilidad, permisos y dueño claro.

Pueden los agentes ejecutar acciones finales?

Sí, pero lo reservaría para acciones reversibles y de bajo riesgo con logs y reglas de aprobación. Reembolsos, cambios de permisos, compromisos al cliente, borrados y despliegues deben esperar controles más maduros.