“We connected Xero, so our AI understands our finances.” I hear a version of that sentence most weeks. The connection does something valuable: it makes source records available. It does not settle what your team means by revenue, customer margin or renewal risk.
That gap is easier to see if you separate three jobs: retaining evidence, using tools during a task and defining business meaning.
Connected. Related. Understood.
Follow the same evidence through three different questions.
Xero / InvoiceINV-2048 · Northstar · past due
Slack / MessageAccount team · a promise to pay
An invoice is evidence.
Xero records an £8,400 unpaid invoice. A Slack message mentions a payment. Access lets you read them; it does not establish that they refer to the same customer or what should count as overdue.
One Source Can Do Several Jobs
Consider Slack. Messages can be synced and retained as evidence. A live tool can also read a thread or post a response during a task. Those are different operations, even though they share a logo.
Xero offers another example. A connector can sync accounting records, while a source-specific tool inspects the evidence already stored. Neither operation decides how the organisation defines customer profitability.
The useful distinction is the job being done, not the vendor supplying the data.
Connectors Retain Evidence
A connector runs full or incremental syncs, stores records within the relevant scope and tracks progress and freshness. Its job is to make source evidence available over time.
A successful connection is only the beginning. Check which entities arrived, when they last synced and whether there are errors or coverage gaps. A connector can be authorised while the data needed for a particular question is still absent.
Availability also differs by provider and deployment. The presence of a connector in a catalogue does not prove that it is configured, permitted or syncing for your organisation.
What this layer contributes is attributable source material. It does not guarantee that the source is complete or that everyone agrees how to interpret it.
Tools Perform Work During a Task
A task-time tool can search, read or act against a provider under the run's identity and permissions. A live call has its own result and trace; it is different from a durable sync with a last-successful-update record.
Some tools can write when policy permits it. Others are read-only. A connection to a service should therefore never be treated as a general promise that an agent can update every record in it.
Tools can fetch a current amount or prepare an action. They still need a definition to know which amount matters. Calling an invoice API does not decide whether the result counts as billings, recognised revenue or cash collected.
The Twin Makes a Definition Reusable
A Twin view contract is a published business definition: what a row represents, which fields and calculations are available, and what evidence supports them. Earlier articles also call this a Twin product.
For recurring governed questions, that definition is the useful destination. The agent can make a bounded request against it instead of reconstructing joins and business rules each time.
The underlying systems keep their own authority. Xero owns its ledger records; a CRM owns its opportunities. The Twin governs how those records are interpreted together. A stable definition can still expose missing or stale evidence rather than hiding it.
Follow One Question Across the Layers
Ask: “Which customers are profitable, and why?”
The ledger may contain recognised revenue and direct costs. A project system holds delivery effort. The CRM identifies the account owner. A contract explains service terms, while a Slack thread may help explain an unexpected overrun.
Connectors make those records available. Tools can inspect a source or retrieve a recent update. The business definition must settle the remaining choices: how customers map to projects, which costs belong to each account, which period applies and how profit is calculated.
That definition needs validation and an accountable decision wherever the evidence leaves ambiguity. Once published and activated, it can support repeated questions without asking each model to make the choices again.
The Slack thread may explain the result. It should not quietly override the ledger amount or the agreed cost-allocation rule.
Seeing a File Is Not Reading Its Contents
Documents reveal a second version of the same problem. A SharePoint sync may list a file's name, path and update time without having extracted its text.
That listing can establish that the file exists. It cannot support a claim about a clause inside the document. Extraction status and content coverage matter as well as connector status.
If an agent cannot read the relevant text, the useful answer is to identify the gap. A filename that sounds relevant is not a substitute for the contract itself.
Audit the Connections You Have
For one recurring business question, fill in three columns:
| Layer | What to establish |
|---|---|
| Evidence | Which records are retained, how complete are they, and when did they last sync? |
| Tools | What can a task read or change, using whose permissions? |
| Definition | Which published business rule combines the evidence, and what checks support it? |
A source can appear in all three. The exercise shows where useful access has been mistaken for a finished answer.
Connect the systems, then give the recurring question an explicit definition. The connection supplies the evidence from which context can be built.
A few practical questions.
We already connect Xero. Does that mean our agent understands our finances?
It means the agent can see Xero. A connector lands source-backed, organisation-scoped records in the MLX warehouse and tracks their freshness. Understanding revenue, margin or renewal risk requires a reviewed, versioned definition in a governed Twin product. Access is a prerequisite for that, not a substitute for it.
What is the difference between a connector and a plugin in MLX?
A connector is durable ingestion: it runs full or delta jobs and keeps source evidence available over time, with tracked job state and freshness. A plugin or tool is a task-time capability that searches, reads or acts against a provider during a run, under identity, capability, secret and approval policy. One persists evidence; the other performs work in the moment.
Does a governed Twin product replace our system of record?
No. Sources such as Xero or your CRM remain authoritative for their own operational reality. A Twin product turns evidence from those sources into an agreed, versioned definition an agent can rely on. It governs meaning; it does not override the systems that own the underlying facts, and it does not by itself guarantee that those facts are complete or correct.