Notion hat aufgehört, ein Werkzeug zu sein, und zielt darauf ab, Infrastruktur zu werden
Es gibt einen Moment im Leben jeder Produktivitätsplattform, an dem es nicht mehr ausreicht, eine einzige Sache gut zu machen. Notion hat diesen Punkt erreicht. Das Unternehmen – das jahrelang als der Ort bekannt war, an dem Teams Notizen, Wikis und Datenbanken aufbewahren – hat gerade eine tiefgreifende Umgestaltung seiner Architektur angekündigt: eine Reihe von Fähigkeiten, die zusammengenommen den Arbeitsbereich in eine Umgebung verwandeln, in der Agenten der künstlichen Intelligenz operieren, Anweisungen erhalten, Code ausführen und externe Daten in kontinuierlichem Echtzeitmodus synchronisieren können.
Die Ankündigung erfolgte am 13. Mai 2026 bei einer live übertragenen Veranstaltung. Ivan Zhao, Mitgründer und Geschäftsführer des Unternehmens, fasste es in einem Satz zusammen, der Beachtung verdient: „Any data, any tool, any agent". Das ist kein Marketingslogan. Es ist eine Positionierungsaussage. Notion kommuniziert, dass seine Decke nicht mehr die einer Produktivitätsanwendung ist, sondern die einer Koordinationsschicht zwischen Systemen, Daten und Agenten.
Um zu verstehen, warum dies über die Schlagzeile hinaus wichtig ist, muss man nachverfolgen, welches konkrete Problem sie zu lösen versuchten.
Die Million Agenten, die nicht zur Arbeit gehen konnten
Im Februar 2026 hatte Notion seine Benutzerdefinierten Agenten eingeführt: konfigurierbare Assistenten, die häufig gestellte Fragen beantworten, Statusaktualisierungen zusammenstellen und sich wiederholende Arbeitsabläufe automatisieren konnten. Die Akzeptanz war bemerkenswert. In wenigen Monaten hatten die Kunden mehr als eine Million Agenten erstellt. Diese Zahl ist relevant, weil sie darauf hindeutet, dass der Bedarf an Automatisierung innerhalb des Arbeitsbereichs nicht latent, sondern aktiv war. Die Nutzer wollten bereits Arbeit an diese Systeme delegieren.
Aber die Agenten hatten eine strukturelle Einschränkung, die ihren praktischen Nutzen minderte: Sie konnten keine Verbindung zu externen Datenquellen herstellen und keine benutzerdefinierte Logik ausführen. Ein Notion-Agent konnte den Status eines Tickets in Zendesk nicht lesen, sich nicht mit Salesforce-Daten aktualisieren und keine Aktion auslösen, wenn sich etwas in einem anderen System änderte. Um dies zu lösen, griffen Teams auf Automatisierungsplattformen von Drittanbietern zurück oder schrieben eigene Skripte, die auf ihrer eigenen Infrastruktur liefen. Mit anderen Worten: Notion war der Ankunftspunkt von Informationen, nicht der Steuerungspunkt des Prozesses.
Die neue Entwicklerplattform greift dieses Problem auf drei Ebenen an.
Die erste sind die Workers: eine Cloud-Umgebung, in der Teams eigenen Code in einer isolierten Umgebung bereitstellen können, ohne externe Infrastruktur zu benötigen. Workers ermöglichen die Synchronisierung von Daten aus jeder Datenbank mit API (Salesforce, Zendesk, Postgres und andere), den Aufbau von Tools mit benutzerdefinierter Logik und die Aktivierung von Workflows über Webhooks. Das Bedeutsame ist nicht, dass Notion das Ausführen von Code ermöglicht – andere taten das bereits –, sondern dass es dies innerhalb desselben Arbeitsbereichs tut, mit denselben Berechtigungskontrollen und demselben Guthabenmodell, das die Agenten bereits verwenden. Die Reibung bei der Integration externer Systeme sinkt erheblich.
Die zweite Ebene ist die Synchronisierung externer Datenbanken. Bisher war das Importieren von Daten aus einem CRM-System oder einer Support-Plattform in Notion ein manueller Prozess oder hing von Drittanbieter-Konnektoren ab. Mit der neuen Architektur kann diese Synchronisierung kontinuierlich und bidirektional erfolgen. Zhao beschrieb dies als die Möglichkeit, „deine Notion-Datenbank als eine Leinwand zu nutzen, um sowohl deine Workflows als auch deine Agenten zu stärken". Was er beschreibt, ist eine Veränderung der Rolle der Daten innerhalb von Notion: vom statischen Archiv zur aktiven Quelle für automatisierte Entscheidungen.
Die dritte Ebene ist die API für externe Agenten. Teams, die bereits eigene Agenten verwenden – intern entwickelt oder von Drittanbietern –, können diese nun mit Notion verbinden. Zum Launch sind vier externe Agenten kompatibel: Claude Code, Cursor, Codex und Decagon. Es ist geplant, diese Liste zu erweitern. Dies ist relevant, weil es die übliche Logik umkehrt: Anstatt dass Notion jede Fähigkeit selbst aufbaut, öffnet es die Tür, damit spezialisierte Agenten innerhalb seines Arbeitsbereichs operieren können.
Die Reibung, die ihren Tribut forderte
Der CEO von Notion räumte etwas ein, das nur wenige Unternehmen laut über sich selbst sagen: „Historisch gesehen war Notion nicht die entwicklerfreundlichste Plattform". Diese Einräumung ist nicht unbedeutend. Jahrelang war eine der am häufigsten dokumentierten Reibungspunkte bei technischen Notion-Nutzern genau das: Die Plattform war leistungsstark als Benutzeroberfläche, aber widerständig als programmierbares System. Ingenieurteams, die komplexe Workflows auf Notion hätten aufbauen können, bevorzugten häufig offenere Werkzeuge, auch wenn diese visuell weniger ausgefeilt waren.
Diese Lücke hatte echte Kosten. Kunden, die fortgeschrittene Automatisierung benötigten, zahlten am Ende für zusätzliche Infrastrukturschichten – Zapier, Make, n8n, Skripte in AWS Lambda –, um Notion mit dem Rest ihres Tech-Stacks zu verbinden. Das fragmentierte den Arbeitsbereich, führte zusätzliche Fehlerpunkte ein und ließ Notion vor allem aus dem automatisierten Entscheidungszyklus heraus. Die Daten lebten in Notion, aber die Aktion fand woanders statt.
Die neue Plattform versucht, diese Lücke zu schließen. Da die Workers innerhalb von Notion laufen, verlagert sich die Ausführungsumgebung nach innen. Der Code lebt nicht mehr in einer abgekoppelten Lambda-Funktion: Er lebt in demselben Kontext, in dem sich die Daten, die Agenten und die Nutzer befinden. Diese Kolokalisation hat konkrete Konsequenzen: Sie reduziert die Integrationslatenz, vereinfacht das Berechtigungsmodell und konzentriert aus der Kundenperspektive das, was früher mehrere Verträge mit verschiedenen Anbietern waren, auf eine einzige Rechnung.
Dass die Workers bis August 2026 kostenlos sind, ist eine typische taktische Entscheidung zur Plattformadoption: die Experimentierkosten zu senken, um die Generierung realer Anwendungsfälle vor der Monetarisierung zu beschleunigen. Wenn Teams während dieses Zeitraums relevante Workflows auf Workers aufbauen, werden die Kosten für deren spätere Migration – in eine andere Umgebung – hoch genug sein, um das Konto bei Notion zu verankern.
Wann eine Anwendung zur Koordinationsschicht wird
Die Unterscheidung zwischen einer Anwendung und einer Infrastrukturplattform ist nicht semantisch. Eine Anwendung löst ein Problem für den Nutzer, der sie öffnet. Eine Koordinationsplattform löst Probleme, selbst wenn niemand hinschaut: Sie synchronisiert, führt aus, verbindet und aktualisiert autonom. Der Wert liegt nicht mehr in der Benutzeroberfläche, er liegt in den Prozessen, die im Hintergrund ablaufen.
Notion versucht diesen Sprung zu machen. Die konkrete Frage, die gestellt werden muss, ist, wie viel von der Arbeit, die heute Plattformen wie Zapier, Make oder sogar ausgeklügelteren Integrationsdiensten koordinieren, die neue Notion-Architektur absorbieren kann und zu welchem Preis.
Es gibt Anzeichen dafür, dass die Wette Fundament hat. Das Agentenmodell zeigte bereits Zugkraft, bevor es diese Fähigkeiten gab. Die in wenigen Monaten erstellte Million von Agenten ist keine Eitelkeitskennzahl: Sie zeigt an, dass Teams bereit waren, Automatisierungen innerhalb von Notion zu konfigurieren, auch wenn diese begrenzt waren. Das deutet darauf hin, dass die Bereitschaft, von Notion aus zu operieren, bereits besteht. Was fehlte, war die Architektur, um dies vollständig zu tun.
Aber die Adoption von Koordinationsplattformen hat eine besondere Dynamik: Ihr Wert aktiviert sich nicht im Moment des Launches, sondern wenn das Volumen der aktiven Integrationen einen kritischen Schwellenwert überschreitet. Eine mit Salesforce synchronisierte Datenbank ist nützlich. Eine mit Salesforce, Zendesk, Postgres und vier weiteren internen Quellen synchronisierte Datenbank, mit Agenten, die diese Daten lesen und Entscheidungen treffen, und Workers, die benutzerdefinierte Logik auf den Ergebnissen ausführen, ist Infrastruktur. Der Unterschied zwischen diesen beiden Zuständen ist nicht technologischer Natur: Er ist kumulierter Adoption.
Die Erweiterung des Katalogs externer Agenten wird wahrscheinlich der aufschlussreichste Indikator für den Erfolg dieser Strategie in den kommenden Monaten sein. Vier Partner beim Launch ist ein bescheidener Anfang. Wenn diese Zahl in sechs Monaten nicht signifikant gewachsen ist, wird die Erzählung des „Agenten-Hubs" eher als Absichtserklärung denn als operative Realität bestehen bleiben.
Was die Nutzer buchten und was sie jetzt buchen können
Es gibt einen klaren Unterschied zwischen dem, was Notion-Nutzer bisher buchten, und dem, was die neue Plattform ihnen vorschlägt. Früher buchten sie einen gemeinsamen Raum, um Dokumente, Datenbanken und Aufgaben des Teams zu zentralisieren. Es war wertvoll durch seine Fähigkeit, die Informationsfragmentierung zu reduzieren: Anstatt in zehn Tools zu suchen, war alles an einem einzigen Ort.
Was die neue Plattform vorschlägt, ist anders. Die Nutzer zentralisieren nicht nur Informationen: Sie können dafür buchen, dass diese Informationen sich selbst aktuell halten, dass Agenten ohne menschliches Eingreifen darauf reagieren und dass der Geschäftscode, der diesen Aktionen Logik verleiht, in derselben Umgebung läuft, in der die Daten leben. Der Schritt von der Zentralisierung von Informationen zur Koordination von Prozessen ist in Bezug auf den wahrgenommenen Wert ein Kategoriensprung.
Wenn Notion es schafft, diesen Sprung fließend genug zu gestalten, damit nicht-technische Teams ihn adoptieren können – und die Tatsache, dass Zhao explizit erwähnte, dass „du den Code nicht selbst schreiben musst, dein Programmieragent kann das für dich tun", deutet darauf hin, dass das die Wette ist – wird es etwas erreicht haben, was nur wenige Produktivitätsplattformen schaffen: dass der Nutzer das Werkzeug nicht nur mehr nutzt, sondern dass es für ihn teurer wird, es nicht mehr zu nutzen. Das ist keine Kundenbindung durch schönes Design. Es ist Kundenbindung durch funktionale Abhängigkeit. Und im Markt für Unternehmenssoftware ist das die dauerhafteste Form der Kundenbindung, die es gibt.
