Connecting CRM and ERP to a language model · the four-layer architecture

Every serious AI initiative arrives at the same question within a few weeks: how does the model reach the data we actually work with? Until it does, it answers general questions well and your questions not at all. It does not know your order book, cannot see the contact history, and the price list it quotes is one it invented.

This article covers the way there: the three walls integrations usually run into, the architecture that avoids them, and the times we measured for individual systems.

Three walls, always the same three

• Every system speaks its own language. CRM, ERP, mailbox, and database have nothing in common except the building they sit in. With no shared protocol, each connection gets built by hand, and the effort returns in full with every additional source.
• The data leaves the building. Tools delivered as a service from someone else's data center carry contract text and customer records there with them. In regulated industries that is not a trade-off, it is a disqualifier.
• The effort ties up engineering. A bespoke build per source occupies exactly the people who are already overloaded, and turns every upgrade of the business system into an exercise in caution.

The third wall is the expensive one, and it shows up late. With one source, a bespoke build is sensible. With three sources, it is a department.

One protocol instead of one interface per source

The Model Context Protocol is an open standard for exactly this mediation. Rather than binding each business system to each model individually, an MCP service exposes the source once, in a standard shape. Which model reaches it afterward becomes a matter of configuration rather than programming.

The protocol has three building blocks, and it needs no more than that.

• Resources are the data: files, records, responses from other interfaces. Every source becomes something an agent can query in one uniform way.
• Tools are the actions: create a case, check an order, send a message. A tool spells out which operation is permitted and which parameters it requires.
• Prompts are the guardrails: prepared workflows an agent invokes depending on context. They keep the approach repeatable instead of leaving it to however somebody phrased the request.

The decisive sentence is the middle one. A tool spells out which operation is permitted, and a model can do nothing for which no tool exists. That boundary is not a side effect; it is the reason the approach is usable in a regulated business at all.

Four layers, one architecture

No tangle of point-to-point links. Every layer has exactly one job, and every layer can be replaced on its own.

• Data sources: CRM, ERP, collaboration platform, and file storage stay where they are. Nothing is copied, and no second store appears to drift out of sync.
• MCP services: one service per system. It translates reads and writes into the protocol, enforces the permissions of the calling account, and writes an audit entry for every call.
• Orchestration: it routes a request to the right model and the right connector. Permissions and data classification are enforced here, and this is where it is decided whether a request may leave the building at all.
• Workspace and teammates: the business side works in the interface or with one of the prepared roles. Anyone who would rather not know about MCP does not have to.

The value of the separation shows up when something changes. A new model touches only the orchestration layer. A new business system touches only one service. In a point-to-point landscape either of them touches everything.

What a call leaves behind

In an audited business, an answer without provenance is worthless. Every call therefore leaves an entry that reads cleanly months later: who touched which data through which tool, when, and with what result.

{
  "timestamp": "2026-08-09T09:14:52Z",
  "account": "[email protected]",
  "role": "sales",
  "service": "mcp-hubspot",
  "tool": "deal.read",
  "parameters": { "dealId": "41207" },
  "dataClass": "internal",
  "result": "ok",
  "durationMs": 214
}

Two things are deliberately missing from that entry: the content of the record and the wording of the request. An audit log that captures content becomes a data protection problem in its own right. What has to be traceable is the access, not its subject matter.

How long it takes

The figures below come from completed rollouts between the fourth quarter of 2025 and the second quarter of 2026. They describe setting up the connector, not delivering a use case. Elaborate custom fields or bridges to legacy systems run longer.

• HubSpot and Odoo: 2 to 4 hours. Authentication and a sandbox are ready within hours.
• Nextcloud: 1 to 2 hours. An app password is enough.
• Microsoft 365 and SharePoint: about half a day. The deciding factor is the scope granted across sites.
• Salesforce and Dynamics 365: half a day to a day, provided profiles and permissions are in order. If they are not, that is the actual work.
• SAP S/4HANA: 2 to 5 days. The OData service and the authorization concept set the pace, not the protocol.

The full table with category, authentication, and scope per system is in the CRM and ERP integration guide.

Permissions are the real work

The technical connection is rarely the problem. The problem is the question it raises: who is allowed to see what? In most companies that question has been answered sloppily inside the business system for years, and it only surfaces once an agent works with an account's permissions and makes visible how far those permissions actually reach.

So the rule is simple: a teammate gets exactly the permissions a person in that role would have, and not one more. A service account with full access is convenient the moment it exists, and it is the point at which an audit stops the rollout.

Four questions before the first connector

• Which workflow is supposed to improve, and how will that be visible? Without an answer, every connector is an end in itself.
• Which system is authoritative? When two sources contradict each other, it has to be settled beforehand which one wins.
• Who owns the permissions? Not IT, but the business area the data belongs to.
• What happens when something goes wrong? An agent that writes needs a way back, and that belongs in place before the first write operation.

Where to start

With read access to a system that is already well maintained, and with a workflow whose value nobody disputes. Write operations come later, once audit logging is running in production and somebody actually reads it on a schedule.

Which systems ship connected today is listed on the MCP connectors page. If you need a service for a system that is not on that list, the article Building your own MCP server walks through it.