A Connector Is Not Context

"We connected Xero, so our AI understands our finances." I hear a version of that sentence most weeks, and it is almost right. Connecting Xero does something real and valuable. It just does not do the thing the sentence claims. After the handshake completes, your agent cannot understand your finances. It can see Xero.

Those are different achievements, and the gap between them is where most agent products quietly fail.

Access is the easy half. Meaning is the hard half. A connector proves you have a credential and a pipe. It does not prove anyone has agreed what "revenue" is, which customers count as active, or how you recognise a renewal that is at risk. The moment you have two sources, you have two answers, and nobody has ratified either.

MLX treats this gap as an architecture problem, not a prompt problem. There are three layers here, and they do three different jobs. Confusing them is the fastest way to build an agent that sounds confident and is wrong.

One Logo, Three Roles

Start with the mistake that makes the rest hard to see: assuming a brand has a single role. It does not. In MLX, Slack can be a durable inbox sync that lands messages as evidence, and separately a live hosted action surface an agent uses during a run. Xero can be a durable accounting connector, and separately a source-specific warehouse skill that inspects already-synced accounting evidence. Same logo, more than one role.

Do not read the layers as a list of vendors. Read them as a list of jobs. A source earns its place in a layer by what it does there, not by whose logo is on it.

Connectors Make Evidence Durable

A connector is durable ingestion. It runs full or delta jobs, lands source-backed, organisation-scoped records in the MLX warehouse, tracks job state and freshness, and may retain change-feed or extraction state so the next run knows what changed. Its job is to make source evidence available over time.

Current connectors span finance, payments, documents, code, communication, and personal-workspace sources. They include Xero, SunSystems, Stripe, SharePoint, Gmail, Google Calendar, GitHub, Granola, and Slack. Gmail, Google Calendar, Granola, and Slack are user-scoped rather than organisation-wide.

Default synced entities vary by provider and are deliberately specific: Xero accounting records; Stripe balances, payments, customers, products and prices, invoices and lines, subscriptions and items, disputes, refunds, payouts, Checkout Sessions, and lifecycle events; SharePoint documents; Gmail messages; Calendar events; Granola notes; Slack mentions and direct messages.

Do not read that list as a uniform grid. These providers do not share one maturity, authorisation flow, or deployment story. Which providers are available in front of you depends on deployment configuration and credentials, not on the length of a product list. A connector existing in the code is not the same as a connector running for your organisation.

What a connector gives you is evidence with a timestamp. It never gives you agreement about what the evidence means, and it does not promise the evidence is complete or correct. It promises provenance and freshness. That is genuinely valuable, and it is genuinely not understanding.

Plugins Make Actions Available at Task Time

A plugin or tool is a task-time capability. During a run, under identity, capability, secret and approval policy, it may search, read or act against a provider. It is the layer that does something now.

The runtime surface is broad and, again, not uniform. Slack appears as a hosted MCP service under MLX policy alongside its native inbox sync. Google Calendar, Docs, Drive, Gmail and Sheets run on user-scoped credentials with runtime traces, and Gmail and Calendar can also sync durable records. There are Microsoft Teams Graph reads, plus Notion, Linear and GitHub task-time integrations.

There is bounded, read-only querying against an external Postgres source, kept deliberately separate from MLX warehouse ingestion. There are MLX workspace and warehouse tools, plus source-specific skills that read already-synced finance, CRM, and meeting evidence.

Two things matter about this layer. First, do not assume it is read-only. Some task-time tools can write when capability and approval policy permit, and an action surface that can only read is a different product from one that can post, file or update.

Second, and this is the crux, a tool call can fetch the current number or take an action, but it cannot ratify a definition. It executes against whatever "customer" or "invoice" the provider happens to expose. It does not decide what those words should mean for your organisation.

Freshness and audit look different here too. A live call reflects this instant with its own trace, while a durable connector can tell you its last successful sync and delta state. Both are legitimate; they are not interchangeable.

Twin Products Make Meaning Governable

The third layer is the one people skip, and it is the one that actually answers business questions. A Twin product turns source evidence into governed organisational meaning.

Concretely, that means a reviewed and versioned definition, a stable published relation, a product contract, a runtime binding, validation evidence, and optionally an evaluation. It is the difference between "here is what Xero returned" and "here is what this organisation has agreed revenue means, at this version, with the checks that back it."

This is the layer an agent should reach for when someone asks an ordinary governed business-data question. Not the raw connector and not a live tool call, but the product that has already resolved the disagreement. The Twin should prefer governed products for ordinary reads, and reserve raw source adapters for cases that genuinely want them: source-specific inspection, reconciliation, or an operation against a particular system.

