Connectors

What you'll walk away with: what a connector actually puts in the window, how to tell a lookup that ran from one that was described, and the order that keeps a connection safe — read first, write after trust.

You need: both tabs, about 20 minutes, and one tool you already use that the product offers a connection for — a calendar, a drive, a notes app. If neither product connects to anything you use, half two still runs and half one has a paste that stands in. One demo runs in your browser. Nothing to install.

First, thirty seconds of retrieval — from memory, not from the page: what is the move behind every "the AI checked something" moment? Say it, then check it against lesson 06: the model asks, the app runs it, the window receives. Search was one door through that move; a connector is the same door pointed at a tool you already own, and this lesson is what comes through it, and which way.

What a connector puts in the window

A connector turns what a tool holds into text, and that text rides in the window like everything else you counted in lesson 03. Nothing in the machine gained a new sense; the window gained new lines. So the first move is to ask what it actually received, quoted, and read it against the tool's own screen.

The same move runs the other way: your request becomes text the tool understands, and the app performs it. Reading and writing are one mechanism, the tool call, with a different verb — so the permission you grant decides what can change, not the wording of your ask.

The open standard under this kind of connection is MCP — the Model Context Protocol, which is why one connection can serve a chat app, an agent, and the command line alike — so one connection can turn up in more than one place; read each permission screen on its own. Connectors and MCP keeps the definition. And the app builds and edits the window; a connector's results fill it, as files, memory notes, and search results do — never "the model reached into your calendar."

Two ways to an answer

Start with arithmetic, one step away from your calendar, because nowhere is the mechanism easier to catch bare-handed.

Ask for 2 + 2 and "4" dominates the odds the way "you" follows "thank": that exact continuation sits in the training pile beyond counting. Nothing you can audit ran — no visible procedure, no receipt; the digits of an answer are picked the way every other token is picked, by the odds over what comes next.

Predict first, before you touch the demo: same machine, but the question is 37,481 × 2,919 — a product you will not find written anywhere. What do the odds do?

It opens on 2 + 2 =, with no path control: the four candidates stand with 4 in front at 96%, tagged SEEN BEYOND COUNTING, and the line beneath the prompt row says why — No tool needed — and none was used. Press 37,481 × 2,919 =: the favorite is now 109,417,039 at 34%, and the true product, 109,407,039, sits below it at 27%, tagged THE TRUE PRODUCT — IN THE ODDS, NOT THE FAVORITE. A PATH row has appeared. Press THROUGH THE TOOL and the candidates give way to three labeled steps — THE MODEL WRITES A REQUEST, THE APP RUNS IT, THE WINDOW RECEIVES — the real digits in the last two, and a closing line: continued from the window, not completed from the odds. FROM THE ODDS puts the candidates back; those two buttons are the fork, and 2 + 2 = takes the demo back to where it opened. The grey line at the bottom says SIMULATED — read it before you take anything from the demo.

What you watched on the odds path: the odds still produce something answer-shaped — right length, right leading digits, even the right final digit, because local patterns are exactly what odds are good at. The true product is in the odds too, and it is not the favorite. And the part that matters more than any wrong number: a computed result and a fluent guess look typographically identical. Nothing in the answer — not the confidence, not the formatting — tells you which one you got.

Now read the tool path again and watch the same request go a different way. The model writes a request — more text, in the same window. The app runs it as real code. The true product comes back into the window, and the reply continues from it. You met this door once before, when web search filled the window in lesson 06; it is the same door, and the tool call is its general name. That lesson has it drawn, with the receipt beside it.

The same fork stands behind every connected tool — a reply naming three meetings either came from a step that ran or was completed from the odds, and the receipt is what separates them.

Read first, write after trust

Grant reading before granting doing: take the read-only option if the permission screen offers one. A connection that can read puts text in the window; one that can write lets the app perform what the text asked for, and connectors and MCP keeps the read-first rule in one line.

Then watch what fills the window before you widen it: ask one question only that tool can answer and make it quote what it read — your evidence of what the connection hands over.

