JA José Azcona
← Volver al blog
24 de abril de 2026 IA agénticaintegraciónMCPA2AMuleSoftarquitectura

Tu arquitectura de integración no está preparada para lo que viene

Read this article in English

Llevas años diseñando flujos. Definiendo secuencias. Programando transformaciones campo a campo. Y funciona.

Pero el consumidor de tus integraciones está a punto de cambiar. Ya no es una aplicación que ejecuta lo que le dices. Es un agente de IA que razona, decide y actúa por su cuenta.

Y eso lo cambia todo.

El flujo ha muerto. Larga vida a la tool

En el paradigma tradicional, tú diseñas el flujo: paso 1, paso 2, transformación, paso 3. El sistema ejecuta. Predecible. Controlado. Lento.

Un agente no necesita tu flujo. Necesita operaciones que pueda invocar. Necesita saber qué hace cada una, qué entrada espera y qué devuelve. El resto lo pone él.

La unidad fundamental deja de ser el flujo de integración. Pasa a ser la tool: una operación con un contrato semántico que el agente entiende, expuesta mediante MCP (Model Context Protocol), el estándar abierto que define cómo los agentes descubren e invocan operaciones.

Dejas de diseñar cómo se comunican los sistemas. Empiezas a diseñar qué capacidades están disponibles.

Del flujo prediseñado a la tool invocable: en el paradigma tradicional el arquitecto diseña el flujo, el desarrollador programa las transformaciones y el sistema ejecuta una secuencia fija con resultado predeterminado; en el paradigma de agentes, el agente razona sobre el objetivo y combina tools según el contexto, con orquestación dinámica en tiempo de ejecución.

Pero cuidado: el agente no lo resuelve todo

Aquí es donde se queda corta la mayoría de narrativas sobre agentes. Te cuentan que el agente orquesta, decide y transforma datos. Cierto. Pero nadie te cuenta qué pasa cuando el agente crea un cliente en el Sistema A, intenta crearlo en el Sistema B, falla… y te deja un estado inconsistente entre dos sistemas de registro.

Eso no lo arregla ningún LLM.

La consistencia transaccional entre sistemas sigue siendo necesaria. Lo que cambia es dónde vive. Ya no vive en el flujo, porque no hay flujo. Vive dentro de cada operación que la necesita.

Si una operación escribe en varios sistemas y la inconsistencia tiene impacto económico o legal, esa operación debe implementar internamente los mecanismos de consistencia que necesite — saga pattern, compensación a nivel de paso — y el agente no ve nunca los detalles técnicos. Solo recibe «éxito» o «fallo con los datos necesarios para que decidas a nivel de negocio».

Si el agente tiene que razonar sobre compensaciones parciales, el diseño está mal.

La clave es una separación limpia. El agente decide qué hacer y cuándo. La implementación de cada tool resuelve cómo hacerlo internamente — incluyendo transaccionalidad, compensaciones y reintentos. La frontera es el contrato de respuesta: el agente recibe resultados de negocio, nunca detalles técnicos de una transacción distribuida.

Y esa transaccionalidad dentro de cada operación se apoya en mecanismos concretos: saga pattern, compensaciones por paso, idempotencia garantizada. El agente no ve nada de esto. Solo ve el resultado.

Dónde vive la transaccionalidad y dónde no: vive dentro de cada tool que la requiere, nunca en el agente ni en la orquestación. Contrato correcto — la tool devuelve estado fallido con un motivo de negocio y el agente decide buscar el cliente existente. Contrato incorrecto — la tool devuelve estado parcial con detalle de qué sistema falló y si se compensó, obligando al agente a gestionar la transacción.

Separación entre orquestación de negocio y orquestación técnica: el agente decide qué operación ejecutar, cuándo, en qué orden y qué hacer ante un error de negocio; la implementación resuelve cómo se ejecuta internamente, la transaccionalidad y el saga pattern, las compensaciones ante fallo y los reintentos técnicos.

Esa separación se materializa en dos tipos de tool

Granular — lectura o escritura simple en un único sistema. El bloque básico. El punto de partida.

Process — operación transaccional sobre varios sistemas. Consistencia interna garantizada, compensación a nivel de paso, idempotencia. La pieza que resuelve la transaccionalidad donde importa.

El agente las invoca igual, vía MCP. La diferencia está en el contrato de respuesta y en quién gestiona la complejidad. La implementación resuelve la transaccionalidad internamente; el agente toma decisiones de negocio a partir del resultado.

