Figure 1 – From TCP/IP to MCP: The Evolution of Interoperability. From connecting computers and networks to integrating applications, knowledge and intelligent agents, each technological generation has introduced new mechanisms for interoperability. The evolution of AI is part of this longer architectural transformation.

Before AI Agents, We Had Protocols

There is something strangely familiar about the current evolution of artificial intelligence.

In the late 1980s and early 1990s, I was working with technologies and communities that were helping shape what would eventually become the modern Internet. Unix systems, distributed computing, emerging networking protocols, early information retrieval services and the first implementations of the World Wide Web were part of an extraordinary period of technological experimentation.

Through my involvement in technical communities, including the IETF environment and the broader Unix, GNU, and Open ecosystem, I witnessed a recurring tension between proprietary architectures and the need for interoperability.

Different vendors developed their own systems, interfaces and technological ecosystems. Each promised integration, performance and reliability. Yet the real transformation came when previously isolated systems became capable of communicating through shared protocols.

TCP/IP demonstrated the power of open networking protocols. HTTP and the early Web showed how a relatively simple architectural approach could connect information distributed across heterogeneous systems.

And the evolution of APIs, from earlier distributed computing interfaces to today’s web services, progressively changed how applications could expose and consume capabilities.

The underlying lesson was not that one technology had defeated all the others.

It was that interoperability could create more value than technological isolation.

I remember working with early Internet technologies such as Gopher, WAIS and the emerging Web, when the eventual dominance of HTTP and web-based architectures was far from obvious.

At the time, we were not simply discussing which technology was technically superior. We were exploring how information could be discovered, accessed and exchanged across systems developed by different organisations.

Three decades later, I see a remarkably similar discussion emerging around artificial intelligence.

We are once again surrounded by competing technological ecosystems.

Amazon offers Bedrock. Microsoft has Foundry. Google provides Vertex AI. Oracle is integrating generative AI into OCI. Meanwhile, OpenAI, Anthropic, Meta, Mistral and DeepSeek are developing increasingly sophisticated models.

New intermediary technologies such as OpenRouter, LiteLLM and Portkey are attempting to simplify access to those models.

And the Model Context Protocol, or MCP, is introducing a common approach for connecting AI applications to external tools and information sources.

The technologies are different, and the challenges are certainly more complex. Artificial intelligence introduces questions of autonomy, reasoning, accountability and institutional responsibility that traditional networking protocols were never designed to address.

But the architectural tension is familiar.

Who defines the interfaces? Who controls access? Who establishes the standards? And who ultimately captures the value created by interoperability?

During the early development of the Internet, open protocols helped prevent communication from remaining confined within isolated proprietary networks.

Today, the challenge is whether organisations can build intelligent systems without surrendering control of their knowledge, processes and decision-making capabilities to a small number of technological platforms.

The question is no longer simply how to connect computers, applications or databases.

It is how to connect intelligence.

And perhaps the most important lesson from the history of the Internet is that the architecture of those connections will shape the distribution of power for decades to come.

1. The New Enterprise AI Stack

For the past few years, the public debate around artificial intelligence has been dominated by a relatively simple question: which AI model is the most powerful?

OpenAI, Anthropic, Google, Meta, Mistral and DeepSeek have competed to develop increasingly sophisticated Large Language Models (LLMs), capable of understanding language, generating software, analysing documents and performing complex reasoning tasks.

The competition has been measured through benchmarks, model parameters, context windows, reasoning capabilities and, increasingly, the cost of processing millions of tokens.

Yet while public attention remains focused on the models themselves, a different competition is emerging within enterprises.

Amazon, Microsoft, Google, Oracle, IBM and other technology providers are building platforms designed to integrate artificial intelligence into the everyday operations of organisations. These platforms are not simply offering access to LLMs. They are creating environments in which models can interact with corporate knowledge, access databases, use software tools, coordinate workflows and, increasingly, execute actions.

At the same time, a new generation of technologies is emerging between the applications and the models themselves. Services such as OpenRouter, LiteLLM and Portkey promise to simplify access to multiple AI providers, while protocols such as the Model Context Protocol (MCP) aim to standardise how intelligent applications interact with external systems.

The result is an increasingly complex technological landscape, where models, platforms, gateways, protocols and autonomous agents coexist.

Understanding their respective roles is becoming essential for anyone responsible for enterprise architecture, digital transformation or organisational governance.

But the most important question is not technological.

Who will control the intelligence infrastructure of tomorrow’s organisations?

And, perhaps more importantly, will organisations retain the ability to choose how their intelligence is developed, connected and governed?

2. LLMs Are Not Enterprise AI