Only then allow a write, and read the receipt each time: ask for it as a draft you approve, keep the approval step if the product offers one, and open the step afterwards to see what ran, not the sentence that says it ran — no receipt, no action, the rule lesson 06 gave lookups, pointed at doing.

The control is a connectors or integrations setting in the app's settings — but menus move, which tools are on offer moves, and what your account can connect moves; look for the nearest thing under those two words. The same setting takes it back — disconnect anything you only wanted to watch, and the reach goes with it.

Do this in ChatGPT and Claude

Half one — the connection. In the first tab, open the app's settings and look for connectors or integrations. Connect one tool you already use and would not mind a chat reading — read-only if offered — and read the permission screen before you agree: it is the only place the reach is written down. Predict, before send 1, and write it down: how much will come back — the whole thing, or a slice — and will there be a visible step, or just a reply?

Send 1 — ask it something only that tool knows.

Using the tool I just connected, tell me what is on my calendar for the next three days. Quote each entry exactly as it came back to you, and say which tool you read it from.

Swap "calendar" and "entry" for the tool you connected — for a drive, the three documents changed most recently. Observe: first the step — a labeled tool run above or inside the reply; open it if it expands and read what was asked for and what came back. Then the quotes, against the tool's own screen: a matching quote is text that arrived in the window; a summary where a quote was asked for was assembled from something else.

Send 2 — the same ask with the connection off. Switch the connector off — or open a chat where it is not available, or disconnect it — and send the block above again, unchanged. Observe: three outcomes, all the same reading: it says it has no access to that tool — absence given a word, lesson 10's habit; it asks you to paste the entries — the same honesty with a request attached; or it writes a plausible three days with no step above it — the demo's fork, on your own calendar. Explain: nothing about the machine changed between the sends; what changed is whether anything ran and put text in the window.

When it does not go that way. No connection on offer for anything you use: paste your next three days in and ask the same question; text in the window is text in the window, however it got there. The tool connects and returns nothing: open the step and read what it asked for — an empty result and a refused permission read differently there; the reply alone does not. It narrates a lookup with no step: treat it as unrun, however current it sounds — no receipt, no lookup.

Half two — the arithmetic, both ways. Fresh chat, same tab — no connector needed. Predict first: will the two answers agree?

Multiply 37,481 by 2,919. Use a calculator or run code to do it, and show me the step that ran.

Then, in a new chat:

Multiply 37,481 by 2,919. Answer from what you already know — do not use any tool, do not run code.

Observe: side by side, check the digits against a calculator; look for the step on the first and its absence on the second; the two answers are typographically identical whatever they say. Explain: one continued from a result that entered the window; the other completed the digits the way it completes every other token — the demo's fork on your own screen, and only the receipt tells them apart.

When it does not go that way. The no-tool reply gets the digits right: without a step they are unaccountable, not wrong. It carries a step anyway: the app ran one regardless of your line — treat it as the first send's result.

Then both halves in the other tab. What differs is one product on one day, no rule for next month — which is why the move you keep is find the step, not a preference between two connector menus.

---

Check your understanding: a reply tells you your Thursday is clear. You have a calendar connected. What are the two things it could be made of, and what settles it?

Check yourself first — then open one good answer+−

Either a step ran against your calendar and the entries — or the absence of them — came back into the window as text, and the reply continued from that; or nothing ran, and the reply completed a plausible Thursday out of the odds. On the page the two are identical: same confidence, same formatting, same clear Thursday.

What settles it is the receipt — the app's own labeled step, opened, so you read what was asked for and what came back. If there is no step, treat the lookup as unrun. And the order that keeps this cheap: connect read-only first, ask one question only that tool can answer, and let anything write only after you have watched what reading puts in your window.

Your answer should have hit the fork — read from the window, or completed from the odds — and the receipt rather than the reply's confidence as the thing that decides.

Use this the first time you connect anything. Read-only, one question only that tool can answer, quote what came back, find the step — then widen the reach if it earned it. Next: Focus the window, or widen it — how much to load, and when to narrow.