Why this lesson exists. Some answers are not in a document: how many deals moved stage this week, which invoices are overdue, who opened a support ticket yesterday. Those live in systems and change constantly. This lesson lets the model go and look instead of waiting for you to paste.
By the end of this lesson you will be able to connect one system read-only and ask it questions, because you will have done the same report by hand and by connection and felt the difference.
By hand. Open the CRM. Filter to deals changed in the last seven days. Export. Open the spreadsheet. Add up the values. Work out which deals have been sitting in the same stage for a month. Write a summary. Paste it into the team channel. Forty minutes if nothing goes wrong, and it is skipped every third week because something always does.
Connected. With the CRM connected to the AI tool, the whole thing is one message:
"Look at all deals in our CRM that changed stage in the last 7 days. For each, give the company, old and new stage, deal value and owner. Then summarise: total pipeline value now versus last week, the three biggest movements, and any deal that has been in the same stage for more than 30 days. Format as a short report I can paste into Slack."
The model reads the records, does the arithmetic, and writes the report. About a minute. Then the second question, which is the one that actually earns the time back: "What is unusual in this compared with the last month, and what is the single most useful thing I could do this week about it?"
Notice that this the five-part brief again, with context now supplied by the connection rather than pasted in.
Modern AI tools can be plugged into the apps you already use: CRMs such as Attio, HubSpot and Salesforce; accounts packages such as Xero and QuickBooks; project tools such as Linear and Asana; Slack, Gmail, Google Drive, Notion; prospecting databases such as Apollo. The standard plug that makes this possible is called MCP (Model Context Protocol). You will not need the name; you will see it as "connectors" or "integrations" in your tool's settings, where you pick an app, sign in, and from then on the model can use it in conversation. Merve itself exposes an API and an MCP, so your content data can feed into the same picture.
The reason this matters is, once more, the model works from what it can see. A connection lets it see the live state of a system rather than a snapshot you exported. Three things follow:
Freshness. The answer reflects the system right now.
Cross-referencing. The model can join what lives in different places. "Which customers have an overdue invoice and an open support ticket?" is one question to a connected model and an afternoon of exports without one.
Action. Many connections let the model write as well as read: create a task, update a record, draft a message. Powerful, and the reason for the next section.
Lesson 5's rule was that anything in a shared knowledge base can appear in an output. A connection makes that rule bigger, because the model can now reach data you did not consciously decide to show it. A CRM connection sees every contact. A mail connection sees every email. So:
Connect read-only first. If the model only needs to read invoices, do not give it permission to create them. Write access is a separate decision, made later, after trust.
Know what each connector exposes before you approve it, and check the provider's policy on whether connected data is used for training.
Keep a human on the send button. The model drafts; a person approves anything that leaves the building or changes a record others rely on.
Treat what the model reads as information, not instructions. If a web page or email it reads contains text like "ignore your instructions and…", a good tool resists, but the safe rule is that nothing the model reads can order it to act. Anything that asks for an action gets confirmed with you.