The introduction of ChatGPT in November 2022 transformed public awareness of artificial intelligence. For the first time, millions of people could interact directly with a sophisticated language model through a conversational interface.

Yet Large Language Models were not entirely new. They represented the visible result of decades of research in machine learning, neural networks, natural language processing and knowledge representation.

The innovation was not simply that machines could process language. It was the combination of model capabilities, computational scale and accessibility.

Today, organisations can choose among several families of models.

OpenAI provides GPT models, Anthropic develops Claude, Google offers Gemini, Meta distributes Llama models, while Mistral and DeepSeek contribute additional commercial and open-weight alternatives.

Each family presents different characteristics in terms of reasoning, coding, multilingual capabilities, latency, cost and deployment options.

However, a fundamental distinction is frequently overlooked.

An LLM is not an enterprise AI system.

A language model can explain financial risk management, but it cannot assess a bank’s actual exposure without access to its portfolios, policies and transaction records.

It can describe public procurement procedures, but it cannot determine the status of a municipal procurement process without consulting the relevant administrative systems.

It can generate software, but it cannot reliably understand the architecture of an existing enterprise application without access to its source code, dependencies and documentation.

The model provides a general-purpose capability. The organisation must provide the context.

This requirement has created the foundations of an entirely new technological stack.

The central challenge is no longer simply selecting the most capable model. It is connecting that model to organisational knowledge, processes, applications and responsibilities.

3. Enterprise AI Platforms: The New Cloud Competition

The first major response to this challenge has come from cloud providers.

Amazon Bedrock, Microsoft Foundry, Google Vertex AI and Oracle OCI Generative AI represent different approaches to making advanced AI capabilities available within enterprise environments.

Their role is to reduce the complexity of integrating foundation models into applications while providing infrastructure, security, monitoring and development services.

Although their capabilities and commercial positioning differ, these platforms address several common requirements: access to foundation models, integration with enterprise data, development of AI applications, implementation of Retrieval-Augmented Generation (RAG), security controls and support for agent-based architectures.

Amazon Bedrock: AI as a Managed Cloud Capability

Amazon Bedrock provides access to supported foundation models through AWS-managed APIs.

Its ecosystem includes Knowledge Bases for retrieval, Guardrails for applying safeguards and services supporting agent development and operations.

For organisations already operating on AWS, Bedrock offers a relatively natural extension of their existing cloud infrastructure.

Identity management, monitoring, storage and security can be integrated with established AWS services.

The strategic advantage is not necessarily the availability of a particular LLM, but the ability to incorporate AI into an existing enterprise architecture.

Microsoft Foundry: AI Within the Enterprise Ecosystem

Microsoft occupies a particularly strong position because many organisations already depend on Microsoft 365, Azure, Microsoft Entra ID, Dynamics and Power Platform.

Microsoft Foundry provides a development and operational environment for AI applications and agents.

Copilot Studio offers a higher-level environment for creating and integrating agents into business processes.

Microsoft’s competitive advantage extends beyond model access. It includes the extensive presence of its technologies in enterprise productivity, identity management, software development and business applications.

For a company already deeply integrated into the Microsoft ecosystem, adopting Foundry may reduce some of the complexity associated with introducing enterprise AI.

However, that convenience can also increase dependence on a single technological ecosystem.

Google Cloud: AI, Data and Machine Learning

Google Vertex AI combines foundation models, machine learning infrastructure, data integration and AI application development.

Google benefits from its research heritage in artificial intelligence and its cloud data ecosystem, including BigQuery.

For organisations with substantial analytical workloads, the integration between AI and data engineering can be particularly attractive.

Google’s broader Gemini enterprise offerings also illustrate how the boundaries between AI platforms, productivity applications and agent environments are becoming increasingly blurred.

Oracle OCI: AI Close to Enterprise Data

Oracle approaches enterprise AI from a different position.

Its competitive strength lies in its extensive installed base of enterprise databases and business applications, together with Oracle Cloud Infrastructure.

OCI Generative AI and Oracle’s agent capabilities aim to bring AI closer to enterprise information and transactional systems.

For organisations running critical applications on Oracle databases, this creates opportunities to integrate AI without necessarily moving sensitive information into an entirely different technological ecosystem.

However, proximity to data should not be confused with automatic data access. Security, authorisation, integration architecture and data governance remain essential.

IBM, Databricks and Snowflake: Different Entry Points

IBM watsonx places particular emphasis on enterprise AI development, orchestration and governance.

Databricks approaches AI from the perspective of data engineering, analytics and machine learning, while Snowflake is extending AI capabilities within its governed data environment.

These companies demonstrate that the enterprise AI market is not converging towards a single architecture.

