Your connector feels like magic. Your semantic layer is the real deal

In Claude or ChatGPT, you click on a standard connector for your CRM, invoicing system, or support desk. Within a minute, the AI answers questions and takes action in a tool it just gained access to. For anyone seeing this for the first time, it feels like magic. No three-month integration project, no thick contract with a systems integrator. Just click, and it works.

Under the hood, that connector runs on MCP (Model Context Protocol). MCP is the technical standard that makes this possible: it governs how an AI model communicates with a tool, which actions are available, and how data flows back and forth. The connector you click on is, in fact, a ready-made MCP connection to one specific SaaS solution.

That magic is partly real. But it’s worth understanding exactly what that connector offers, because that’s also where the limits of what it can solve lie.

What a standard connector actually gives you

A standard connector gives an AI model two things: knowledge of how the lock works, and a floor plan of the part of the house where that lock is located. The model knows how to make an API call, which fields a tool expects, and what the results look like. That’s impressive work, and it saves a tremendous amount of manual integration effort.

What that connector doesn’t include is the business logic that exists outside of that single SaaS solution. The connector for your CRM knows how a “deal” is stored. It doesn’t convey the fact that sales only marks a deal as “closed won” once finance has confirmed payment, while operations applies that label earlier, as soon as the contract is signed. That knowledge isn’t in the tool. Ideally, it’s in the minds of your people and in informal agreements between departments.

“Best guess” becomes the default answer

If that business logic isn’t documented or structured anywhere, the AI model does what it always does when information is missing: it makes the best estimate based on patterns. These days, that works surprisingly well. Large language models have become remarkably good at inferring context.

But “guessing very well” isn’t the same as being correct in a business context. An agent who independently compiles a report or sends a customer a response based on the wrong definition of “active customer” or “outstanding amount” confidently provides the wrong answer. No one checks it, because it sounds convincing.

And that problem snowballs as soon as you use multiple standard connectors at the same time. Each connector brings its own separate schema, but no one tells the model how those schemas relate to one another. How does a customer in your CRM relate to a customer in your billing system? Which field takes precedence when the two systems contradict each other? Which definition of “revenue” counts? Every additional connector is another place where the model has to make a guess, with a growing chance that those guesses will contradict each other.

Why a semantic layer is where you should invest

The more structural solution lies not in yet another connector, but in bringing your data together in one place and building a true semantic layer on top of it.

The difference lies in scope. A standard connector describes a single system. A semantic layer describes your entire data landscape: how source tables from different systems are related to one another, which join is the right one when combining customer data from three systems, and, most importantly, what your company means by a term like “revenue,” “active customer,” or “outstanding balance.” Not as a separate agreement per team, but as a single, standardized definition that everyone—whether human or agent—can rely on.

In a previous blog, we described what semantic sprawl looks like in practice: finance reports 4.2 million euros in revenue, sales reports 4.5 million, and operations reports 4.1 million. Three figures, three definitions—a headache for management. That’s exactly the kind of inconsistency an AI agent can’t resolve on its own by guessing harder. It must be resolved at the layer beneath the agent, not within it.

With a semantic layer on top of your data warehouse, you give an agent something fundamentally different from a map of a single tool. You give it the rules of your entire company: how data comes together, and how that data should be interpreted.

What such a connector is good at

This is not an argument for abandoning connectors. A standard connector, built on MCP, is excellent at setting an agent on a task: performing an action, creating a record, or updating a status in a specific system. For such tasks, it’s exactly the right tool.

The point is that a connector and a semantic layer solve different problems. The connector handles the execution. The semantic layer determines the truth on which that execution is based. You need both, but if you have to choose which one to invest in first, the answer is the layer that determines whether your agent uses the correct figure—not the layer that determines how quickly it performs a task.

Our recommendation

Before adding more standard connectors to your AI workflows, it’s worth checking whether your definitions are already established. Identify which key terms in your organization have multiple definitions. Invest in a central, semantic layer above your data warehouse before deploying agents across multiple systems simultaneously. And treat that layer as a shared responsibility between your data team and the teams that will be using the agents—not as a one-time technical project.

Want to know how mature your semantic layer is and where the biggest risks lie before you deploy agents on your data? We’d be happy to help you figure it out.