Watch how a sales manager actually works now. The pipeline review is written in Claude. The question about why a region slipped is worked through in ChatGPT. The numbers that feed both come from the business platform — exported, pasted, and stale by the time the sentence is finished. Nobody planned it. The assistant is simply where the thinking happens, and the data is somewhere else.
We had two choices about that. Build a better chat inside xMatix and hope it wins the tab war, or accept where the thinking happens and bring the business there. We did the first, and it matters: Sense is the assistant that knows the page you are on. But this post is about the second.
What "connect" has to mean
Connecting an assistant to a business system is easy to demonstrate and hard to do properly. The demo is an API key in a config file and a model that can call an endpoint. What it hides is the question every security team asks first: whose permissions is that key carrying?
If the answer is a service account, the connector is a side door. The model can be told "only show the user what they are allowed to see", but the access check is then a sentence in a prompt, and a cleverly worded question walks straight through it. We have written before about why our AI runs as you; the external connector could not be the place we quietly gave that up.
So the connector has no key. It has a sign-in. When a user connects Claude or ChatGPT to their xMatix organisation, the assistant sends them to the platform's own login, they authenticate as themselves, pick the organisation, and approve what the assistant may do. The token the assistant receives is theirs — bound to one organisation, expiring within the hour, carrying only the scopes the organisation allows. Every call the assistant makes afterwards is evaluated as that person, through the same record security and field permissions that govern every screen. The assistant cannot see a record the user could not open. Not because we asked the model nicely, but because the check never consults the model.
The same tools, not a smaller set
The second temptation is to expose a "safe" subset — a few read-only lookups — and call it integration. That produces a connector nobody uses, because the interesting questions need the whole surface.
The external endpoint exposes the tool surface the in-product Sense agent uses. An assistant can list your entities and learn their shape, query and aggregate records, walk relationships, run the saved reports and dashboards your business already trusts, and search the knowledge collections that ground your agents. It can hand a question to Sense itself and get the routed, grounded answer back. If the organisation allows it, it can create and update records, and an administrator can drive the Setup Copilot from their assistant and approve each step there. Aggregations come back as charts. The platform's own setup recipes are exposed as prompts.
What makes this safe is not that the set is small. It is that the set is the same, and so is everything wrapped around it: the token's scopes, the capability grants an administrator made in AI Studio, and the user's permissions at execution time. Each layer can only narrow the previous one. The external surface is always a subset of what the user could already do inside xMatix — never a superset.
Off by default, and a switch that means it
External assistants are disabled for every organisation until an administrator turns them on. That decision lives in AI Studio with two more controls beside it: whether writes are allowed at all — off means every token is capped at read-only, whatever the assistant requested — and an optional allow-list of approved assistant clients. The same page lists every live connection, by assistant and by user, with a disconnect on each row. Switching the feature off ends every session immediately, not at the next token refresh.
The reason for that last detail is the difference between a control and a promise. A promise says the connector will respect a policy change eventually. A control says it already has.
Why a standard, and not our own plug-in
We could have built an extension for one assistant and had a nicer demo sooner. We chose the open Model Context Protocol instead, for the same reason the platform speaks REST and OData rather than shipping a proprietary client: which assistant your people use should not be our decision to make. One endpoint serves Claude on the web and desktop, ChatGPT's connectors, Claude Code in a terminal, and any agent framework that speaks the protocol. When the next one arrives, it will work on the day it arrives.
The authorization server in front of the endpoint is general for the same reason. It brokers your normal xMatix sign-in for any registered client, so the next integration your IT team wants to build signs in the way the assistants do — a separate post covers why we built that ourselves.
What changes for the people
Less than you might expect, which is the point. The sales manager still writes the review in Claude. The difference is that when they ask which distributors slipped past terms this quarter, the answer comes from this morning's invoices, cited, and only from the invoices they could open themselves. The analyst in ChatGPT runs the report the business already agreed is the report, rather than rebuilding it from a table and getting a subtly different number. The administrator in Claude Code asks for a field on the visit form and approves the change set without opening a browser.
And for the security team, something that was invisible becomes governed: a switch, a ceiling, an allow-list, and a log of every call. The data that used to leave the building in a paste now leaves it permission-checked and on record.
The setup guide walks through the first connection. The product page states what the connector does and does not do, in the plain terms an evaluator wants.
Related: Sense in Claude and ChatGPT · How Sense earns trust · The MCP endpoint