Say what this layer does not do, clearly. It does not replace your systems of record. Xero still owns your ledger; your CRM still owns your accounts. The Twin governs meaning on top of sources that remain authoritative for their own operational reality.

It also does not magically guarantee quality. A definition can be governed and still sit on top of incomplete extraction or a source that is behind. Governance makes the definition reviewable and stable; it does not make the underlying evidence true.

Follow One Question

Take a question a finance or operations buyer actually asks: which customers are profitable, and why?

Revenue and direct costs may live in Xero or SunSystems. The relationship, account owner, and commercial status may live in a CRM. Service terms may live in SharePoint documents. Slack conversations may contain useful explanatory context about delivery problems. Four sources, four vocabularies.

One source has an invoice. Another has an account. SharePoint has a contract. Slack has a message. None agrees, by itself, on what "customer" means, let alone "profitable."

Connectors make the source evidence durable with provenance and freshness. Plugins can fetch a current figure, inspect a specific source, or post the eventual answer back into a channel. Neither step decides that a customer maps to a particular account, that revenue is recognised income associated with it, which costs belong to it, or which formula the organisation uses for profit.

That decision is a Twin product: defined once, reviewed, versioned, published as a stable relation, bound at runtime, and backed by validation evidence. Ask the raw sources and you get several honest, conflicting answers. Ask the product and you get the one your organisation has agreed to stand behind.

More connectors do not shrink this problem. They enlarge it. Every source you add is another vocabulary that can disagree. Access scales; agreement does not, unless you govern it.

SharePoint, in Detail

SharePoint is a good place to see the trap up close because the code is real and the temptation to overclaim is strong.

The SharePoint connector includes Microsoft Graph OAuth, site and drive traversal, delta tokens, deletion recovery, and a document extraction pipeline. By default, an individual document is capped at 100 MB and an extraction job processes up to 100 candidate documents, with both limits configurable. Supported documents can then be submitted to Reducto for extraction.

It is also code capability, and that is not proof of production end-to-end consent, a live customer deployment, or successful ingestion for any particular organisation. The pipeline existing in the repository tells you what the code can do, not what has happened for you.

There is a second distinction inside SharePoint that matters even when everything is live: metadata sync and extracted document text are different evidence states. Listing a file is not the same as being able to query its contents.

A connector can enumerate every document in a drive, with names, paths and change history, and still not have extracted a word of what is inside them. "We can see the file" and "we can answer questions from the file" are two different claims. Treating the first as if it were the second is the access-versus-understanding error, one folder down.

Why Some Providers Live in Two Layers

The two-layer providers should now read as sensible rather than confusing. Slack earns durable inbox sync because its messages are evidence worth keeping with provenance and freshness, and it earns a live hosted action surface because sometimes a run needs to act in Slack right now.

Xero earns a durable accounting connector because the ledger is evidence over time, and it earns a source-specific warehouse skill because sometimes you want to inspect that already-synced accounting evidence directly. The presence of a brand in two places is not duplication. It is one source doing two genuinely different jobs.

An Audit You Can Run

Take every source you have connected or plan to connect and put it into three columns, not one.

Column one, evidence: does this source land durable, source-backed records with tracked freshness? That is your connector layer, and the honest entry is a last-sync state, not a feeling.

Column two, actions: can a run search, read or act against this source at task time, and can it write or only read? That is your plugin layer, and the honest entry names the capability and approval policy.

Column three, governed products: for the business questions this source feeds, is there a reviewed, versioned definition with a published relation and validation evidence? That is your Twin layer, and for most sources this column starts out empty.

That emptiness is the point. It is the work you have not done yet, and it is the work that turns access into answers. A source can appear in all three columns. Most teams discover they have filled the first two and left the third blank, then wonder why their agent is confident and unreliable.

Access Is a Prerequisite, Not a Substitute

Connecting Xero, Slack or SharePoint is worth doing. It is the ground everything else stands on. But it is ground, not building. A connector makes evidence durable. A plugin makes an action available. Only a governed Twin product makes meaning something your organisation has agreed to and can hold an agent to.

Connect the sources, and then do not stop there. Access is a prerequisite for context. It is not a substitute for it. The connector is not the context; it is what lets you finally go and build one.

---

Previous: Every AI Answer Needs a Receipt. Why durable evidence must show which governed product actually answered.

Next: The Agent Is the Easy Part. Why durable advantage moves from replaceable agent surfaces to the company context underneath them.