Notion 3.5 Turns the Workspace Into an Agent Hub
Notion 3.5's Developer Platform adds Workers, live database sync, and first-class Claude Code and Cursor support - turning the workspace into an AI agent orchestration layer.
6 min read
Your support team runs three systems: Zendesk for tickets, Postgres for usage data, and Notion for internal documentation. Every Friday, someone on the team copies ticket counts into a Notion table, cross-references usage drops by hand, and writes the week's summary in prose. Two hours, every week, done by a human because nothing connects the pieces automatically.
That's the problem Notion's new Developer Platform is built to remove.
Released on May 13, 2026 as version 3.5, the platform adds a hosted runtime for custom code called Workers, live database sync from external APIs, and direct integration with coding agents including Claude Code, Cursor, Codex, and Decagon. Notion CEO Ivan Zhao framed it without much preamble: "Any data, any tool, any agent."
The company says customers have already built over 1 million agents since February's Custom Agents launch. The new platform is what those agents were missing: a way to pull in external data and run custom logic without spinning up separate infrastructure.
TL;DR
- Notion 3.5 launched May 13, 2026 with the new Developer Platform
- Workers is a hosted runtime for custom code - free until August 11, 2026, then switches to Notion credits
- Database sync pulls live data from Salesforce, Zendesk, Postgres, Strava, and any API-based source
- External Agents API integrates Claude Code, Cursor, Codex, and Decagon natively
- Agent SDK (alpha) lets teams embed Notion agents in external apps like CRMs and Discord
- CLI available on all plans; Developer Portal at app.notion.com/developers
The Pipeline, Step by Step
The core shift in Notion 3.5 is that data no longer has to travel into Notion manually. The full flow for that Friday report now looks like this:
- Sync external sources - A Worker pulls Zendesk ticket data and Postgres usage metrics into Notion databases on a schedule via the database sync feature. No webhook server, no custom ETL. The data is in Notion when the agent needs it.
- Apply custom logic - The Worker function handles business-specific transforms: calculating churn indicators, flagging anomalies, merging ticket counts with usage trends.
- Data lands in Notion - Results populate a standard Notion database - queryable, filterable, and readable by agents and humans alike.
- Assign work to an agent - Via the External Agents API, the workflow assigns the report task to Claude Code or Cursor, with the prepared database as context.
- Agent writes the output - The coding agent generates the summary, formatted as a Notion page and sourced directly from the synced data.
- Webhook fires downstream - Notion triggers a webhook to Slack or email. The report goes out without anyone touching it.
Notion's CLI sits across every step. Install it, authenticate, and you can deploy Workers, read and write Notion content programmatically, and manage the full pipeline from a terminal:
ntn auth
worker.deploy()
That's the confirmed interface from Notion's own blog post. The rest of the pipeline - syncs, triggers, agent assignments - is configured through the Developer Portal at app.notion.com/developers, which opened with the platform launch.
Workers: Hosted Glue Code
Workers is the most significant piece of Notion 3.5 for engineering teams. It's a cloud-based sandbox where you deploy custom code - the kind of glue logic that currently lives in a Lambda function no one remembers who wrote, or a cron job on a server in a corner.
The sandbox environment, resource limits, and supported languages aren't fully documented yet. Workers are free through the beta period, switching to Notion's existing credit system on August 11, 2026. Pricing per invocation hasn't been announced.
Database Sync: External Data, Inside Notion
Database sync connects Notion databases to any service that exposes an API. Salesforce, Zendesk, Postgres, and Strava are named at launch, but the underlying mechanism - a Worker that runs the sync logic - generalizes to any API-based source. This is the piece that matters most for teams who've been maintaining separate connectors between their data systems and Notion.
Notion Workers lets teams deploy custom agent tools that run in a hosted sandbox - removing the need for external compute for workflow glue logic.
Source: notion.com
External Agents API: Bring Your Own Agent
Rather than building its own coding agents, Notion is positioning as the coordination layer for agents teams already use. Claude Code, Cursor, Codex, and Decagon are available at launch. The API is open, so teams can plug in internal agents too.
From within Notion, you can assign tasks to an external agent, track its progress, and receive output in the same workspace where the task originated. If you've been comparing Claude Code and Cursor for your team, our full breakdown of Claude Code vs. Cursor vs. Codex covers the tradeoffs - both are supported on day one.
Notion is also shipping enhanced MCP compatibility with the Developer Platform. If your stack already uses the Model Context Protocol for agent tool access, the new platform integrates at that layer too.
The Old Way vs Notion 3.5
| Step | Before Notion 3.5 | With Notion 3.5 |
|---|---|---|
| Pull external data | Custom webhook server or ETL job | Database sync via Workers |
| Transform data | Separate cron script or Lambda | Worker function inside Notion |
| Store results | Write to a database or spreadsheet | Notion database entry |
| Trigger an agent | Manual API call or external scheduler | External Agents API |
| Track agent progress | Poll agent API manually | Notion task view |
| Deliver output | Separate Notion API write | Agent writes directly to Notion |
The "before" column isn't theoretical. Teams running agents against Notion today are maintaining exactly this stack - scattered across multiple services, owned by whoever set it up, and fragile in ways that usually only become visible on a Friday afternoon.
The Notion CLI runs on all subscription plans, giving developers and coding agents direct programmatic access to the workspace.
Source: notion.com
Where It Breaks
Beta software carries real risks here, not just the standard disclaimer.
Workers pricing after August is unannounced. If credit costs make high-frequency syncs expensive, teams will run their own compute instead. Notion's credit pricing for Custom Agents hasn't been universally popular, and Workers runs on the same system.
Database sync is only as reliable as the source APIs. Salesforce's API versioning has a history of quiet deprecations that break integrations without warning. A sync that works in May 2026 can fail silently after a Salesforce update.
The External Agents API supports four named partners at launch. Teams using anything outside Claude Code, Cursor, Codex, or Decagon - including open-source coding agents or custom deployments - have to build the integration themselves using the open API spec.
Agent SDK is flagged as alpha. Notion explicitly says it isn't production-ready. Don't build customer-facing workflows on it yet.
Notion's core claim since it launched was that the workspace is where context lives. Version 3.5 extends that claim: context is also where agent work should start and land. That's a reasonable place to plant a flag if the connectors hold up, the credits stay cheap enough to run at scale, and the agent ecosystem grows past the initial four partners. The platform's shape - data in, code in the middle, agents at the edge - looks a lot like what infrastructure engineers have been building manually for the last year. Notion is betting they'd rather not.
Sources:
