Series: Building the AI Foundation — Part 2 . Part 1: Stop Picking AI Tools laid out the seven-layer architecture. This piece is a deep dive into layer five, the context layer. Part 3 will cover the system of record.
The first article in this series, Stop Picking AI Tools, proposed treating enterprise AI as an architecture rather than a purchase. That architecture had seven layers, and most of them exist to be replaced as vendors and models change. Several readers responded with variations of one question. One division runs SAP, another runs a platform built on IBM i, and a third depends on a customer relationship system that few people trust. Dozens of internally built applications sit beneath all of it. Which layer addresses that problem?
This article addresses it. The context layer, fifth of the seven, receives the deepest treatment in this series because organizations tend to misconfigure it before they reach questions of governance. The difficulty lies in deciding which systems count in the first place.
The systems the standard diagram leaves out
When consultants draw enterprise systems, they usually draw one ERP with clean lines to a CRM and a data warehouse. After 25 years in enterprise IT and ERP, I’ve rarely seen a landscape that tidy.
A realistic diagram has one or two ERPs, often inherited through acquisitions. The CRM is the one half the sales team works around. Somebody built a quoting tool in 2014, it still runs part of the business, and the only person who understood it has left. A plant-floor system has no real API because nobody expected it to need one. Then there are the systems holding data you can’t expose casually: payroll, customer identifiers, safety records, and sometimes regulated manufacturing data.
Many companies also run a data platform that copies information from several of these systems into one governed place. That changes the picture more than people expect, and I’ll come back to it below.
Every AI initiative runs into this landscape early. An assistant that knows one system helps only the people who work in that system. Wiring each new tool straight to each new system brings back the sprawl from Part 1, one layer down.
Why point-to-point access breaks down
The obvious first move is to let each AI tool build its own connector to each system. With three tools and three systems, that’s nine integrations. Each one has its own authentication, its own reading of the data, and its own maintenance. Part 1 mentioned this problem in passing. With several ERPs, a CRM, and custom applications, it becomes the main one.
Custom applications make it worse because there’s no vendor connector to start from. Sensitive systems raise the stakes: a careless integration is a real exposure, and nobody wants to explain why an AI assistant could read compensation data because a connection already existed.
What MCP actually is, in plain terms
The Model Context Protocol, or MCP, is a standard way for an AI tool to discover and call the tools and data a server exposes. The protocol will keep changing, and it may not be the standard in three years, so I wouldn’t invest in it for its own sake. What it removes is the need for a separate integration for every pairing of tool and system. Build one connector per system and any compatible tool can use it, whichever one your teams prefer this year.
It’s the same argument I made for AGENTS.md in Part 1, one level up. Different artifact, same principle: put the effort where it outlasts any single vendor.
The pattern changes with the type of system
What sits behind a connector determines how you build it.
ERP and CRM platforms usually have mature APIs and existing connectors, so the work is scoping and normalization. You can expose each system’s own terms as they are, or map “sales order,” “SO,” and whatever the CRM calls the same thing to one shared term. Native terms ship faster. A shared vocabulary takes longer to build, and it lets someone ask for total open orders across two plants and get one answer instead of two.
Custom applications often have no API at all, so the work starts a step earlier. The best option is a thin API layer added to the application itself, if you can change the code. Next best is reading from a replicated database, which keeps any load off production. Script-based access with close monitoring is the last resort. Most of the engineering time in this layer goes into that bridge, and very little goes into learning the protocol.
Every server should sit behind a registry, or gateway, that AI tools use to discover approved connections. Without one, people configure connections by hand, and the sprawl returns.
When a data platform already exists
Many companies already run a data platform, such as Databricks, that pulls data from the ERPs and the CRM, plus some custom applications, into one governed place. If yours does, five things change.
First, it’s a new kind of system in the landscape, and a friendly one. Databricks provides managed MCP servers over Unity Catalog data, search indexes, Genie, and custom functions. Unity Catalog enforces permissions on those servers, and they can authenticate as the individual user, so agents reach only what that person has been granted. That matches the identity rule I’ll get to below. Other platforms may offer something similar, so check yours before assuming it.
Second, normalization moves upstream. If the ERPs and CRM feed a curated layer with shared definitions, “open orders across both plants” becomes a query against one set of tables instead of a mapping project on every server. The work shifts to data engineering: pipelines and master data, plus the definitions both depend on. A weak curated layer gives confident wrong answers, so every pipeline needs a named owner.
Third, custom applications get an easier path. Replicating their data into the platform gives you the replicated-database option once, for many applications, and you skip a separate bridge for each. That covers reading only. Writing back still needs another route.
Fourth, the context layer splits into two lanes. One is for knowing: analysis, and grounding answers in current data. The other is for acting: creating or updating records in the systems of record. Creating an order still needs a server in front of the ERP, with the same scoping and identity rules as before. The platform answers questions; it doesn’t replace those servers.
Fifth, sensitive data gets easier to govern and easier to expose. You can apply column masking and row filters once, at the catalog, and tag sensitive fields in the same place, instead of rebuilding that protection on every server. The same consolidation concentrates risk, though. Joining data from several systems can reveal things no single system showed on its own, so the sensitive-tier review has to cover joined and derived datasets, not just the sources.
One more caution, about the registry. Databricks lets administrators see and manage its own MCP servers in one place, which is useful. Your registry still has to cover every system. If a single platform’s console becomes the registry, one vendor ends up holding the role I argued in Part 1 should stay neutral.
Sensitive-data systems deserve their own tier, not a footnote
I want to be direct about this, because it’s the part people skip past.
Some systems shouldn’t get a general-purpose MCP server, at least at first. HR and payroll are the clearest examples. They’re usually better served by narrow, read-only tools with field-level redaction built in than by a general connector with a few fields switched off afterward.
Scoping has to go below the system level, down to individual fields. A server over your CRM might expose accounts and opportunities and leave out compensation and personal identifiers. Redaction belongs at the server, before any response reaches the model. A prompt-level instruction can’t give the same protection, because a well-meaning user or a differently configured tool might skip it.
That calls for a separate, heavier approval path. A server that touches regulated or sensitive data goes through security review, and often legal review, before it enters the registry. A sales or operations system gets a lighter one. It's slower on purpose. A decision like this shouldn't move at the speed of a Friday afternoon message thread.
Governance across the whole registry
Four principles hold whatever system sits behind the server.
Identity comes first. MCP calls should run as the requesting user and never as a shared service account, so the underlying system’s own authorization still applies. Custom applications tempt people the other way, because one broad credential is easier than per-user authentication, so this matters more there.
Scoping is second. Give each server a narrow, task-specific set of tools. Handing over a system’s full capability because a template made that the easy path is the usual way this goes wrong.
Audit comes next. Every MCP call is a loggable event, so treat it like any other system access. A vendor’s chat history isn’t an audit trail.
Ownership is the hardest to assign. Someone has to update a server when the underlying system changes. That’s straightforward for ERP and CRM platforms, which follow release cycles. Custom applications often have none, and their servers go stale and keep answering with full confidence. Data pipelines carry the same risk, so they need owners too.
A rollout sequence for a real enterprise
Start with the system that has the best API and the lowest sensitivity. Often that’s a curated, non-sensitive set of tables in the data platform, where governance already exists. Prove one narrow use case end to end on that server before you add a second.
Build the registry, and especially the sensitive-data approval path, while you only have two or three servers. Adding that structure after fifteen servers are running costs much more. Then expand in order: mature systems next, custom applications once their bridges exist, and sensitive systems last, through the heavier review path.
It’s the same phasing as the adoption plan in Part 1, one layer down: prove it small, and build governance while it’s still cheap.
Failure patterns worth naming
These recur often enough to name. A shadow MCP server appears on someone’s laptop because the official one took too long to approve. Credentials sit in a config file because nobody has set up secret management for this layer. A server built from a generic template exposes far more of a system than anyone intended, because nobody reviewed the defaults. A sensitive system gets connected to a general-purpose server because it was already there, and nobody asked whether it belonged. And an unowned pipeline goes stale, so the answers look authoritative and are wrong.
None of these is unusual. Each comes from putting speed ahead of structure.
What building it myself taught me, this time
In Part 1 I said context beats model choice, and this layer is where I’ve seen that most clearly. I designed a complete ERP application specification meant to be built by a team of AI agents, and most of the effort had nothing to do with AI. It went into scoping: deciding what each component needed to know and in what form, along with what it should never touch. The specification worked as a context layer for a system that didn’t exist yet.
The lesson carried straight over to this article. The protocol is the easy part. Deciding what belongs on the other side of it, and what doesn’t, is where the judgment is, whether you’re specifying a system for agents to build or choosing which of your fifteen production systems gets an MCP server this quarter.
Where this leaves you
The protocol will keep changing. MCP itself may not be the final standard, any more than any specific model is the final model. What won’t change is the discipline underneath it: one connector per system, not per tool; narrow scopes instead of broad access; identity carried all the way through; and a clear, deliberate line around what doesn’t get connected at all, at least not yet.
That discipline is the actual asset. Everything else is implementation detail that next year’s tools will happily inherit, if you’ve built it right.
Strong follow-up, Balu. I especially like the distinction between knowing through a governed data platform and acting against systems of record.
From a security perspective, carrying user identity through every hop is necessary, but not sufficient. MCP still needs least-privilege scopes, agent/workload identity, credential isolation, and stronger controls around write-capable actions.
I’d also view the MCP registry as part of the security control plane—not just service discovery—to govern approved servers, capabilities, ownership, and shadow MCP.
MCP may standardize connectivity, but standardized connectivity shouldn’t become standardized trust.