MCP-Led: integración semántica para sistemas empresariales

1. El problema

Un flujo de integración es un actor que aprendió el guion de memoria.

Mientras todos dicen su frase, la obra funciona. Pero basta con que alguien improvise para que se quede sin respuesta. O peor: que siga actuando como si nada hubiera cambiado.

Eso es exactamente lo que ocurre con muchas integraciones. Y antes de llegar ahí conviene ver de dónde viene el problema.

Las empresas operan sobre ecosistemas heterogéneos: ERPs, CRMs, plataformas de comercio electrónico, sistemas heredados y SaaS de terceros. Conectarlos ha sido históricamente costoso, frágil y difícil de mantener.

Los equipos de integración se enfrentan siempre a los mismos tres dilemas:

• Velocidad frente a calidad. El negocio necesita las integraciones pronto, pero hacerlas bien lleva tiempo.
• Coste frente a cobertura. Automatizarlo todo desde el principio es caro e incierto; hacerlo todo a mano es insostenible.
• Conocimiento frente a documentación. El saber cómo funciona una integración vive en las personas, no en los sistemas.

La raíz es más profunda que cualquiera de los tres. Llevamos cincuenta años tratando la integración como un problema sintáctico: mover datos de A a B respetando un contrato técnico. P2P, SOA, API-Led. Cada generación resolvió las limitaciones de la anterior, pero ninguna atacó el problema de fondo.

Los contratos describen la estructura de los datos, no su significado.

Este patrón lo plantea como un problema semántico: cómo lograr que los sistemas se entiendan entre sí como lo harían dos personas que conocen el negocio.

Por qué los paradigmas anteriores no bastan

Cada generación resolvió los problemas de la anterior e introdujo los suyos.

Punto a punto. Conexiones directas, sin contrato y sin reuso. Funciona con dos sistemas y colapsa con diez. Cada conexión es única y vive en la cabeza de quien la escribió.

SOA. Buscó el reuso mediante servicios de grano grueso con contratos rígidos. El contrato era verboso y solo interpretable por máquinas configuradas de antemano. La orquestación se concentró en el bus, que acabó siendo cuello de botella y punto único de fallo.

API-Led. Organizó las integraciones en capas, con APIs REST como productos y contratos legibles por personas. Mejoró el reuso de forma real, pero el foco seguía siendo la entidad y el verbo: el contrato describe estructura, no significado. Quien consume la API debe conocer el dominio para usarla bien.

Lo que faltaba en los tres es lo mismo: un orquestador que entienda el negocio, no solo que siga reglas técnicas.

2. Una analogía del comportamiento humano

Este patrón no es una invención tecnológica. Es la digitalización de algo que las personas hacemos de forma natural.

Piensa en tu primer día en un puesto nuevo. Al principio haces las tareas manualmente: entiendes el contexto, tomas decisiones y resuelves excepciones. Con el tiempo descubres que una de esas tareas siempre sigue el mismo patrón. Llega un momento en que piensas: esto merece la pena automatizarlo. Escribes el procedimiento y, desde entonces, la máquina lo ejecuta por ti.

La diferencia decisiva está en lo que ocurre después. La máquina ejecuta el procedimiento sin entender por qué funciona. Si el contexto cambia, la persona lo detecta y se adapta; la máquina falla, o produce resultados incorrectos sin señalarlo.

El patrón formaliza ese ciclo: hay un agente que comprende y un automatismo que ejecuta, cada uno en su papel.

3. El cambio de unidad fundamental

Cada paradigma de integración tiene una unidad básica distinta, y en ella se resume su orientación:

Paradigma	Unidad de integración	Orientación
Punto a punto	Código a medida	Técnica
SOA	Servicio	Funcional
API-Led	API REST (entidad)	Producto
MCP-Led	Tool (capacidad)	Semántica

En MCP-Led la unidad no es una entidad como /accounts ni un servicio como CustomerService. Es una capacidad con significado: replicate_customer, sync_invoice, get_account_health. El nombre expresa una intención de negocio, no una estructura técnica.

4. Los dos tipos de integración

Esta es la distinción que sostiene el resto del patrón.

Integración semántica. El agente comprende el significado de lo que maneja:

Este identificador de cliente del ERP representa una empresa que debo crear en el CRM como cuenta de tipo cliente. Si ya existe, debo actualizarla. El sector «IT» en origen equivale a «Technology» en destino, porque ambos describen la misma realidad.

