Notion API wird zur Agentenplattform: Ab 11. August kosten Workers Credits

Die Notion API wird zur Agentenplattform: Am 13. Mai hat Notion seine Developer Platform mit Workers, einer External Agent API und einer CLI veröffentlicht, durch die Claude Code, Cursor und Codex als vollwertige Akteure im Workspace auftreten. Dahinter steckt mehr, als die Ankündigung vermuten lässt: Notion greift nach der Steuerungsebene für Agenten. Entscheidend ist dafür ein Datum – der 11. August.

Was Notion veröffentlicht hat

Sechs Bausteine in einem Release. Workers – eine gehostete Laufzeit für Node/TypeScript, derzeit in der Public Beta und ausschließlich für Business und Enterprise verfügbar. External Agents in der Alpha-Phase, inklusive sofort einsatzbereiter Partnerintegrationen für Claude Code, Cursor, Codex und Decagon. Eine External Agent API für eigene Agenten, zugänglich über die Warteliste zur Private Beta. Eine CLI namens ntn, verfügbar in allen Tarifen und installierbar mit curl -fsSL https://ntn.dev | bash. Datenbanksynchronisierung über Workers für Zendesk / Salesforce / Postgres. Webhook-Trigger: von jeder App über einen Worker nach Notion. Quelle: Notions Ankündigung der Developer Platform.

Zwei weitere Signale sind wichtig. Mit dem Notion Agent SDK (Alpha, Warteliste) lassen sich Notion Custom Agents in MS Teams, Discord, Amplitude und Hex einbetten. Governance ist Teil des Pakets – mit schrittweiser Freigabe von Agentenaktionen, isolierten Workers sowie eigener Authentifizierung und eigenen Berechtigungen je Deployment.

Was die Notion API strategisch verändert

Die eigentliche Schlagzeile lautet nicht: „Notion veröffentlicht ein SDK.“ Sondern: „Notion erklärt sich zum Workspace für Agenten.“ Sobald Claude Code, Cursor, Codex und Decagon als Partneragenten direkt in der Seitenleiste auftauchen, verliert die IDE ihre Rolle als Orchestrierungsebene. Genau um diese Position wird jetzt gekämpft.

Der Ablauf in den Release Notes vom 13. Mai macht den Anspruch deutlich: Decagon übernimmt ein Support-Ticket, reicht den Fehler an einen Coding-Agenten weiter und leitet die Korrektur zur Freigabe zurück an das Team. Heute verteilt sich dieser Ablauf auf drei Apps und einen Slack-Thread. Notion führt ihn auf einer einzigen Oberfläche zusammen.

Wer den Workspace kontrolliert, zieht die Integrationssteuer ein. Notion kassiert sie jetzt bei Agentenanbietern, nicht bei CRM-Anbietern. Darin liegt der eigentliche Wandel.

Die Gegenposition: In den meisten operativen Stacks gibt es längst eine Standardoberfläche – das CRM, das Projektmanagement-Tool oder eine eigene Admin-Anwendung. Entscheidend ist, ob Notions Ansatz (datenbanknah, agentennativ, browserzentriert) allein durch die Gewohnheiten jener Teams gewinnt, die ohnehin dort arbeiten. Für Teams außerhalb von Notion ändert sich nichts. Für Notion-Teams verschiebt sich dagegen die Build-or-Buy-Rechnung bei jedem internen Tool, das gerade als Nächstes geplant war.

Der Credit-Stichtag am 11. August

Während der Public Beta sind Workers kostenlos. Ab dem 11. August 2026 laufen sie über Notion Credits. Der Credit-Tarif ist noch nicht veröffentlicht. Genau darin liegen die asymmetrische Chance und die Falle.

Die asymmetrische Chance: Workers lassen sich jetzt kostenlos aufbauen. Wer bis zum 10. August drei Synchronisierungen und zwei Agenten-Tools ausliefert, hat die Integration zum Nulltarif umgesetzt. Wer wartet, muss später von dem Tarif wegmigrieren, den Notion veröffentlicht – unter einem Credit-Preismodell, das nie in der Roadmap einkalkuliert war.

Die konkrete Rechnung: Eine Synchronisierung im 5-Minuten-Takt kommt auf 8,640 Aufrufe pro Monat. Drei Synchronisierungen ergeben 25,920 Aufrufe pro Monat. Bei Notion bleibt der Preis nach dem 10. August eine offene Variable. Landet Notion bei weniger als $1 pro Million, ist das für die Integrationsschicht günstig genug, um alles dorthin zu verlagern, was Notion-Daten berührt. Bei $5+ pro Million behält Cloudflare den kostenbewussten Teil des Marktes, und Notion Workers bleiben ein Tool ausschließlich für Notion-Daten.

Die Falle: Deterministische Workloads, die im bestehenden Stack bereits günstig laufen, sollten dort bleiben. Ein Umzug lohnt sich nur, wenn die Nähe zu Notion-Daten einen Vorteil bringt – etwa bei Synchronisierungsjobs, die aus Notion lesen, Agenten-Tools, die nach Notion schreiben, oder Webhooks, die Daten auf Notion-Datenbanken verteilen. Alles andere bleibt an seinem Platz.

