How Notion Built with Claude Managed Agents

1. The delegate model: Claude inside your workspace

When most people first encounter AI assistants, they think of them as external advisors: you ask a question, you get an answer, and then you go do the work yourself. Notion’s integration with Claude Managed Agents is built around a fundamentally different model. Claude is not an advisor you consult before doing work — Claude is a delegate that does the work inside your workspace, with access to your pages, databases, and files.

This distinction matters enormously in practice. An external advisor can tell you how to write a project spec; a delegate writes it, puts it in the right Notion database, links it to the relevant project, and notifies the team. An external advisor can suggest how to structure a website; a delegate builds the pages, fills in the content, and sets up the structure. The scope of what becomes possible with delegation rather than consultation is dramatically larger, but it requires a different kind of integration with the underlying workspace.

Eric Liu’s presentation at Anthropic’s event in April 2026 demonstrated exactly this pattern. Rather than building a chatbot that sits alongside Notion and answers questions about it, his team built a Claude integration that operates within Notion as a first-class participant. Claude can read from and write to the workspace, navigate its structure, create and edit content, and complete multi-step tasks that span many pages and databases — all on behalf of the user who requested the work.

The practical outcomes are striking. Engineers on Notion’s team use the integration to ship code: they describe what they want built, and Claude works through the coding task, using relevant workspace context (specs, past decisions, API documentation stored in Notion) to inform its implementation. Other teams use it to build websites from a brief, create presentation decks from meeting notes, or draft one-pagers from scattered research pages. The same underlying capability — a Claude delegate with workspace access — surfaces as radically different products for different users.

2. Technical architecture of the integration

The integration rests on three technical pillars: a Notion MCP server, a Managed Agents session configuration, and workspace context injection.

The Notion MCP server is the bridge between Managed Agents and Notion’s data. It exposes Notion’s core operations — reading page content, querying databases, creating and updating pages, navigating workspace structure — as MCP tools that Claude can call. Building an MCP server for an existing product is relatively straightforward because MCP is a standard protocol: you essentially wrap your existing API with the MCP adapter interface. For Notion, this means Claude can call read_page, create_page, query_database, and similar operations as naturally as it might call a web search tool.

The Managed Agents session configuration defines what Claude can do within Notion. This includes which MCP tools are available, what permissions are granted (read-only vs. read-write, which parts of the workspace are accessible), and what long-term memory stores the agent can use. Critically, the session also injects workspace context at startup: information about the user’s workspace structure, their recent activity, and any preferences stored from previous sessions. This context primes Claude to operate as a knowledgeable participant in the workspace rather than a blank-slate model that needs to re-learn the workspace structure on every task.

Memory across sessions is what enables the delegate model to become more useful over time. After completing a task, Claude can write observations to long-term memory: how this user prefers their project specs structured, which databases the team uses for which purposes, the naming conventions for pages in this workspace. Future sessions can retrieve this accumulated knowledge, making Claude increasingly effective as a workspace-specific delegate rather than a generic AI assistant.

3. Use cases across teams

The engineering team’s use case is the most technically intensive: describing a feature to build, and having Claude work through the implementation using workspace context (design specs, past decisions, API documentation) to inform the code. This requires Claude to read extensively from the workspace, understand the codebase structure, and produce working code — then update the relevant Notion ticket or spec page with the result.

Marketing and content teams use the same integration differently. A brief that lives in a Notion page becomes the input for a full website build: Claude reads the brief, creates a set of pages in the workspace with appropriate structure and content, and links everything together. This is pure content creation and organization work — the same delegate capability, applied to a completely different job.

Operations teams use the integration for document assembly: turning scattered notes, meeting records, and research pages into clean one-pagers, reports, or presentations. Rather than manually synthesizing information from a dozen Notion pages, a team member delegates that synthesis to Claude, which reads all the relevant pages, identifies the key information, and produces a polished output.

4. Lessons from building a production Managed Agents product

Building on top of Managed Agents is a different experience from building on top of a model API, and the Notion team’s experience surfaced several important lessons.

