MCP-Led: semantic integration for enterprise systems

1. The problem

An integration flow is an actor who learned the script by heart.

As long as everyone says their line, the play works. But the moment somebody improvises, the actor has no answer. Or worse: carries on performing as if nothing had changed.

That is exactly what happens with many integrations. Before getting there, it helps to see where the problem comes from.

Companies run on heterogeneous ecosystems: ERPs, CRMs, e-commerce platforms, legacy systems and third-party SaaS. Connecting them has historically been expensive, fragile and hard to maintain.

Integration teams always face the same three dilemmas:

• Speed versus quality. The business needs integrations soon, but doing them properly takes time.
• Cost versus coverage. Automating everything up front is expensive and uncertain; doing everything by hand is unsustainable.
• Knowledge versus documentation. Understanding how an integration works lives in people, not in systems.

The root cause runs deeper than any of the three. For fifty years we have treated integration as a syntactic problem: moving data from A to B while honouring a technical contract. P2P, SOA, API-Led. Each generation solved the limitations of the one before it, but none went after the underlying problem.

Contracts describe the structure of the data, not its meaning.

This pattern frames it as a semantic problem: how to get systems to understand each other the way two people who know the business would.

Why previous paradigms fall short

Each generation solved the problems of the one before it and introduced its own.

Point to point. Direct connections, no contract, no reuse. It works with two systems and collapses with ten. Every connection is unique and lives in the head of whoever wrote it.

SOA. It pursued reuse through coarse-grained services with rigid contracts. The contract was verbose and only interpretable by machines configured in advance. Orchestration concentrated in the bus, which ended up being both a bottleneck and a single point of failure.

API-Led. It organised integrations into layers, with REST APIs as products and human-readable contracts. It improved reuse in a real way, but the focus was still the entity and the verb: the contract describes structure, not meaning. Whoever consumes the API has to know the domain in order to use it well.

What all three were missing is the same thing: an orchestrator that understands the business, not just one that follows technical rules.

2. An analogy from human behaviour

This pattern is not a technological invention. It is the digitisation of something people do naturally.

Think of your first day in a new job. At first you do the work by hand: you understand the context, make decisions and resolve exceptions. Over time you discover that one of those tasks always follows the same pattern. A moment comes when you think: this is worth automating. You write the procedure, and from then on the machine runs it for you.

The decisive difference lies in what happens next. The machine executes the procedure without understanding why it works. If the context changes, the person notices and adapts; the machine fails, or produces incorrect results without flagging them.

The pattern formalises that cycle: there is an agent that understands and an automation that executes, each in its own role.

3. The shift in the fundamental unit

Every integration paradigm has a different basic unit, and its orientation is summed up in that unit:

Paradigm	Unit of integration	Orientation
Point to point	Custom code	Technical
SOA	Service	Functional
API-Led	REST API (entity)	Product
MCP-Led	Tool (capability)	Semantic

In MCP-Led the unit is neither an entity like /accounts nor a service like CustomerService. It is a capability with meaning: replicate_customer, sync_invoice, get_account_health. The name expresses a business intent, not a technical structure.

4. The two types of integration

This is the distinction that holds up the rest of the pattern.

Semantic integration. The agent understands the meaning of what it handles:

This ERP customer identifier represents a company I must create in the CRM as a customer-type account. If it already exists, I must update it. The sector “IT” in the source is equivalent to “Technology” in the target, because both describe the same reality.

Syntactic integration. The automated flow reproduces the result:

customer_id     → source_customer_id
customer_name   → name
sector_code     → sector           (lookup: IT → Technology)
street + number → billing_street   (concatenate with a space)

The syntactic flow is efficient, deterministic and cheap. But it does not understand. If the source system changes the sector code from IT to TECH, the flow fails. The agent would have detected and resolved it.

The automated flow is the actor from the opening: it recites its part precisely, without understanding why it says it. It works perfectly as long as nobody improvises.

The practical consequence is not to choose one of the two, but to assign each its territory: understanding is flexible and expensive; repeating is rigid and cheap.

5. The architecture: channel adapters

