You Can Now Delegate Tasks to Cursor From Inside Notion

Notion used the Cursor SDK to embed coding agents directly inside its workspace, and the result is a new way to put Cursor to work: you can now delegate tasks to Cursor from inside Notion. In Cursor's words, you can tag Cursor in a doc, mention Cursor in a thread, or assign Cursor an issue in your database -- and Cursor takes the work end to end, planning, building, testing, verifying its own work, and then opening a PR. Cursor says Notion built the integration in a few weeks using the Cursor SDK.

For the platform this is built on, see our Cursor SDK public beta coverage.

Key Takeaways

• New surface: delegate tasks to Cursor from inside Notion -- tag Cursor in a doc, mention it in a thread, or assign it an issue in a database.
• End to end: Cursor plans, builds, tests, verifies its work, and opens a PR.
• Who built it: Notion built the integration, in a few weeks, using the Cursor SDK.
• Thread = agent: a Notion thread becomes a Cursor agent; every message in that thread becomes an agent run.
• First message = setup: the first message creates the agent with the prompt, selected repo, model, MCP servers, and automatic PR creation enabled.
• Live and resumable: follow-ups start new runs, streamed over SSE so users can watch live and resume from the last event if a connection drops.
• Real-time workspace access: custom remote MCPs let Cursor read and write into the workspace it is working for, with full state awareness.

What You Can Now Do

You can hand Cursor a task without leaving Notion. Cursor lists three entry points: tag Cursor in a doc, mention Cursor in a thread, or assign Cursor an issue in your Notion database. From any of those, Cursor takes the work end to end -- it plans the change, builds it, tests it, verifies its own work, and opens a pull request. The delegation surface is the document or thread you were already working in, not a separate tool you have to context-switch into.

This is the practical payoff of the Cursor SDK: a coding agent that lives where the work is described. The task description, the discussion, and the agent run all share one surface.

How a Notion Thread Becomes a Cursor Agent

Cursor describes a clean mapping between Notion's primitives and the SDK's. A Notion thread becomes a Cursor agent, and every message in that thread becomes an agent run. The first message does the setup work: it creates the agent with the prompt, the selected repo, the model, the MCP servers, and automatic PR creation enabled. Every follow-up message after that starts a new run on the same agent.

The mapping is worth internalizing because it explains the behavior you see:

That structure means a thread carries its own durable agent context, and the conversation history in Notion lines up one-to-one with the run history in Cursor.

Live Streaming and Resumable Runs

Cursor says follow-up runs are streamed over SSE so users can watch the agent work live, and can resume from the last event if a connection drops. The practical effect is that a long-running task -- the kind that plans, edits, runs tests, and opens a PR -- stays observable inside Notion while it happens, rather than being a black box you check on later. A dropped connection does not lose the run; it resumes from the last streamed event.

Real-Time Workspace Access via Custom Remote MCPs

The integration is not read-only. Cursor says custom remote MCP servers let Cursor read and write into the workspace it is working for, in real time and with full state awareness. That is the mechanism that lets the agent stay in sync with the Notion workspace it was delegated from while it does the coding work, rather than operating on a stale snapshot.

Customizing the Agents

Cursor says users can customize the agents that handle delegated work. Per Cursor's blog post, you can:

• Use templates such as codebase Q&A, repo exploration, or bug triage.
• Write custom instructions.
• Choose which MCP servers, skills, and subagents the agent has access to.
• Set custom triggers.

These are the same primitives the SDK exposes generally -- templates, instructions, MCP servers, skills, subagents, and triggers -- surfaced inside Notion's product rather than in code.

Why It Matters

Notion's integration is the clearest case study yet for the Cursor SDK as a platform play. Cursor describes the SDK as the harness, models, and runtime it uses in production, exposed so developers can bring Cursor into their own products, infrastructure, or workflows. The Notion build is exactly that: a third-party product team embedding Cursor's production coding agent behind their own surface, reportedly in a few weeks.

For teams, the takeaway is concrete. Work gets described in tools like Notion long before it reaches an editor. Putting a coding agent at the point of description -- tag it, mention it, assign it an issue -- collapses the gap between writing down what needs to happen and a PR that does it. Cursor does not state explicit product limitations in the post, so the boundaries of what Cursor will and won't take on from a Notion task are best discovered in practice.

The canonical reference is Cursor's own write-up, "How Notion used the Cursor SDK to embed coding agents." For the underlying platform, our Cursor SDK public beta piece is the right starting point.