I've been thinking about a gap that's been nagging at me for a while. Claude Code has made me somewhere around 50x more productive as an engineer on certain classes of task - scaffolding, refactoring, working across large codebases without losing the thread. It's genuinely transformative in a way that's hard to overstate once you've properly internalised it. But the moment I close the terminal and open my email, that multiplier collapses. I'm back to being a normal person, clicking through Gmail threads, hunting for a Notion page I know exists somewhere, copying context from one tool into another like it's 2015.

Boris Cherny, who built Claude Code at Anthropic, made this point clearly on Lenny's Podcast recently. Coding was the first frontier to move because software already had the necessary substrate - compilers, test suites, version control, well-documented APIs, and a feedback loop that tells you instantly whether something worked. The rest of knowledge work didn't have that infrastructure. Until MCP standardised how AI connects to external tools, there was no equivalent connection layer, and so the gains stayed inside the terminal.

That's changing. I've spent the last few weeks running Claude Cowork connected to my full work stack - Gmail, Google Drive, Calendar, Notion, and Slack all wired in through the enterprise license, plus a local MCP server I built to fill a gap Cowork doesn't cover natively - and I wanted to write up what the setup actually looks like and what it's returning in practice.

The setup

Cowork launched in January 2026 as what Anthropic describes as "Claude Code for the rest of your work." The same agentic engine under the hood - takes a goal, creates a plan, breaks it into subtasks, executes across whatever tools you've connected. Instead of operating in a terminal against a codebase, it operates in a sandboxed VM on your desktop against your real work tools. The integration layer runs over MCP, which means you can connect it to most of the standard enterprise stack via OAuth, and the tokens never route through Anthropic's servers.

The native connectors cover Gmail, Calendar, Drive, Notion, and Slack reasonably well. What they don't handle well is Google Workspace as editable objects - Docs, Sheets, and Slides. Cowork's computer use approach to Google relies on reading what's rendered in the browser, and Google renders Docs and Sheets as a canvas rather than standard DOM elements, so screenshot-based interaction is unreliable. Updating a document with new information, for instance, keeps failing in ways that are hard to debug and harder to trust.

I spent about 20 minutes with Claude Code and good prompts building a local MCP server that goes direct to the Google Workspace API instead. For any developer comfortable with APIs this isn't a significant undertaking - it's just the faster path to something deterministic. It covers full read, write, create, and append operations across Docs, Sheets, and Slides, with formula support in Sheets and markdown export from both Docs and Slides. The two things together - Cowork for scheduling and orchestration, the local MCP server for Google Workspace - give me coverage that neither does alone.

What the workflow actually looks like

The highest-value thing I've set up so far is a post-meeting flow, and it's the clearest illustration of what this combination unlocks.

Google Meet saves transcripts natively to Drive. After a meeting I give Claude one instruction: read the most recent meeting transcript and update relevant projects in Notion with any decisions or new information, add action items where there are any, and note any emails I should respond to. That's it. Claude reads the transcript Doc via the MCP server, cross-references against my Notion project database and daily notes to figure out which projects are touched by the content, updates the right pages, and adds action items. The inference on which projects are relevant it figures out itself from the transcript content - I don't point it at a specific page.

Before this, the post-meeting workflow was 25-40 minutes of mechanical work: open the transcript, open each relevant Notion page, write up what changed, create tasks, go back to email. The actual thinking in that process - what matters, what's a decision versus a discussion, what needs to become a task - takes maybe five minutes. Everything else is assembly. That assembly is now gone.

Beyond the meeting flow, I have a daily morning briefing running as a scheduled task that pulls from Gmail, Calendar, and Slack, surfaces what actually needs attention, and is sitting there when I open my laptop. That's around 45 minutes of morning processing compressed to a five-minute read. A weekly digest runs on Fridays covering open items across the week. These run without me touching anything after the initial setup - that's the part that matters, because the time comes back every day rather than once.

Why this pattern works

The leverage isn't in any single workflow, it's in connecting the tools before configuring the tasks. Gmail in isolation gives you an expensive email summariser. The moment you add Calendar and Notion together, Claude can reason across all of them - it can see that an email thread about a project relates to a meeting on your calendar and open tasks in Notion, and act on that relationship rather than just reporting on each piece separately. The transcript flow only works because Drive, Docs, and Notion are all accessible simultaneously and Claude can do the synthesis step in the middle.

The other thing that compounds over time is context. The output quality is directly proportional to how much Claude knows about how you work. I have a project database in Notion and daily notes with project context, and Claude uses both when deciding where to route information from a transcript. That context layer is what makes the "figure out which projects are relevant" step work rather than requiring me to specify it every time. It starts rough and gets meaningfully better as the context builds up - the same principle as maintaining a good CLAUDE.md in a codebase, which I've written about in the context of Claude Code agents.

The honest numbers

I'm a few weeks in so I'm not going to claim a precise multiplier. What I can say is that roughly two hours a day is coming back - mostly from the morning briefing compressing the async information triage, and from the meeting workflow eliminating the post-meeting assembly work. That's not the 50x I see on greenfield coding tasks, and I've argued before that the headline AI productivity numbers for developers don't reflect the aggregate reality - the same caution applies here.

But two hours a day is 500 hours a year, and more importantly it's the high-friction mechanical hours rather than the thinking hours. The compounding effect of getting that time back, concentrated on actual judgment work rather than information assembly, is harder to quantify and probably more valuable than the raw number suggests.

The research on knowledge work productivity bears this out. Asana's data puts around 60% of knowledge workers' time in coordination overhead - searching, updating, reorienting, assembling status. The Harvard and BCG studies on AI in professional work found meaningful gains on tasks inside AI's capability boundary, with the biggest compression on exactly this category: structured information processing, cross-tool synthesis, document generation from source material. The meeting transcript to Notion update is a textbook example of that pattern.

Worth noting: Cowork is still a research preview. No cross-session memory yet, the desktop app needs to stay open during execution, and some enterprise compliance features aren't complete. For solo practitioners and small teams these aren't blockers, but at larger scale the audit trail question matters. The local MCP server approach also means my Google Workspace tooling isn't yet persistent infrastructure - it works, but it requires my machine to be running.

What comes next

The meeting flow is working and I'm planning to add more structure around it - a prompt template that captures decisions versus action items versus open questions more explicitly, and a weekly synthesis that looks across all the week's transcripts and updates a higher-level project view in Notion.

The broader pattern I'm working toward is what I'd call zero-assembly knowledge work: the mechanical layer of moving information between tools, updating documents, creating tasks, and drafting responses becomes something Claude handles, and my time goes entirely to the decisions and judgment that actually require me. I built something directionally similar with OpenClaw - an AI operations centre on a $6 Droplet - but the coverage was limited by what I was willing to wire up manually. Cowork plus the Workspace MCP server gets much closer to the full stack without the maintenance overhead.

Coding moved first because the substrate was already there. The substrate for knowledge work is being built right now, and the gap between what's possible and what most people are actually running is significant. I'd rather be in early with a rough setup that's improving than wait for it to be polished.