Each system exposes its capabilities through an MCP server acting as a channel adapter. The two orchestrators sit on top of that layer.

                     REAL-WORLD SYSTEMS
                              │
                              │  expose their capabilities as
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                CHANNEL ADAPTERS (MCP servers)               │
│                                                             │
│   ERP MCP                  CRM MCP                          │
│   · get_customer           · query                          │
│   · post_invoice           · create_record                  │
│   · list_orders            · update_record                  │
│                                                             │
│   Integration MCP      ← generated by the system itself     │
│   · replicate_customer                                      │
│   · sync_invoice                                            │
│   · post_order                                              │
└───────────────────────────┬─────────────────────────────────┘
                            │
              ┌─────────────┴──────────────┐
              ▼                            ▼
    SEMANTIC ORCHESTRATOR        SYNTACTIC ORCHESTRATOR
    Understands the why          Repeats the what
    Flexible                     Efficient
    Expensive                    Cheap
    Universal                    Specific
    Handles exceptions           Follows the happy path

The system adapters expose low-level operations. The integration adapter —the last item on the list— is written by nobody: the system generates it itself as it learns, and it is the end result of the cycle described below.

6. The three agents

The broker: chooses the path

Its responsibility is a single one: determining the route each integration event takes. It executes no business logic and transforms no data. It only answers one question: do I know how to do this automatically?

Its behaviour:

1. It receives the integration event.
2. It classifies its type (Customer.Replicate, Invoice.Post…).
3. It queries the flow registry.
4. If a flow exists, it delegates to the automated layer: syntactic orchestration.
5. If none exists, or if it fails, it delegates to the executor: semantic orchestration.
6. It watches the system: if the same event repeatedly goes through the executor without a flow being generated, it raises an alert.

The executor: understands and acts

Its responsibility is twofold: executing any integration with real business understanding and documenting exactly what it did so it can be replicated.

Its behaviour:

1. It receives the event from the broker.
2. It understands the content and its business context.
3. It executes the integration with the available tools: it searches the target before creating in order to avoid duplicates, maps the fields using domain judgement, writes the result and handles errors by reasoning about them.
4. It generates the integration specification, which crystallises what it has understood.
5. It signals that a flow is pending development.

It is the semantic orchestrator: it decides in the face of ambiguity, handles unforeseen exceptions and reasons about the business.

The development agent: crystallises

Its responsibility is turning the executor’s understanding into an automated flow, tested and deployed.

Its behaviour:

1. It receives the integration specification.
2. It generates the flow.
3. It generates the automated tests.
4. It validates and deploys.
5. It registers the flow in the catalogue.
6. When it accumulates enough flows between the same systems, it generates a new capability in the integration adapter.

It is the equivalent of the employee who one day decides to write the procedure. Only it does so in seconds.

7. The artefacts

The flow registry

The catalogue the broker queries on every event to know whether an automation is available:

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

The integration specification

This is the central piece of the pattern: understanding turned into procedure. It is the equivalent of the functional specification an analyst used to write, now generated automatically.

{
  "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": "Direct customer" },
    { "target": "record_source", "value": "ERP integration" }
  ],
  "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" }
  }
}

Two fields are worth pausing on. deduplication captures a business decision —how you identify that a customer already exists— that is usually written down nowhere. And test_data means the generated flow is born with its own test case, taken from the real execution that produced it.

The integration adapter

As validated flows accumulate between two systems, they are encapsulated in a specialised MCP server. Each tool represents a proven integration, expressed as a business capability:

ERP–CRM integration MCP
├── replicate_customer       ← customer_master → customer
├── sync_invoice             ← invoice         → invoice
├── post_order               ← sales_order     → contract
└── get_integration_status   ← status by correlation identifier

This is not one more API-Led layer. It is semantic integration distilled into tools whose names express business intent.

8. The life cycle of an integration

Unknown event: semantic orchestration

1. The ERP sends:  { customer_id: "0010012345", customer_name: "Ibertech..." }
2. Broker → flow registry: empty for this event type
3. Broker delegates to the executor
4. The executor understands: "this is a new customer, I must search before creating"
5. It deduplicates, maps using domain judgement and writes to the CRM
6. It generates the integration specification
7. It signals that a flow is pending development

Generation of the automation

1. The development agent receives the specification
2. It generates the flow: erp-customer-to-crm-account
3. It generates the tests using the specification's test data
4. It validates → deploys → registers it in the catalogue

Known event: syntactic orchestration