Was diese Woche live gehen sollte

Zuerst die CLI installieren: curl -fsSL https://ntn.dev | bash, authentifizieren, fertig. Kostenlos und ohne erforderlichen Plattformtarif. CLI-Überblick.

Dann einen Worker veröffentlichen, der sich selbst bezahlt: ein deterministisches Agenten-Tool, das Custom Agents 50+ Mal pro Woche aufrufen. Kundensuche per E-Mail, Aufgabe an Linear senden, Wochenbericht erstellen. Token-effizient, ohne LLM-Reasoning und in der Sandbox ausgeführt. Anleitung für Tools.

Außerdem eine Synchronisierung umsetzen, deren Entwicklung sich bisher nicht gelohnt hat: eine Postgres-Tabelle, Stripe-Zahlungen oder den Status von GitHub-PRs in eine Notion-Datenbank leiten. Workers übernehmen Zeitplan und Zugangsdaten. Wenn „X-Daten in Notion ablegen, damit das Team sie sieht“ schon länger aufgeschoben wurde, ist diese Woche der richtige Zeitpunkt – solange es kostenlos ist.

Auf die Warteliste der External Agent API setzen lassen. Wer bereits Agenten mit dem Cloudflare Agents SDK, Mastra oder LangGraph gebaut hat, kann sie über diese API als Teilnehmer in den Workspace integrieren. Nicht bis zur GA warten.

Den Neuaufbau als Custom Agents auslassen. Agenten, die bereits auf einer echten Laufzeit für dauerhafte Ausführung laufen, gehören nicht in Notion Workers. Workers eignen sich für Tools, nicht für die Orchestrierung.

Was Notion bei einem Cloudflare-Stack NICHT ersetzt

Dauerhafte Workflows. Notion Workers bieten keine über mehrere Stunden laufende, dauerhafte Ausführung mit zwischengespeicherten Schritten und sicherer Wiederholung. Wer bereits Cloudflare Workflows, Inngest oder Temporal nutzt, sollte dabei bleiben.

Vectorize und Embeddings. Notion stellt Workers keinen Vektorbaustein bereit. Memory und RAG bleiben im eigenen Stack.

Öffentliche API-Endpunkte. Notion Workers sind Tools, die innerhalb von Notion aufgerufen werden – keine HTTP-Dienste für Zugriffe aus dem öffentlichen Web.

Cron-Zeitpläne unter 5 Minuten. Für kurze Intervalle bleiben Cloudflare Cron Triggers zusammen mit this.schedule() aus dem Agents SDK überlegen.

Das Muster des ruhenden Agenten. Notions Custom Agents bewältigen einmalige Workflow-Läufe gut; bei langfristig laufenden Agenten mit eigenem Speicher pro Instanz, wie sie auf Durable Objects entstehen, sind sie schwächer. Das Modell aus meinem Beitrag zum Claude-Stack für kleine Unternehmen – sechs spezialisierte Agenten mit jeweils eigenem Memory und Zeitplan – passt heute nicht sauber in die Workers-Sandbox.

Die richtige Einordnung: Notion Workers ersetzen Zapier, die AWS-Lambda-Integrationsschicht und jene 200 Zeilen Node-Code, die sonst nötig wären, um einem Custom Agent ein deterministisches Tool zu geben. Sie ersetzen nicht das Anwendungs-Backend. Dasselbe Multi-Provider-Risiko, über das ich bei der Übernahme von Stainless geschrieben habe, gilt auch hier: Die Orchestrierung muss portabel bleiben; Notion ist die Oberfläche, nicht die Laufzeit.

Was in den nächsten 30 Tagen entscheidend wird

GA der External Agent API. Die Warteliste zur Private Beta ist derzeit das Nadelöhr. Sobald sie sich öffnet, veröffentlicht jeder Anbieter mit Mastra oder LangGraph noch in derselben Woche einen Notion-Adapter.

Bekanntgabe des Credit-Tarifs vor dem 11. August. Die beiden Szenarien sind real und schließen einander aus: Weniger als $1 pro Million macht Workers zur naheliegenden Integrationsschicht; $5+ pro Million begrenzt die Verbreitung auf Teams, die bereits fest an Notion gebunden sind.

Ausbau der Partneragenten. Wer folgt auf Claude Code, Cursor, Codex und Decagon? Im Blick bleiben sollten Replit Agent, Devin, Lovable sowie mögliche Adapter für Managed Agents aus dem Anthropic-Umfeld. Mit jedem neuen Partner gibt es für operative Teams einen Grund weniger, die Notion-Oberfläche zu verlassen.

GA des Notion Agent SDK. Hier kehrt sich das Modell um – Notion Agents laufen innerhalb anderer Tools. Das ist Notions Burggraben für die eigenen Daten, nicht für den Workspace. Gehen beide in Q3 live, konkurriert Notion nicht mehr um die Oberfläche, sondern um den Agenten selbst.