Integración sintáctica. El flujo automático reproduce el resultado:

customer_id     → source_customer_id
customer_name   → name
sector_code     → sector           (lookup: IT → Technology)
calle + número  → billing_street   (concatenar con espacio)

El flujo sintáctico es eficiente, determinista y barato. Pero no comprende. Si el sistema origen cambia el código de sector de IT a TECH, el flujo falla. El agente lo habría detectado y resuelto.

El flujo automático es el actor del principio: recita su papel con precisión, sin entender por qué lo dice. Funciona perfectamente mientras nadie improvise.

La consecuencia práctica no es elegir uno de los dos, sino asignar a cada uno su territorio: comprender es flexible y costoso; repetir es rígido y barato.

5. La arquitectura: adaptadores de canal

Cada sistema expone sus capacidades a través de un servidor MCP que actúa como adaptador de canal. Sobre esa capa se sitúan los dos orquestadores.

                     SISTEMAS DEL MUNDO REAL
                              │
                              │  exponen sus capacidades como
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                ADAPTADORES DE CANAL (servidores MCP)        │
│                                                             │
│   MCP del ERP              MCP del CRM                      │
│   · get_customer           · query                          │
│   · post_invoice           · create_record                  │
│   · list_orders            · update_record                  │
│                                                             │
│   MCP de integración   ← generado por el propio sistema     │
│   · replicate_customer                                      │
│   · sync_invoice                                            │
│   · post_order                                              │
└───────────────────────────┬─────────────────────────────────┘
                            │
              ┌─────────────┴──────────────┐
              ▼                            ▼
   ORQUESTADOR SEMÁNTICO         ORQUESTADOR SINTÁCTICO
   Entiende el porqué            Repite el qué
   Flexible                      Eficiente
   Costoso                       Barato
   Universal                     Específico
   Gestiona excepciones          Sigue el camino feliz

Los adaptadores de los sistemas exponen operaciones de bajo nivel. El adaptador de integración —la última pieza de la lista— no lo escribe nadie: lo genera el propio sistema a medida que aprende, y es el resultado final del ciclo que se describe a continuación.

6. Los tres agentes

El broker: decide el camino

Su responsabilidad es única: determinar la vía que sigue cada evento de integración. No ejecuta lógica de negocio ni transforma datos. Solo responde a una pregunta: ¿sé hacer esto de forma automática?

Su comportamiento:

1. Recibe el evento de integración.
2. Clasifica su tipo (Customer.Replicate, Invoice.Post…).
3. Consulta el registro de flujos.
4. Si existe flujo, delega en la capa automática: orquestación sintáctica.
5. Si no existe, o si falla, delega en el ejecutor: orquestación semántica.
6. Vigila el sistema: si un mismo evento pasa repetidamente por el ejecutor sin que se genere flujo, emite una alerta.

El ejecutor: comprende y actúa

Su responsabilidad es doble: ejecutar cualquier integración con comprensión real del negocio y documentar exactamente lo que hizo para que pueda replicarse.

Su comportamiento:

1. Recibe el evento del broker.
2. Comprende el contenido y su contexto de negocio.
3. Ejecuta la integración con las herramientas disponibles: busca en destino antes de crear para evitar duplicados, mapea los campos con criterio de dominio, escribe el resultado y gestiona los errores razonando sobre ellos.
4. Genera la especificación de integración, que cristaliza lo que ha entendido.
5. Notifica que hay un flujo pendiente de desarrollar.

Es el orquestador semántico: decide ante ambigüedades, gestiona excepciones no previstas y razona sobre el negocio.

El agente de desarrollo: cristaliza

Su responsabilidad es convertir la comprensión del ejecutor en un flujo automático, probado y desplegado.

Su comportamiento:

1. Recibe la especificación de integración.
2. Genera el flujo.
3. Genera las pruebas automáticas.
4. Valida y despliega.
5. Registra el flujo en el catálogo.
6. Cuando acumula suficientes flujos entre los mismos sistemas, genera una nueva capacidad en el adaptador de integración.

Es el equivalente al empleado que un día decide escribir el procedimiento. Solo que lo hace en segundos.

7. Los artefactos

El registro de flujos

El catálogo que el broker consulta en cada evento para saber si existe un automatismo disponible:

