Introducing Notion’s Developer Platform: Keynote (Ivan Zhao)

Summary (Technological concepts & developer/product features)

1) Shift toward a developer platform (key improvements mentioned)

Notion has been expanding developer-facing capabilities over the past year, including:

• API for database views
• Personal access tokens
• MCP token-efficiency improvements (“MCP 91% more token efficient”)
• Markdown API, enabling Notion to “speak the native language of agents”

Overall, Notion is evolving from a mostly non-developer-centric platform into one designed for agent ecosystems and developer integrations.

---

2) Custom Agents (context: no-code background agents)

Notion previously launched Custom Agents (about 3 months prior to the keynote) that:

• Let users create powerful agents running 24/7 in the background
• Require no coding
• Have reached widespread usage: over 1 million custom agents created by users

Examples highlighted:

• Vercel: auto-updating product release organization (e.g., self-updating roadmap)
• Rakuten: night-time request triage → morning Slack reports per team
• British Columbia / Vancouver Fire Department: training + answering FAQs

Reported customer preferences:

• Collaborative: one person building an agent benefits the whole company
• Easy to set up: non-technical users can build
• Model agnostic: can choose frontier models or cost-efficient open-weight models

---

3) “Notion Developer Platform”: 3 core pillars

The platform is described as a set of tools that enables developers/agents to:

A) Sync any data into Notion

Goal: provide a shared, editable canvas (databases + pages) where team and agent context live.

Why raw Notion API alone is difficult:

• API rate limits
• Boilerplate glue code
• Limited observability (debugging a distributed sync system is hard)
• Need to run and manage servers/deployments

What’s new:

• Workers-based syncing (via the platform) to connect “any system with an API,” including:
  • Internal databases/services (e.g., Postgres, Snowflake)
  • Complex apps (e.g., ServiceNow, NetSuite) via OAuth
• Platform-provided sync controls:
  • pacing/rate-limit handling
  • backfills
  • incremental syncing
• SDK designed to remain simple enough for personal/side projects while supporting enterprise-grade sync patterns.

B) Build any tool (custom automation hosted by Notion)

Developers can create real-code automation hosted by Notion, positioned as enabling more reliable and secure agent workflows than “agent-only” reasoning.

It introduces the idea of “tools” that an agent can call, backed by code.

C) Orchestrate any agent (external agents inside Notion)

A new API capability invites external agents into Notion so they appear as collaborators inside docs/tasks.

Examples mentioned for external agents include:

• Coding agents like Claude/Codex
• Specialized agents (example partner: Deckagon, plus “something you build yourself”)

Theme: unify multiple agents into a single Notion workspace for collaboration and workflow execution.

---

4) Workers: the foundation for syncing + tools

A recurring technical primitive is introduced:

• Workers are:
  • Small TypeScript programs
  • Deployed into Notion-managed sandboxes
  • Reliable and deterministic, run on standard CPUs
• Notion handles:
  • deployment, execution, security, and governance
• Workers expose capabilities via tools/skills so coding agents can:
  • test, introspect, validate behavior

---

5) Tutorial/demo: building a Stripe sync (end-to-end development flow)

The keynote includes a concrete step-by-step example demonstrating Workers + sync setup.

Using the Notion CLI “NTN”:

• Initialize a worker: NTN workers new
• Build sync via a prompt to a coding agent (Codex) using a sync skill
• Deploy via NTN workers deploy
• Push secrets/environment variables via NTN workers env push
• Check status via a sync status command (sync becomes “healthy” and linked to a Notion database)

Result:

• Stripe customers, subscriptions, invoices appear in a Notion database
• A “shared dashboard” is created using a personal agent UI
• Data is described as syncing in real time

Follow-on automation example:

• A custom agent (“Renewal Ronnie”) runs nightly on synced billing data to proactively notify account teams.

---

6) Observability + enterprise control features for syncs

The platform provides built-in observability:

• Manage deployed workers
• View health
• View sync timing and performance metrics
• Read detailed logs per execution

Enterprise requirements covered:

• OAuth abstraction (SDK handles handshake/refresh; secrets via secure environment variables)
• rate limit controls using a pacer (platform ensures requests stay within defined limits)
• The sync skill can configure the pacer

---

7) Workers “tools”: replacing MCP gaps with validated, deterministic workflows

A separate deep-dive (Jay Clam) discusses extending Custom Agents when MCP is insufficient.

Problem:

• MCP servers may lack required tools or can’t cover internal APIs.

Solution: Workers tools

• TypeScript functions connected to agents without deploying extra infrastructure
• Connect to APIs, internal services, databases, etc.

Advantages over typical MCP tool calling:

• Strict validation/guardrails (workers can enforce preconditions)
• Deterministic workflow logic to avoid wasting tokens on multi-step agent “thinking” between X→Y→Z steps
• Avoids “spaghetti” visual workflow builders; instead uses Turing-complete code

---

8) Tutorial/demo: a feature-flag tool workflow (validate then toggle)

Another example builds a worker to handle conditional feature-flag enablement.

Scenario: enable “custom domains” for a customer (Gummy Bear Aeronautics) only if:

• the flag is off
• the workspace is on the enterprise plan

Workflow steps:

• Query feature flags API for default plan requirement
• Check workspace plan via read-only DB replica
• Toggle feature flag only when preconditions are met
• Log the outcome to a customer log database in Notion

Outcome:

• If precondition fails (e.g., customer is only on pro plan), the toggle is blocked and the attempt is recorded for future team/agent context.

Deployment: again uses the NTN CLI; Notion installs/builds dependencies and deploys to sandboxes automatically.

---

9) Orchestration UI: external agent collaboration inside Notion

A design engineering segment (Jeffrey) previews orchestration and introduces external agents.

Motivation:

• Agent usage can become chaotic (multiple chats/apps, copy-paste context, juggling terminal tabs).

Proposed solution:

• A unified Notion-based UI where:
  • multiple agents (not only Notion custom agents) can be used together on tasks
  • agents operate as collaborators in shared Notion docs/tasks

Demo flow described:

• From a Notion spec page:
  • start a Claude agent for technical plan
  • bring in Deckagon for customer support quotes
  • coordinate engineers via comments
  • Claude-generated plan becomes collaborative
  • Codex performs PR review and updates within the same Notion task

“Infinite minds” concept via scale:

• Task boards can automatically progress through stages (e.g., Decagon → Claude → Codex)
• Agents work to bring tasks to a human-ready state

---

10) Product availability claim

Final messaging emphasizes:

• Platform works seamlessly on mobile
• Developer platform capabilities: sync any data, build any tool, orchestrate any agent
• Stated as available today, with some launches planned over subsequent months (including timing details for external agent API coming soon/over coming months)

---

Main speakers / sources

• Ivan Zhao (keynote framing; presented developer platform highlights)
• Eric (Notion product team) — Workers + sync deep demo; observability/rate-limit/OAuth abstractions
• Jay Clam (Notion software engineer) — Workers tools vs MCP limitations; validation + deterministic workflows
• Jeffrey (Notion design engineer) — Orchestration UI preview; external agents in Notion and agent workflows at scale
• “NTN” / Notion Developer Platform — Primary system being demonstrated