Instead, AI is becoming a capability embedded across multiple technological environments.

The competition is no longer simply between models.

It is between ecosystems seeking to become the preferred infrastructure for organisational intelligence.

4. OpenRouter and the Rise of AI Model Gateways

While cloud providers compete to offer increasingly comprehensive AI environments, another category of technology is emerging.

Its purpose is considerably more specific: simplifying access to different AI models.

Consider an organisation developing several AI applications.

One application uses GPT for software development. Another relies on Claude for document analysis. A third uses Gemini for multimodal processing, while a fourth employs DeepSeek for lower-cost workloads.

Without an abstraction layer, each application may need to integrate separately with different providers, manage multiple authentication mechanisms and adapt to different API conventions.

This creates complexity.

It also creates dependencies.

If the organisation decides to replace one model with another, the change may require modifications to application code, configuration, monitoring and operational processes.

AI model gateways attempt to address this problem.

OpenRouter: One API, Multiple Models

OpenRouter provides a unified API through which developers can access models from multiple providers.

Instead of maintaining separate integrations with OpenAI, Anthropic, Google and other model providers, an application can communicate with OpenRouter.

The gateway routes requests to supported models through available inference providers.

OpenRouter also offers capabilities such as provider selection, fallback routing, usage monitoring and centralised billing.

For developers, this can simplify experimentation.

A software engineer can compare different models without rebuilding the entire integration each time.

For organisations, the potential benefit is broader.

A common model-access interface can reduce coupling between applications and individual AI providers.

However, the abstraction is not perfect.

Models differ in their reasoning capabilities, context windows, tool-calling behaviour, structured output support and multimodal features.

A unified API does not make every model interchangeable.

LiteLLM: An Alternative for Enterprise Control

LiteLLM addresses a similar problem through a unified interface supporting numerous model providers.

Its proxy and gateway capabilities can be deployed within an organisation’s own infrastructure.

This introduces an important distinction.

A managed aggregation service such as OpenRouter can simplify development and commercial access to models.

A self-hosted gateway such as LiteLLM can provide greater control over routing policies, credentials and operational infrastructure.

For regulated organisations, this distinction may be significant.

However, self-hosting a gateway does not automatically guarantee data sovereignty. If the gateway forwards requests to external model providers, those requests remain subject to the processing arrangements of the selected providers.

Portkey and the Operationalisation of AI Gateways

Portkey represents another approach, combining model routing with operational capabilities such as observability, reliability controls and fallback management.

This reflects the evolution of model gateways from development conveniences towards components of enterprise AI infrastructure.

Once multiple applications depend on AI models, organisations need to understand which models are being used, how much they cost, how reliably they respond and which policies govern their use.

A model gateway can become a central point for implementing some of these controls.

But it also becomes a critical dependency.

If the gateway fails, applications relying on it may lose access to their models.

If its routing policies are poorly configured, workloads may be sent to inappropriate providers.

If its security is compromised, sensitive information or credentials may be exposed.

Consequently, model gateways should be treated as enterprise infrastructure rather than merely API utilities.

5. Do Amazon, Microsoft, Google and Oracle Offer Their Own Model Gateways?

The major cloud providers increasingly offer capabilities that overlap with those of independent model gateways.

However, it is important to distinguish three functions.

The first is model aggregation: providing access to multiple models through a common environment.

The second is model routing: selecting a model based on predefined rules or dynamic criteria.

The third is model governance: controlling and monitoring how models are accessed and used.

These capabilities are related, but they are not identical.

Amazon Bedrock provides managed access to supported foundation models and offers intelligent prompt routing capabilities within defined constraints.

Microsoft Foundry includes model-routing capabilities that can select among supported models according to optimisation objectives such as quality or cost.

Google Vertex AI provides access to a range of models through its model catalogue and deployment infrastructure.

Oracle OCI Generative AI similarly offers managed access to supported models within the Oracle Cloud ecosystem.

The differences become clearer when the platforms are compared.

Capabilities, supported models and commercial arrangements evolve rapidly. The table represents architectural positioning rather than a complete feature comparison.

The distinction is strategically important.

A company using AWS Bedrock may gain access to several model providers without leaving AWS.

But it remains dependent on the Bedrock service environment.

An organisation using an independent gateway may have greater flexibility to access different inference providers, but it introduces another component that must be managed and governed.

There is no universally superior solution.

The appropriate choice depends on existing infrastructure, regulatory requirements, operational capabilities and the organisation’s desired degree of independence.

6. From Generative AI to Agentic AI

The next transformation concerns the relationship between artificial intelligence and organisational processes.

Traditional generative AI applications operate primarily through a request-and-response model.