La idempotencia es un requisito en ambos tipos: si el agente invoca dos veces con los mismos parámetros, el resultado debe ser equivalente a una sola invocación.

Dos tipos de tool: la granular actúa sobre un único sistema de registro, con transaccionalidad local y errores recuperables; la process abarca varios sistemas como unidad de negocio, con saga pattern interno, transformaciones codificadas y compensaciones definidas para cada paso.

No necesitas anticipar desde el principio cuáles serán process tools. Empiezas granular. La observabilidad te dice cuándo evolucionar.

Empieza pequeño. Itera rápido

No intentes diseñar el catálogo completo desde el día uno. Arranca con un MVP: un dominio de negocio, tools granulares, observabilidad desde el principio — si no puedes reconstruir qué decidió el agente y por qué, estás ciego — y un proceso de reconciliación para cuando algo falle.

Después, deja hablar a los datos. ¿El agente combina siempre las mismas tools de escritura? ¿Aparecen inconsistencias en pruebas? ¿Cuesta más reconciliar que implementar la consistencia interna? Esas son las señales que te dicen qué tool granular debe convertirse en process.

Un ejemplo concreto. Dominio de Cliente. MVP con 6 tools granulares independientes. La observabilidad revela que create_systemA y create_systemB se usan siempre juntas y que, cuando una falla, aparece inconsistencia. Siguiente iteración: una process tool create_customer_all_systems con transaccionalidad interna. Las dos granulares se retiran. De 6 tools a 5, pero con consistencia garantizada.

El catálogo evoluciona. No se rediseña.

El catálogo híbrido como destino de la arquitectura: en el MVP, seis tools granulares independientes sin transaccionalidad entre sistemas; en la iteración, las señales de observabilidad marcan create_systemA y create_systemB como deprecadas y se incorpora la process tool create_all_systems; en la madurez, cinco tools con consistencia garantizada por saga interno y granulares allí donde no hay señal de migración.

Criterios de clasificación entre tool granular y process: si la operación escribe en más de un sistema y la inconsistencia tiene impacto económico, legal u operativo inmediato, es process desde el diseño inicial; si la reconciliación es viable, puede seguir siendo granular con posible migración posterior.

Y esto no va de teoría. Va de plataforma

Puedes diseñar la arquitectura más elegante del mundo. Si no tienes gobierno, seguridad y trazabilidad desde el primer día, no sirve de nada.

MuleSoft Agent Fabric resuelve exactamente eso, con cuatro pilares: Registry para catalogar tools y agentes. Broker para orquestar entre agentes. Governance con Flex Gateway para autenticación, autorización y políticas MCP/A2A en cada interacción. Visualizer para ver en tiempo real qué decide cada agente, qué invoca y qué ocurre.

No es desarrollo. Es configuración. Desde el día uno.

Agent Fabric: gobierno, seguridad y observabilidad desde el primer día, con cuatro pilares — Agent Registry para descubrir y catalogar, Agent Broker para orquestar, Agent Governance con Flex Gateway y políticas MCP y A2A nativas, y Agent Visualizer para observar y trazar las decisiones de cada agente.

Lo que viene: la red de agentes

Hoy es un agente con sus tools. Mañana son agentes de ventas, operaciones y finanzas hablando entre ellos vía A2A (Agent-to-Agent, el protocolo de comunicación entre agentes), cada uno con su catálogo de tools, cada uno tomando decisiones.

Todo lo que resuelvas hoy — seguridad, trazabilidad, gobierno, transaccionalidad — se multiplica en un escenario multiagente. La arquitectura es la misma. Lo que cambia es la escala.

Y está pasando más rápido de lo que crees.

Evolución de un agente a una red de agentes: hoy un agente con sus tools, un punto de orquestación, un catálogo y un perímetro de seguridad; mañana una red de agentes especializados de ventas, operaciones y finanzas comunicándose por A2A, con múltiples puntos de orquestación, catálogos segmentados y perímetros cruzados.

Esto es una tesis, no una verdad revelada. Pero la alternativa a empezar no es esperar. Es quedarse atrás.

Referencias

Escrito por José Miguel Azcona Padín · Málaga · más artículos

Las opiniones expresadas en este artículo son personales del autor y no representan la posición de ningún empleador, actual o anterior. El contenido es de elaboración propia y no incluye información confidencial de empresas ni de clientes.