Workspace context quality drives output quality. The biggest lever on Claude’s effectiveness as a workspace delegate is not prompt engineering — it is the quality of the context injected at session start. Workspaces with well-organized pages, clear naming conventions, and consistent database schemas give Claude much better material to work with. Teams that invested in workspace hygiene before integrating the Claude delegate saw dramatically better results.

Permission design requires careful thought. Granting a delegate broad read-write access to a workspace creates leverage but also risk. The Notion team settled on a progressive permission model: Claude starts with read access and limited write capabilities, and users can explicitly grant broader permissions for specific tasks. This preserves user trust while enabling the full power of the delegate model.

Long-form task transparency matters. For tasks that take multiple minutes — building a full website from a brief, synthesizing a complex report — users need to understand what Claude is doing while it works. The integration surfaces agent activity in real time, showing which pages are being read, what is being created, and what decisions are being made. This transparency builds confidence and lets users intervene if the agent goes off-track.

🧠 Check your understanding

4 questions · your answers are saved in this browser only

1. 1. What is the key difference between the 'delegate' model and the 'chat assistant' model for AI integration?

   Delegates are cheaper to run than chat assistants A delegate operates inside the workspace and does the work; an assistant gives advice that you then act on yourself Chat assistants can use MCP; delegates cannot Delegates only work for technical tasks like coding

   The delegate model means Claude operates inside the workspace as a first-class participant, completing work autonomously. A chat assistant advises from outside; you still do the execution. The delegate model dramatically expands what becomes possible.

2. 2. What is the primary role of the Notion MCP server in this integration?

   It stores Claude's long-term memory between sessions It translates Notion's API operations into MCP tools that Claude can call — read pages, query databases, create content It handles billing and rate limiting for the Managed Agents API It provides Claude with internet access to research information

   The Notion MCP server wraps Notion's existing API with the MCP adapter interface, exposing workspace operations as tools Claude can call within its Managed Agents session — read_page, create_page, query_database, and similar operations.

3. 3. Which of the following is NOT listed as a use case for Notion's Claude delegate integration?

   Engineers shipping code using workspace context like specs and API docs Marketing teams building websites from a brief stored in Notion Ops teams synthesizing scattered notes into clean one-pagers Sales teams making automated phone calls to prospects

   The three use cases described are code shipping (engineering), website building from briefs (marketing), and document assembly from scattered notes (operations). Phone outreach was not mentioned.

4. 4. What was the biggest single lever on Claude's effectiveness as a Notion workspace delegate?

   Fine-tuning Claude on Notion-specific data Prompt engineering the task descriptions carefully The quality of workspace context — well-organized pages, clear naming, consistent database schemas Granting Claude the broadest possible permissions from the start

   The Notion team found that workspace context quality — organization, naming conventions, schema consistency — was the biggest driver of output quality. Teams with well-maintained workspaces saw dramatically better results from the Claude delegate.

Reset quiz

🛠️ Build it yourself

Follow these exact steps to reproduce it yourself

1. Define your workspace surface — Identify the core data entities in your product (pages, records, files, databases). These will be what the delegate reads from and writes to.
2. Build an MCP server for your product — Create an MCP adapter that wraps your product’s existing API, exposing read, write, search, and navigate operations as MCP tools. Start with read operations only; add write capabilities incrementally.
3. Design your context injection — Decide what workspace context to inject at session start. User preferences, recent activity, workspace structure, and relevant domain knowledge all help Claude operate as an effective delegate rather than a blank slate.
4. Define your permission model — Design a layered permission system: default permissions (what Claude can always do), elevated permissions (what users can explicitly grant per task), and forbidden operations (what Claude should never do regardless of requests).
5. Configure long-term memory schema — Decide what the delegate should remember across sessions: user preferences, workspace conventions, accumulated domain knowledge. Write a schema for these memory entries.
6. Build real-time transparency UI — For tasks that take more than a few seconds, surface what the agent is doing to the user. Show which data is being read, what decisions are being made, and what is being created or modified.
7. Start with a constrained scope — Launch your delegate with a specific, well-defined task scope. Expand to more task types after you have validated quality and built user trust. Notion’s team did not try to make their delegate do everything on day one.