Lesson 29.1 drew the two shapes: question-to-answer versus goal-to-tool-to-observation-to-decision. Now the confusing middle arrives. You connect Google Drive to ChatGPT, link a calendar to Claude, or let Gemini read your email context — and suddenly the chat can search your files, find tomorrow's meetings, even draft a message. Is that an agent?

Usually not. It is tool-augmented chat: the same question-and-answer shape, with a longer reach. This lesson shows how the three major platforms package that reach, and gives you three questions that separate a connector from an agent.

What the platforms actually offer

All three major assistants now let a chat model reach into services you use. The names change; the durable idea does not: the model gets a defined, permissioned capability it can invoke during a conversation.

• ChatGPT apps (formerly connectors). Apps in ChatGPT connect services such as Google Drive or Slack so the model can find a file, summarize a document, or look up a message without you leaving the conversation. Some apps show interactive cards or maps, support search and synced indexes, work with deep research, and — depending on configuration — take permitted write actions. Permissions distinguish read actions from consequential ones, asking first before anything meaningful, hard to undo, or sensitive. Note the current vocabulary: apps provide the connection; plugins package apps, skills, and templates into discoverable workflows.
• Claude connected apps and MCP. Claude's MCP and connectors documentation describes the same idea through the Model Context Protocol: a standard way for an AI application to discover tools, read resources, and use reusable prompts. A Claude connector built on MCP can search a connected store, read project context, or call an approved tool — but the protocol is plumbing, not autonomy. It standardizes how the model asks; it does not decide that the model should keep working unsupervised.
• Gemini connected apps. Connected apps in Gemini let Gemini summarize Gmail threads, create calendar events, search photos and files, play media, or act inside approved mobile and smart-home apps, with per-app connection switches. You can direct a request with @ to a specific app, and Gemini pulls in connected context automatically when relevant.

The pattern across all three: drive, calendar, project context, or a permitted write action — inside a conversation you started, under permissions you granted. That is powerful, and it is still chat with tools. Attaching a tool does not by itself create a goal, a loop, or durable state.

The three questions

When someone demos a connected feature and calls it an agent, ask these three questions. All three must lean toward "yes" before the agent label earns its keep.

1. Who starts the action?

In connected chat, you start it. You type "find tomorrow's meetings" or "summarize this doc." The model responds once. In an agent workflow, the start can be a schedule, an event, or a standing goal — "every weekday at 7 a.m." — with no human typing a prompt each time.

2. Can it continue after the chat ends?

Close the chat window. Does the work continue? Augmented chat stops; its context was the conversation. An agent continues because its progress lives in run state — a job record, a queue entry, a database row — not in the transcript. Class 28 called this durable operational memory; Class 34 will deepen it.

3. Does it hold durable state and loop over tasks?

Does the system remember what it already did, observe each tool result, and choose the next step? A connector call is one lookup: search drive, return snippets. An agent loop is inspect-then-decide, repeated: check each calendar, detect conflicts, draft resolutions, queue them for approval, record what was queued.

A compact test table:

Calendar, both ways

The outline's calendar example makes the boundary concrete.

"Find tomorrow's meetings" — augmented chat. You ask; the model calls the calendar connector, returns times and titles. One turn, one tool call, no memory of yesterday's run, no follow-up unless you ask. Useful, fast, cheap, easy to verify: you glance at your calendar and confirm.

"Every morning prepare a brief, check conflicts, and queue drafts for approval" — agent workflow. A schedule wakes the system at 7 a.m. It reads today's and tomorrow's events (state loaded), pulls attendee context from mail or docs (tools), flags the double-booking at 10 a.m. (observation), drafts two reschedule messages but does not send them (bounded action with an approval gate), saves the brief and drafts to a review location, and stops with "brief ready, two drafts need review." Nobody typed a prompt. The value is the carried-forward packet plus the decision not to send without approval.

Notice what changed: not the calendar API, but the system around it — a trigger, a loop, a record, a stop rule, and a human review path. Same tool, different shape. That is why platform names mislead: "agent mode" on a button may still be one-turn chat with tools, while a plain scheduled script with a loop may quietly be a real agent.

A caution from the official docs, worth internalizing: permissions, workspace controls, and approval prompts still apply. A connector's write action (creating an event, editing a file) runs inside the platform's permission model — read automatically, consequential steps confirmed. An agent built on top inherits those limits but adds its own: budgets, timeouts, and human gates, which Class 30 teaches.

Exercise: write CONNECTOR-OR-AGENT.md

Pick one real platform feature you can inspect — a ChatGPT app, a Claude connector, or a Gemini connected app. Read its official page (links above plus the MCP introduction) and write a short file called CONNECTOR-OR-AGENT.md with:

1. What the feature connects to and what it may read or do. 2. Your answers to the three questions (who starts / survives closed chat / loops with state). 3. Your verdict: augmented chat or agent workflow — and what would have to change to flip it.

Finish line: one CONNECTOR-OR-AGENT.md file with a named feature, three answered questions, and a verdict.

Verify: re-read the feature's permission or approval behavior from the official docs and quote the line that supports your verdict. If you cannot find it, mark the verdict provisional.

Common failure mode: judging by the demo's confidence instead of the mechanism. A fluent "I'll handle your calendar" that waits for your next message is still chat. Check the trigger and the state.

Check your understanding

1. Why does adding an MCP tool to a chat model not automatically make it an agent? 2. Your inbox assistant summarizes a thread when asked, but also runs every hour and files receipts without prompting. Which part is augmented chat and which part is agentic? What tells you? 3. A connector can create a calendar event. Why does that capability alone not satisfy the "loop with state" test?

Next

You can now separate chat from agent, and connector from agent. One confusion remains: among non-chat systems, when is the right design a fixed automation, a known multi-step workflow, or a genuine agent? Lesson 29.3 gives you the simplest-one rule — because every unit of autonomy you add charges you in cost, latency, debugging, and review.