{
  "event_type": "Customer.Replicate",
  "flow_name":  "erp-customer-to-crm-account",
  "status":     "DEPLOYED",
  "created_by": "DevAgent",
  "tested":     true,
  "executions": 147,
  "last_error": null
}

La especificación de integración

Es la pieza central del patrón: la comprensión convertida en procedimiento. Equivale a la especificación funcional que antes redactaba un analista, generada ahora de forma automática.

{
  "event_type": "Customer.Replicate",
  "source": { "system": "ERP", "protocol": "OData", "entity": "customer_master" },
  "target": { "system": "CRM", "entity": "customer",   "operation": "UPSERT" },
  "field_mappings": [
    { "source": "customer_name",  "target": "name",           "transform": "direct" },
    { "source": "street+number",  "target": "billing_street", "transform": "concatenate(' ')" },
    { "source": "sector_code",    "target": "sector",         "transform": "lookup({'IT':'Technology'})" },
    { "source": "website",        "target": "website",        "transform": "prefix_if_missing('https://')" }
  ],
  "derived_fields": [
    { "target": "category",      "value": "Cliente directo" },
    { "target": "record_source", "value": "Integración ERP" }
  ],
  "deduplication": {
    "strategy": "UPSERT",
    "lookup_fields": ["source_customer_id", "name"]
  },
  "test_data": {
    "input":  { "customer_name": "Ibertech Solutions S.L.", "sector_code": "IT" },
    "expected_output": { "name": "Ibertech Solutions S.L.", "sector": "Technology" }
  }
}

Conviene detenerse en dos campos. deduplication recoge una decisión de negocio —cómo se identifica que un cliente ya existe— que normalmente no está escrita en ningún sitio. Y test_data hace que el flujo generado nazca con su caso de prueba, tomado de la ejecución real que lo originó.

El adaptador de integración

A medida que se acumulan flujos validados entre dos sistemas, se encapsulan en un servidor MCP especializado. Cada herramienta representa una integración probada, expresada como capacidad de negocio:

MCP de integración ERP–CRM
├── replicate_customer       ← customer_master → customer
├── sync_invoice             ← invoice         → invoice
├── post_order               ← sales_order     → contract
└── get_integration_status   ← estado por identificador de correlación

No es una capa más de API-Led. Es la integración semántica destilada en herramientas cuyo nombre expresa intención de negocio.

8. El ciclo de vida de una integración

Evento desconocido: orquestación semántica

1. El ERP envía:  { customer_id: "0010012345", customer_name: "Ibertech..." }
2. Broker → registro de flujos: vacío para este tipo de evento
3. Broker delega en el ejecutor
4. El ejecutor comprende: "es un cliente nuevo, debo buscarlo antes de crearlo"
5. Deduplica, mapea con criterio de dominio y escribe en el CRM
6. Genera la especificación de integración
7. Notifica que hay flujo pendiente de desarrollar

Generación del automatismo

1. El agente de desarrollo recibe la especificación
2. Genera el flujo: erp-customer-to-crm-account
3. Genera las pruebas con los datos de test de la especificación
4. Valida → despliega → registra en el catálogo

Evento conocido: orquestación sintáctica

1. El ERP envía:  { customer_id: "0010099999", customer_name: "Acme Corp..." }
2. Broker → registro de flujos: DESPLEGADO
3. El flujo se ejecuta en milisegundos
4. Sin ejecutor. Sin coste de inferencia. Sin razonamiento.

Madurez: emergencia del adaptador de integración

El agente de desarrollo detecta patrones en el registro:
  · erp-customer-to-crm-account      → 500 ejecuciones, estable
  · erp-invoice-to-crm-opportunity   → 230 ejecuciones, estable
  · erp-order-to-crm-contract        →  89 ejecuciones, estable

Genera el MCP de integración ERP–CRM con esas tres capacidades.
El broker pasa a usarlo como primera opción.
El ejecutor queda liberado para lo genuinamente nuevo.

9. La evolución del sistema

El sistema madura igual que lo haría un equipo humano que aprende.

Estadio 1 — sistema vacío. Todo pasa por el ejecutor semántico. Coste elevado y cobertura total. Se generan los primeros flujos.

Estadio 2 — acumulación de automatismos. Los eventos conocidos van por la capa automática y el ejecutor solo atiende lo nuevo. El coste decrece sin que nadie optimice nada.

