Why MCP Is the Ceiling, Not the Foundation of Enterprise AI Agent Architecture

Let's start with what should be uncontroversial: MCP has won.

In under eighteen months, Anthropic's Model Context Protocol went from open-source release to near-ubiquity. It has been donated to the Linux Foundation's Agentic AI Foundation , with OpenAI and Block as co-founders. The ecosystem now spans thousands of available servers. Every major cloud provider, SaaS vendor, and enterprise platform is building MCP integrations.

MCP solved a real problem. Before it existed, every agent framework had its own way of describing and invoking tools, most of them thin wrappers around CLI commands and REST calls. MCP standardised that. It gave the industry a common protocol for how agents connect to external systems. That matters.

But here is the question that has been nagging at me, and it came into sharper focus during a recent conversation with an industry analyst who covers this space closely:

That question cuts to the heart of something the market is conflating: the difference between connecting agents to systems and structuring what agents can see and do once they get there.

When enterprises talk about making their architecture "AI-ready," they tend to collapse two very different challenges into a single conversation.

The first is coordination: how agents invoke tools, how tasks are orchestrated, how state is synchronised across multiple agents, how capabilities are negotiated. This is where MCP lives. Alongside Google's Agent-to-Agent protocol (A2A), which now has over 150 supporting organisations including Salesforce, SAP, and ServiceNow, the coordination layer is maturing rapidly. MCP handles agent-to-tool. A2A handles agent-to-agent. These are important, well-defined problems.

The second challenge is structured data access: how agents discover what data is available, how related entities connect to each other, how access is governed at the field level, and how enterprise systems are safely exposed without rewriting everything. This is a fundamentally different problem. And it is the one most enterprises are actually stuck on today.

The market conversation has overwhelmingly emphasised the first problem. But in the enterprise trenches, the more urgent pressure is almost always the second.

Here is what I keep hearing from enterprise architects and platform teams, and what the data increasingly confirms. According to Gravitee's 2026 security report , 88% of organisations have experienced confirmed or suspected security incidents involving AI agents. Only 14% have obtained full security approval for their agent deployments. Adoption has massively outpaced governance.

The questions these teams are asking are not about multi-agent choreography. They are asking: which agent can access which fields? How do we prevent sensitive attributes from leaking through an agent's response? How do we expose legacy systems to AI without rewriting them? How do we make our data layer AI-ready without losing control?

Make it concrete. Picture a retail enterprise with an AI shopping assistant. The agent needs to check a customer's order history, verify a payment status, look up shipment tracking across two logistics providers, and check real-time inventory in three regional warehouses. All to answer a single question: "Where is my order, and can I change the delivery address?"

With MCP alone, that agent has six tool connections to six different systems. It can invoke each one. But it has no model of how those systems relate. It doesn't know that customer_id in the order system maps to account_ref in the payment system and shipper_client_code in the logistics API. It doesn't know that address changes are only permitted before the shipment enters "in-transit" status. It doesn't know that the customer's payment history contains credit card details it should never surface in a chat response. It will figure out how to make the calls. It will not figure out the relationships, the constraints, or the governance. Those have to be encoded somewhere.

These are governance problems. Protocols standardise invocation. They do not inherently solve data-level governance. That control surface lives elsewhere.

Before I go further, I want to address the best objection to this framing head-on, because it's one I take seriously.

The argument goes like this: modern LLMs are trained on millions of API documentation pages, Stack Overflow answers, and code repositories. They can already generate correct REST or GraphQL requests on the fly. If the model can figure out how to call any API, why do we need additional structure at all? Isn't the whole point of AI that it handles the messy integration work for us?

This is true in narrow, well-scoped scenarios. An agent calling a single well-documented API to retrieve a customer record? It doesn't need a graph. It barely needs MCP.

But enterprise data doesn't live in single API calls. A customer relates to orders, which relate to payments, which relate to shipments, which relate to inventory across warehouses. An agent reasoning about that chain needs to understand how those entities connect, not just how to call each endpoint in isolation. It needs to know which fields it is allowed to access, which relationships are traversable, and which operations are permitted.

The LLM can generate the request. It has no idea what it shouldn't be asking for.

Leonardo de Moura, creator of Lean and Z3, recently posed a parallel question about code : when AI writes the world's software, who verifies it? The same question applies to data. When AI agents access enterprise systems at scale, who governs what they can see? De Moura argues that testing is not verification. Similarly, connectivity is not governance. A protocol that confirms an agent can reach a system tells you nothing about whether it should be accessing what it finds there.

A well-designed data layer provides something fundamentally different from a protocol. And here I want to be precise about what I mean.

I am not talking about knowledge graphs in the academic sense, or semantic web ontologies, or graph databases. I am talking about a typed, schema-driven API layer that encodes how enterprise entities relate to each other. GraphQL is one implementation of this. It provides explicit relationships between entities through a typed schema. It provides field-level visibility and access control. It enables operation allowlisting . It supports cross-domain composition through federation. It gives agents a discoverable, introspectable model of the enterprise.

