Connectors, Projects, and the Copilot Cowork partnership

Cowork doesn't live in a silo. Your work lives in Google Drive, Notion, Slack, Jira, and a dozen other tools — and the whole point of delegation is getting finished deliverables from a single session, not copy-pasting between apps. Connectors are how Cowork reaches into those systems, and Projects are how it stays focused once it gets there.

Two types of connectors

Web connectors are browser-based API integrations. They connect Cowork to cloud services: Google Drive, Gmail, Slack, Notion, Asana, Linear, Jira, HubSpot, Salesforce. You authorise the connection once, and Cowork can read and write to those services during a task. Ask it to pull all open Jira tickets for a sprint, summarise them, and write a status report to out/sprint-report.docx — it does that without you downloading anything manually.

Desktop extensions are local MCP servers with deeper system access. They go further than web connectors in one important direction: bidirectional flow. A web connector can read your Notion database and write back to it. A desktop extension can do that AND save external data locally as real files, AND use local files as input for external actions. You can pull meeting transcripts from an external system into your raw/ folder, run analysis in Cowork using those files, and push the summary back out — all in one task. That bidirectional loop is unique to Cowork's architecture.

The Copilot Cowork partnership

In March 2026, Microsoft and Anthropic announced Copilot Cowork — Cowork's agentic capabilities running inside M365 Copilot, embedded in Outlook, Teams, and Excel.

The key difference from Anthropic's Cowork: Copilot Cowork runs in the cloud within the M365 tenant. Your data doesn't leave Microsoft's environment. That matters for organisations under enterprise data-protection requirements.

If your team lives in M365, Copilot Cowork is the path — you get the same agentic capabilities without moving data outside the tenant. If your workflows are local-first (file systems, non-Microsoft tools, scheduled overnight tasks), stick with Anthropic's Cowork. The two serve different deployment contexts, not different kinds of work.

Projects solve context bleeding

Without structure, Cowork sessions bleed into each other. You're halfway through a financial model task and you fire off one unrelated question about a client proposal — now the context window contains both, and Claude is working from a muddled picture of what you're trying to do.

Projects are the container that fixes this. Each project has its own files, instructions, memory, and links. Memory persists within a project across sessions — Claude knows what it learned last time. Nothing bleeds from one project into another.

The pattern is simple: one project = one context. One project per client, one per ongoing initiative, one per life domain. Your marketing project doesn't know about your financial project. Your house-renovation project doesn't contaminate your job-search project.

Mobile Dispatch ties into this too — when you queue a task from your phone, it runs inside the correct project context. The right files, the right instructions, the right memory.

The practical setup

Set up a project the first time you start a sustained workstream — not after you've already made a mess. Projects are cheap to create and expensive to wish you'd created earlier. A project for a quarterly report, a project for a client engagement, a project for a product launch. Each one starts clean and stays clean.

Within each project, the familiar hierarchy applies: context/ for reference docs and past examples, raw/ for untouched inputs, work/ for in-progress operations, out/ for finished deliverables. The project boundary is the outer container; the folder hierarchy is the inner structure.