Integration used to be largely proprietary. Twenty years ago, connecting two enterprise systems often meant buying a middleware stack and staying bought. Connectors were vendor-specific, and teams repeated much of the integration work for each project.
Then the interfaces opened up. SOAP and WSDL, backed by incumbents such as IBM and Microsoft. REST, emerging from the architecture of the web. The incumbents helped standardize integration to grow the market. In publishing the interface contract, they exposed part of what had been their moat.
That gave open source more room to compete. Mule, ServiceMix, Camel, Spring Integration. Standard interfaces gave these projects common ground to build on, and the open-source layer helped shift deployment choice from the vendor to the buyer.
We are seeing a similar cycle again, and we may be further along than it feels.
2023 and 2024 were largely the proprietary phase of AI integration. Providers had their own plugin formats and tool contracts. Then Anthropic published MCP, and Microsoft, OpenAI and Google adopted it. The interface between an AI system and the tools it uses now has a common, open protocol, once again backed by the dominant players.
And the open source harness layer is appearing right on cue. Runtimes for deploying and governing MCP servers, local orchestration, policy and audit around tool access.
Once the interface is standard, more of what sits behind it becomes a deployment choice rather than a vendor decision.
A Camel route could connect to a mainframe, a SOAP service or a REST API through a common integration framework. That abstraction gave the buyer leverage. Something similar is becoming possible in AI. MCP standardizes tool access; the orchestration layer can then route work between local models and frontier models without rebuilding every integration. Their capabilities still differ, but the surrounding application need not be tied to one provider.
That is becoming more practical. Many decisions inside production pipelines don’t need text generation; they need a label, a score, or a typed answer. Models designed specifically for these decisions are emerging, while smaller models offer a path to running suitable tasks locally. These approaches are early, and benchmark results need testing against real workloads.
The architectural implication is what matters: if much of a workflow can be handled locally, the frontier model need not be the substrate your system runs on. It can be the escalation path for the share of work that genuinely needs it. Frontier models may still be the best choice for designing systems and writing code, without being essential to every runtime decision or interaction with enterprise systems.
This changes the sovereignty argument.
Much of the sovereign AI discussion in Canada and Europe has focused on frontier-scale infrastructure, financed by governments or telcos. But if a substantial share of production decisions can run locally behind standard interfaces, sovereignty becomes as much an architecture problem as a capital problem. It comes down to control of the harness: the connectors, the routing, the governance, the audit trail, and what is permitted to leave your perimeter. A health authority can own that. Building and sustaining a frontier model is beyond the reach of almost every individual institution.
The irony is that the frontier labs helped make this possible. By opening the interface, they made more room for local, open-source, and sovereign deployment, just as the last generation of vendors did.
One open question, and I lived through the last version of it: WS-* became increasingly complex as more legitimate concerns were pushed into the standards, until the standards themselves became part of the problem. Does MCP stay simple, or does it go the same way?
Author Profile:
Praveen Ramachandran is co-founder and director of AOT Technologies, with over two decades of experience in system integration, application modernization, and reusable software. His work and thought leadership focus on helping enterprises and governments build scalable, adaptable and secure systems.