A person asks a question, the system processes the request and generates an answer.

Agentic AI introduces a different approach.

An AI agent can pursue an objective by selecting tools, retrieving information, planning intermediate steps and executing permitted actions.

Imagine a manager asking an AI system to analyse the performance of a public service.

A conventional conversational assistant might explain which indicators should be examined.

An agentic system could retrieve operational data, compare performance across periods, identify anomalies, consult relevant policies and prepare a report.

With appropriate authorisation, it might also create follow-up tasks or initiate administrative workflows.

The difference is not simply greater intelligence.

It is the ability to interact with the operational environment.

This introduces new architectural requirements.

An agent must know which tools are available, what each tool can do, which information it may access and which actions require human approval.

It must also operate within explicit security boundaries.

A system authorised to retrieve information should not automatically be authorised to modify it.

An agent permitted to draft an administrative document should not necessarily be permitted to approve or publish that document.

These distinctions become especially important in regulated environments and public administration.

As AI systems move from producing recommendations to executing actions, questions of accountability become unavoidable.

Who authorised the action? Which information was used? Which rules were applied? Can the process be reconstructed and audited? Who is responsible when the result is incorrect?

These are not peripheral technical concerns.

They are fundamental questions of organisational design.

7. Enter MCP: Why AI Needs a Common Language for Tools

One of the less visible challenges in enterprise AI is integration.

Organisations typically operate hundreds of applications, databases, document repositories and specialised services.

Historically, connecting a new application to these systems has required dedicated interfaces, APIs, connectors and integration logic.

The introduction of multiple AI models and agents risks multiplying this complexity.

Imagine an organisation using three different AI platforms and twenty internal applications.

Without a common integration mechanism, developers may need to create and maintain numerous model-specific or framework-specific connections.

This is where the Model Context Protocol (MCP) becomes relevant.

Introduced by Anthropic in 2024, MCP is an open protocol designed to standardise how AI applications connect to external tools and sources of context.

Its architectural model distinguishes between three components.

An MCP host is the application that coordinates the interaction, such as an AI assistant or agent environment.

An MCP client manages the protocol connection.

An MCP server exposes capabilities that the host can discover and use.

These capabilities can include tools for executing operations, resources containing information and prompts that provide reusable interaction templates.

The principle is relatively straightforward.

Instead of developing a proprietary integration for every AI application, an organisation can expose selected capabilities through MCP-compatible servers.

Different compatible AI applications can then discover and interact with those capabilities through a common protocol.

A Practical Example: An International Enterprise

Consider a multinational organisation operating across several countries, with different ERP systems, customer platforms, document repositories and business applications.

An AI agent supporting a regional executive may need to retrieve financial information, examine supply-chain performance, consult contractual documentation and compare operational indicators across business units.

Through appropriately designed MCP servers, the organisation can expose selected capabilities to authorised AI applications without requiring every agent to implement a separate integration with every enterprise system.

The objective is not simply to connect more applications. It is to make organisational knowledge and operational capabilities accessible through reusable, governed interfaces.

This also illustrates a fundamental distinction: interoperability enables access to organisational capabilities; governance determines how those capabilities may be used.

The rest of the article can retain its broader discussion of enterprise AI architecture, organisational intelligence and accountability without referring to your current employment.

One question: you mentioned two modifications, but I can identify only the request to avoid references to municipalities and your official role. What is the second change?

8. MCP and OpenRouter: Two Different Forms of Interoperability

At first glance, OpenRouter and MCP may appear to address similar problems.

Both aim to simplify integration.

Both can reduce the need for proprietary connections.

Both are relevant to the development of AI applications.

However, they operate at different architectural levels.

OpenRouter addresses the relationship between an AI application and the models it uses.

MCP addresses the relationship between an AI application and the external capabilities it needs.

In simplified terms:

OpenRouter helps an application access and route requests to different models.

MCP helps an application access the tools and information required to perform a task.

Consider an enterprise agent asked to analyse the financial performance of a department.

The agent might use a model gateway to select an appropriate LLM for interpreting financial information.

It might then use MCP to discover an authorised financial data service.

That service could invoke a conventional REST API to retrieve information from an enterprise resource planning system.

The agent could also consult a RAG system to retrieve relevant financial policies and budget documentation.

Finally, the LLM would help interpret the results and prepare an assessment.

Several technologies cooperate in this process, but each performs a distinct function.

The distinction is particularly important because organisations should avoid confusing technological interoperability with architectural independence.

Using OpenRouter does not automatically eliminate dependence on model providers.

Using MCP does not automatically eliminate dependence on enterprise applications.

And using open standards does not necessarily make every component portable.

Interoperability must be designed, implemented and governed.