# A Connector Is Not Context > Access is not understanding. Why durable ingestion, task-time tools and governed Twin products are three different layers, and why collapsing them breaks agents. Published: 2026-07-23T06:00:00Z Updated: 2026-09-10 Author: Archie Norman (Founder, MLX) Category: Twin Tags: connectors, plugins, twin, data-governance, ingestion, business-model, product-architecture Canonical URL: https://mlx.systems/blog/connector-is-not-context ## TL;DR - A connection gives you source evidence. It does not establish what the business means. - Connectors retain data, tools act at task time, and reviewed Twin definitions make meaning reusable. - A relationship between records adds context; it does not validate a business rule. --- “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.
Figure 01. Follow an illustrative invoice from source evidence to a relationship and a reviewed business rule.
## 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.