REST exposes endpoints. A typed graph layer exposes relationships. In theory, hypermedia APIs were supposed to bridge that gap. REST responses that describe their own links and traversable relationships. In practice, HATEOAS remains one of the most cited and least implemented principles in API design. For an AI agent trying to understand how a customer connects to orders, payments, and fulfilment, that structural metadata is not a nice-to-have. It is the difference between an agent that can make calls and an agent that can reason about your business.

Go back to the retail example. With a federated graph layer underneath, that shopping assistant doesn't need to figure out the mapping between customer_id and account_ref and shipper_client_code. The graph encodes those relationships. The schema defines which fields are traversable and which are masked. The agent introspects the graph, discovers that an address change requires checking shipment status first, and constructs a single query that spans all six systems. Governed, efficient, and explainable. The protocol invokes the query. The graph is what makes the query possible.

This is already happening in practice. SAP has announced MCP servers for Commerce Cloud that sit on top of structured product and order graphs. Microsoft Fabric is building native GraphQL integration alongside MCP support. The pattern is converging toward an AI-ready data layer: structured graph underneath, protocol on top.

There is a useful distinction borrowed from networking that clarifies where the real pressure sits. North-south traffic describes communication between external consumers and internal systems. East-west traffic describes communication between internal services. The coordination protocols (MCP, A2A) are designed for both, but excel at the east-west problem: agents talking to tools, agents talking to agents.

But the overwhelming majority of enterprise AI deployments today are north-south patterns: AI copilots accessing enterprise systems. AI-powered commerce interfaces. Internal assistants. Retrieval-and-action workflows. These are not multi-agent coordination meshes. They are single agents (or thin orchestration layers) querying distributed enterprise data.

In these scenarios, the bottleneck is rarely tool invocation. It is structured, governed access to data that spans multiple backend systems. And that is precisely the problem a typed data layer solves.

I want to be clear about the limits of this argument.

A typed data layer does not define task lifecycles. It does not handle agent-to-agent negotiation. It does not manage streaming state or orchestrate multi-step workflows. Those are coordination problems, and coordination protocols are the right tool for them.

Advanced multi-agent systems are coming, even if they are not the majority of production workloads today. When they arrive, MCP and A2A will be necessary infrastructure. The argument is not that protocols are unnecessary. The argument is that they are insufficient alone.

Rather than framing this as a choice, the more accurate model is layered. If you think about it through an OSI lens, MCP solves the transport. It does not solve the data layer. And no amount of reliable transport compensates for unstructured data.

The data plane defines structured, governed access to enterprise data. It encodes relationships, enforces field-level access control, and provides a consistent, discoverable model. GraphQL and federated graph layers live here.

The coordination plane defines how agents invoke capabilities and communicate with each other. MCP for agent-to-tool. A2A for agent-to-agent. Orchestration frameworks for multi-step workflows.

The risk, and this is the risk I see enterprises taking right now, is investing heavily in the coordination plane without first structuring the data plane. A protocol cannot compensate for poorly modelled data relationships, overexposed schemas, a lack of field-level governance, or inconsistent cross-domain composition.

If the data layer is not AI-ready, adding a protocol on top does not make it so.

This is precisely the gap that Cosmo and Hub are built to address. Cosmo is the data plane in practice: routing, schema registry, composition validation, and observability. Hub is the layer Federation itself never provided — a collaborative workspace where teams design schemas, propose changes through governed workflows, and ship against agreed contracts without breaking clients.

Together, they are the structured foundation that MCP servers need to sit on.

The meaningful architectural question for enterprise teams is not "should we adopt MCP or GraphQL?" Those are not competing choices. The question is: where should structure live in our AI architecture?

If structure lives only in protocol wrappers around loosely governed APIs, the underlying systems remain opaque to agents. The protocol gives you connectivity. It does not give you comprehension.

If structure lives in a governed data layer, agents operate against a consistent, discoverable, access-controlled model of the enterprise. Protocols still sit on top. But they have something coherent to coordinate against.

The industry has been dominated by protocols for good reason. MCP solved a real and urgent problem. But the next bottleneck is not more protocol adoption. It is data readiness.

Enterprises that conflate the two, that treat protocol adoption as synonymous with AI readiness, risk over-investing in orchestration before they have structured what is being orchestrated.

The graph is the data plane. Protocols are the coordination plane. Both are necessary. But the graph is the foundation, and protocols sit on top of it.

Getting that order right will determine how "AI-ready" an architecture truly is.

Or, to put it more directly: if you are building MCP servers today, ask yourself what they are sitting on. If the answer is a collection of loosely governed REST endpoints with no shared model of how your data connects, you have not built a foundation. You have built a very well-connected ceiling.

Frequently Asked Questions (FAQ)