1. The ERP sends:  { customer_id: "0010099999", customer_name: "Acme Corp..." }
2. Broker → flow registry: DEPLOYED
3. The flow runs in milliseconds
4. No executor. No inference cost. No reasoning.

Maturity: emergence of the integration adapter

The development agent detects patterns in the registry:
  · erp-customer-to-crm-account      → 500 executions, stable
  · erp-invoice-to-crm-opportunity   → 230 executions, stable
  · erp-order-to-crm-contract        →  89 executions, stable

It generates the ERP–CRM integration MCP with those three capabilities.
The broker starts using it as its first option.
The executor is freed up for what is genuinely new.

9. How the system evolves

The system matures just as a human team that learns would.

Stage 1 — empty system. Everything goes through the semantic executor. High cost and full coverage. The first flows are generated.

Stage 2 — accumulation of automations. Known events go through the automated layer and the executor only handles what is new. Cost falls without anyone optimising anything.

Stage 3 — integration adapter. Flows are encapsulated as capabilities. The broker uses them as its first option and the executor is reserved for what has not been seen before.

The transitions are not decided by intuition: they are measured.

Transition	Indicator
Stage 1 → 2	First flow registered and validated
Stage 2 → 3	Three or more flows between the same systems with more than 50 stable executions
Alarm	The same event type repeatedly goes through the executor without a flow being generated

10. Governance and control

Control by environment

Automatic code generation cannot behave the same way in every environment:

Environment	Code generation	Deployment	Registration
Development	Active	Automatic	Automatic
Testing	Active	Automatic	Automatic
Production	Active	Requires approval	Requires approval

In production the pattern keeps generating understanding and specifications, but deployment goes through a person. What gets automated is the knowledge, not the decision to publish it.

Semantic degradation

This is the risk the pattern introduces, and it is worth taking on from the start. A syntactic flow can become obsolete without anyone noticing: the business changes, the systems evolve, and the actor carries on reciting a script that no longer represents reality.

Two signals give it away:

• A flow that recorded no errors starts failing: the source system has probably changed.
• The semantic executor handles an event type that already has a flow: the flow does not cover every case.

Either of the two should trigger a review of the corresponding integration specification. That problem is not solved by reacting in production: the mechanisms to detect it have to be designed in from the start. Without that vigilance, the system accumulates automations that no longer do what they should.

11. Comparison with previous paradigms

	Point to point	SOA	API-Led	MCP-Led
Contract	None	Rigid	Human-readable	Agent-interpretable
Orientation	Technical	Service	Entity / CRUD	Capability / action
Orchestrator	None	Service bus	API manager	Agent or flow
Reuse	None	Theoretical	By design	By understanding
Who understands the contract	The author	The architect	The developer	The agent
Exceptions	Manual	Configured	Configured	Reasoned
Evolution	Manual	Manual	Manual	Self-generated

The underlying difference is in the reuse row. In API-Led, reuse is achieved by design: someone has to anticipate it, document it and get others to adopt it. In MCP-Led it emerges by understanding: any agent capable of interpreting the contract can consume it without anyone having planned for it.

One important nuance: MCP-Led does not replace API-Led. The adapters are built on top of the existing APIs. It adds the semantic layer that was missing.

12. When not to apply this pattern

There are three scenarios in which the pattern is unnecessary or outright inadvisable:

• Integrations that are stable and known from the start. If you know exactly what to integrate and the domain is not going to change, it is better to design the flow directly. Understanding adds nothing where there is no ambiguity.
• Environments without reliable access to a model in production, with controlled latency and availability.
• Regulated domains where every decision must be auditable by a person. Semantic integration makes decisions whose reasoning is not always fully traceable.

13. Conclusion

The system stops depending on someone anticipating every integration. It understands, executes, documents what it has understood and generates the automation that will repeat it more cheaply. When it accumulates enough experience between two systems, it distils that into capabilities named after the business.

The interesting part is not that AI does the integration. It is that the cost comes down on its own, without anyone having to optimise the process. The system starts out expensive and flexible, because it is still learning. And it ends up cheap and rigid exactly where the knowledge has already settled.

Integration stops being written once and for all, and starts being learned.

---

The previous step in this line of reasoning —why the unit of integration stops being the flow and becomes the invocable tool— is in Your integration architecture is not ready for what’s coming.