The data plane
connectors by role · the two-gate auth model · MCP servers · folder-scoped files
Cowork sees your data through three surfaces. Connectors are the named OAuth integrations (Slack, M365, Drive, Notion, Gmail, Calendar, Atlassian…). MCP servers are the protocol underneath — community and vendor-published, often with hundreds of tools per server. Folder-scoped file access is Cowork's quiet edge: local disk reads and writes, in folders you explicitly mark, that no cloud-only agent can touch.
Anthropic's docs walk you through enabling each one. They don't tell you which connectors each role on your team actually needs, what the auth blast radius is, or when an MCP server is the right answer vs. a connector. That's the gap.
Five workflows: connectors by role, the two-gate auth model, MCP as the long tail, folder-scoped file access, and how connectors compound. Side notes on M365 Copilot connectors, ChatGPT connectors, and Copilot Workspace where the same idea exists.
// Anthropic's launch keynote — the connector demo. Watch on YouTube →
Five IT-Pro roles, five starter sets
// audience: anyone deciding what to enable"Enable everything" is the wrong first move. Each connector is an auth boundary, an audit surface, and a token budget. Pick the smallest set that unlocks your highest-frequency task — add later when a real workflow demands it.
BA / Product
Enable: Atlassian (Jira + Confluence), Slack, Notion, Drive, Calendar. Leave off: source-control connectors unless you spec PRs.
Read the last 30 days of Jira issues in project FOO, pair with related Confluence pages, summarise the recurring complaint themes. Write a one-pager to Notion in the "Discovery" database.Why: the BA loop is read-many-sources, synthesise, draft. Five connectors covers 90% of it.
DBA / Data engineer
Enable: Slack, Drive, plus MCP for whichever warehouse you use (Snowflake, BigQuery, Supabase). Leave off: Calendar / Gmail at the agent layer — high noise, low value for queries.
Run this HogQL query on PostHog, screenshot the chart, post to #data with a 3-line interpretation and a link to the saved insight.Why: a DBA's leverage is "ask, screenshot, share." MCP servers carry the SQL surface; the OAuth connector to chat carries the share.
Tester / QA
Enable: Atlassian, Slack, Drive, plus any test-management MCP. Leave off: production warehouse connectors entirely.
Generate test cases for the user stories in epic FOO-42. For each story, propose 3 happy-path + 2 edge cases. Write them to a sheet in Drive grouped by story. Post a Slack thread with one line per story for the dev team.Why: testing connects spec to execution. The agent needs read access to specs and write access to test stores — no prod data exposure.
Support / Customer Success
Enable: Slack, Gmail, Atlassian, plus a ticketing MCP (Zendesk, Intercom, Front). Leave off: repo connectors unless you triage code reports.
Read the last 7 days of support tickets tagged "billing." Group by root cause. Draft a one-pager for the engineering team listing the top 3 with example ticket IDs.Why: support is the highest-volume connector role. Cap by tag or queue, not by time alone, or the context fills with noise.
Architect / Platform
Enable: all the above plus repo (Git provider) and observability MCPs (PostHog, Grafana, Sentry, Vercel, Supabase). Leave off: nothing — this is the role that benefits from the broadest read access.
Audit our auth middleware. Read every service in github.com/foo/services that imports auth, cross-reference with Sentry errors tagged auth in the last 30 days, write a Notion page with the top 5 risks and proposed fixes.Why: the architect's job is correlation across systems. The connector list is the toolbelt; the MCP layer is the rest of the workshop.
M365 Copilot: connectors are M365-anchored (SharePoint, Teams, Outlook, OneDrive). Strong for BA / support on a pure Microsoft stack; weaker once you reach for Notion, Jira on Cloud, or anything outside the M365 graph.
ChatGPT connectors: growing connector list with similar OAuth model, but they fire inside the chat surface, not an agent task loop — meaning the agent can't compose connector + filesystem + scheduled steps in one run.
Copilot Workspace: GitHub-native. Excellent for the architect / repo work; you'd reach for a different tool for everything else.
OAuth grants vs. agent scopes
// audience: security-conscious operatorsEvery connector you enable passes through two gates — and most security incidents we've seen come from confusing them.
- Gate 1: OAuth grant. Anthropic's connector asks for scopes from the upstream provider. "Allow Cowork to read messages and post on your behalf in Slack." Identity-level, lives in the upstream provider's app settings, not Cowork.
- Gate 2: Per-run scope. Even with the OAuth grant in place, the agent's per-task scope is governed by what you tell it in the prompt and what Cowork's permission settings allow. A run can be told "Slack: read only, no posts." OAuth grant is the ceiling; per-run scope is the floor.
The audit cadence we recommend:
The single highest-leverage move: if your upstream provider supports it, scope the OAuth grant to a specific channel / folder / project rather than the whole workspace. Slack: install Cowork to a dedicated channel for agent runs, not the whole team. Drive: scope to a single folder root. Notion: pick the databases the agent needs, leave the rest off the integration list.
Two-gate auth is industry-standard for OAuth agents. M365 Copilot enforces it through Entra ID conditional access; ChatGPT enforces it through the connector's per-action toggles. The Cowork-specific piece is the per-run scope override in the prompt — a fast belt-and-braces step the other two don't expose as cleanly.
When a connector isn't enough
// audience: anyone past the named-connector listConnectors are the curated short list. MCP (Model Context Protocol) is the open standard underneath — any SaaS, internal API, or local script can expose itself as an MCP server and Cowork picks it up. The vendor MCP servers we live in every day:
- PostHog — over 200 tools: query insights, manage dashboards, feature flags, surveys, error tracking, alerts. One authenticated MCP gives the agent the whole product surface.
- Notion — fetch / search / create-pages / update / move / comments. The canonical "agent's working memory" connector.
- Supabase — execute SQL, list tables, apply migrations, deploy edge functions, generate TS types. The platform surface, scoped by project.
- Vercel — deploy, fetch runtime logs, list deployments, get build logs. Useful for the "is the prod build green" reflex.
- Slack — read channel / thread, search, send message, schedule message, create canvas.
- Gmail + Calendar — search threads, draft, label, suggest meeting times.
- Atlassian, Hugging Face, Stripe, Zapier, custom internal MCPs — the long tail.
The pattern: when you reach for a connector and it isn't there, check whether the vendor publishes an MCP server. If yes, install it once and it's permanent. If no, MCP is simple enough that you can stand one up over a lunch break — an HTTP endpoint, a tool manifest, an auth handshake.
The MCP-specific gotcha: each MCP server gets its own instruction block in the agent's context. PostHog's says "you are a helpful assistant that can query PostHog API." Multiply by 5–10 servers and you've spent meaningful context before the user has typed anything. Curate the active list per project — you don't need the Stripe MCP loaded when you're writing a content brief.
# Cowork picks up MCP servers from settings.json { "mcpServers": { "posthog": { "url": "https://mcp.posthog.com", "auth": "token:..." }, "notion": { "url": "https://mcp.notion.com", "auth": "oauth" }, "supabase": { "url": "https://mcp.supabase.com", "auth": "token:..." } } }MCP is an open standard. ChatGPT, Codex, and several other agent platforms can consume MCP servers too — same protocol, different host. The differentiator isn't the protocol; it's whether the agent loop around it can compose MCP calls with filesystem writes and scheduled triggers. Cowork composes all three; ChatGPT's surface keeps them separate.
Cowork's quiet edge
// audience: everyoneThis is the one feature where the comparison table tells the whole story.
- Cowork: mark a folder, the agent reads and writes inside it. Persistent. The artifact ends up on disk you can git-commit, ship as a file, or open in Excel.
- ChatGPT: upload files to the chat, get them back as downloads. No persistent local view of a folder.
- Codex (cloud agents): cloud-only working tree. Output ships as a branch or a zip.
- Copilot Workspace: GitHub-anchored. The "filesystem" is the repo.
What this unlocks — the workflows the cloud-only agents can't do cleanly:
- Build a multi-tab xlsx in
~/work/q1/, open it in Excel, edit a cell, save, ask Cowork to extend the analysis. No re-upload. - Maintain a folder of meeting notes; ask Cowork to read everything since last Tuesday and ship a status doc. No tarball.
- Run a content pipeline that produces 50 HTML files into a real repo. Commit. Push. Deploy. No zip-then-extract.
- Open a vendor CSV in Excel, look at it, then ask Cowork to "do what I'd do if I had three hours." It reads the file in place.
The discipline: mark the smallest folder that fits the task. Marking ~/ is the lazy default and the riskiest. Marking ~/work/cowork-c03-draft/ means the agent can only see and only write inside that folder — you don't have to argue about whether it might overwrite something elsewhere because it physically can't.
No comparable surface in ChatGPT, Codex cloud, or Copilot Workspace. The closest analogue is Claude Code's repo-rooted access — the same idea, scoped to a working directory for code work. Cowork is the same idea scoped to any folder for any work.
Three connectors, one run
// audience: anyone with > 5 connectors enabledThe named-connector list isn't the differentiator — ChatGPT and Copilot have most of them too. The differentiator is composing them in a single agent loop without writing glue. Three composed-loop examples we run:
# Example A — Triage loop Read the last 50 messages in Slack #ops. For each one referencing an outage, search Notion for the runbook and Jira for an open ticket. Compose a one-pager in Drive with one row per outage: Slack link, runbook link, ticket status, owner. Post the Drive link back to #ops with a one-line summary. # Three connectors (Slack, Notion, Drive) + one Drive write + one repost. # In ChatGPT you'd hop surfaces three times. In Cowork it's one task. # Example B — Pipeline loop Run the pickbits-daily-trends skill against today's sources. Render the HTML to ~/pickbits-daily/{date}.html. Post the eight platform variants from social.md to a Notion staging board. Notify #content with the Notion link. # Filesystem + Notion + Slack composed; the skill is invoked from within the run. # Example C — Investigation loop Query PostHog for sessions with errors in the last 24h. Cross-reference with Sentry issues by user_id. Read the relevant service's source in ~/repos/api/ to identify the failing handler. Draft a Notion ticket + Slack alert to the on-call rota. # PostHog MCP + Sentry MCP + local FS + Notion + Slack. Five surfaces. One agent.The principle: if a task requires hopping more than two surfaces, write it as one Cowork prompt instead of three chats. Each surface-hop costs you a re-context, a re-paste, and a window switch. Letting the agent do the hopping turns five minutes of swivel-chair work into 90 seconds.
ChatGPT connectors can call multiple connectors inside one chat, but the surface is conversational — no scheduled trigger, no filesystem step. Zapier / Make.com compose connectors visually and are excellent at deterministic flows; Cowork is the choice when the middle step needs judgment (which two errors are the same incident? which ticket matches this Slack thread?).
The over-connector trap
// audience: everyoneEvery connector is overhead. Don't enable one until a real workflow needs it. Specifically:
- If you've used it twice this quarter, you don't need it on every machine. Enable on the one where the workflow lives; revoke elsewhere.
- If the agent only ever reads from it, see if MCP scopes can be read-only. Smaller blast radius, same value.
- If the connector is to a high-stakes system (payments, identity, prod data), keep it off the agent entirely — have Cowork draft the work; have a human use the system directly to execute.
- If two connectors duplicate (a calendar in your Google account and a Calendar MCP), pick one. Each duplicates the agent's understanding of "where do I look for events?" and that ambiguity is where mistakes hide.
The good news: Cowork's connector list is reversible. Revoke a connector, the OAuth grant on the upstream provider is gone, the agent loses access. No ghost permissions, no migration cost.
You wired connectors. We help you wire the rest.
Module C03 of five in the Cowork for IT Pros track. If you want this built on your team's actual stack — with your connectors, your auth model, your audit cadence — our advisory engagements are scoped for exactly that.
← Back to Cowork track ← C02 · Schedule C04 · Curate →