Estadio 3 — adaptador de integración. Los flujos se encapsulan como capacidades. El broker las usa como primera opción y el ejecutor queda reservado para lo que no se ha visto antes.

Las transiciones no se deciden por intuición: se miden.

Transición	Indicador
Estadio 1 → 2	Primer flujo registrado y validado
Estadio 2 → 3	Tres o más flujos entre los mismos sistemas con más de 50 ejecuciones estables
Alarma	Un mismo tipo de evento pasa repetidamente por el ejecutor sin que se genere flujo

10. Gobierno y control

Control por entorno

La generación automática de código no puede comportarse igual en todos los entornos:

Entorno	Generación de código	Despliegue	Registro
Desarrollo	Activa	Automático	Automático
Pruebas	Activa	Automático	Automático
Producción	Activa	Requiere aprobación	Requiere aprobación

En producción el patrón sigue generando comprensión y especificaciones, pero el despliegue pasa por una persona. Lo que se automatiza es el conocimiento, no la decisión de publicarlo.

Degradación semántica

Este es el riesgo que el patrón introduce, y conviene asumirlo desde el principio. Un flujo sintáctico puede quedarse obsoleto sin que nadie lo advierta: el negocio cambia, los sistemas evolucionan, y el actor sigue recitando un guion que ya no representa la realidad.

Dos señales lo delatan:

• Un flujo que no registraba errores empieza a fallar: es probable que haya cambiado el sistema origen.
• El ejecutor semántico atiende un tipo de evento que ya tiene flujo: el flujo no cubre todos los casos.

Cualquiera de las dos debe disparar una revisión de la especificación de integración correspondiente. Ese problema no se resuelve reaccionando en producción: hay que diseñar los mecanismos para detectarlo desde el principio. Sin esa vigilancia, el sistema acumula automatismos que ya no hacen lo que deberían.

11. Comparativa con los paradigmas anteriores

	Punto a punto	SOA	API-Led	MCP-Led
Contrato	Ninguno	Rígido	Legible por personas	Interpretable por agentes
Orientación	Técnica	Servicio	Entidad / CRUD	Capacidad / acción
Orquestador	Ninguno	Bus de servicios	Gestor de APIs	Agente o flujo
Reuso	Ninguno	Teórico	Por diseño	Por comprensión
Quién entiende el contrato	El autor	El arquitecto	El desarrollador	El agente
Excepciones	Manual	Configurado	Configurado	Razonadas
Evolución	Manual	Manual	Manual	Autogenerada

La diferencia de fondo está en la fila del reuso. En API-Led el reuso se consigue por diseño: alguien debe anticiparlo, documentarlo y lograr que otros lo adopten. En MCP-Led emerge por comprensión: cualquier agente capaz de interpretar el contrato puede consumirlo sin que nadie lo hubiera previsto.

Un matiz importante: MCP-Led no sustituye a API-Led. Los adaptadores se construyen sobre las APIs existentes. Añade la capa semántica que faltaba.

12. Cuándo no aplicar este patrón

Hay tres escenarios en los que el patrón sobra o directamente está desaconsejado:

• Integraciones estables y conocidas desde el inicio. Si se sabe con exactitud qué integrar y el dominio no va a cambiar, conviene diseñar el flujo directamente. La comprensión no aporta nada donde no hay ambigüedad.
• Entornos sin acceso fiable a un modelo en producción, con latencia y disponibilidad controladas.
• Dominios regulados en los que cada decisión debe ser auditable por una persona. La integración semántica toma decisiones cuyo razonamiento no siempre es completamente trazable.

13. Conclusión

El sistema deja de depender de que alguien anticipe cada integración. Comprende, ejecuta, documenta lo que ha entendido y genera el automatismo que lo repetirá de forma más barata. Cuando acumula experiencia suficiente entre dos sistemas, la destila en capacidades con nombre de negocio.

Lo interesante no es que la IA haga la integración. Lo interesante es que el coste se reduce por sí solo, sin que nadie tenga que optimizar el proceso. El sistema empieza siendo caro y flexible, porque todavía está aprendiendo. Y termina siendo barato y rígido exactamente allí donde el conocimiento ya está consolidado.

La integración deja de escribirse una vez y para siempre, y pasa a aprenderse.

---

El escalón anterior de este razonamiento —por qué la unidad de integración deja de ser el flujo y pasa a ser la herramienta invocable— está en Tu arquitectura de integración no está preparada para lo que viene.