Notion Dev Day 2026 ist der Moment, in dem Notion aufgehört hat, nur ein Produktivitäts-Tool zu sein, und anfing, eine echte Entwicklerplattform zu werden — mit Workers, einem Agent SDK und einer Agent API, die zusammen deinen Workspace in ein programmierbares System of Record verwandeln.
Falls du die Ankündigungen verfolgt hast und dachtest: “Klingt technisch” — keine Sorge. Du musst keine einzige Zeile Code schreiben, um von dem zu profitieren, was gerade passiert ist. Und wenn du Code schreibst (oder KI für dich schreiben lässt), ist die Obergrenze gerade erheblich gestiegen.
Hier ist alles, was angekündigt wurde, was das für deinen Workspace bedeutet und wie du heute damit anfangen kannst. Für spezifische Notion AI-Terminologie schau ins Notion AI Dictionary.
Was sind Notion Workers — und warum sollte dich das interessieren?
Notion Workers sind kleine Code-Stücke, die direkt auf Notions Servern laufen und deinen Workspace weit über die eingebauten Funktionen hinaus erweitern.
Stell dir einen Worker wie ein spezialisiertes Werkzeug vor, das du deinem Notion-Setup gibst. Kennst du Notions eingebaute Automationen — das kleine ⚡-Icon in deinen Datenbanken? Workers sind im Prinzip genau das, nur auf Steroiden. Sie können alles, was eine normale Automation nicht kann: über Datenbanken hinweg suchen, externe APIs ansteuern, komplexe Logik ausführen und vieles mehr.
Ja, Workers erfordern Code. Aber im Jahr 2026 ist das kaum noch eine Hürde. Tools wie Claude Code und Codex können aus einer einfachen Beschreibung einen funktionierenden Worker generieren. Wir veröffentlichen diese Woche noch ein vollständiges Tutorial — auch wenn du noch nie ein Terminal geöffnet hast.
Wie erscheinen Workers in deinem Workspace?
Workers können auf drei verschiedene Arten getriggert werden, die jeweils für unterschiedliche Use Cases geeignet sind.
1. Als Tool für Custom Agents
Du kannst einen Worker an jeden Notion Custom Agent als Tool anhängen — wie deinem Agent einen neuen Trick beibringen. Von Haus aus können Custom Agents nicht mit jedem externen Service kommunizieren. Zum Beispiel gibt es keinen eingebauten Connector für ConvertKit (Kit), unsere Newsletter-Plattform.
Also haben wir einen kleinen Worker gebaut, der auf Kits API zugreift, und ihn unserem Agent als Tool gegeben. Jetzt kann der Agent automatisch Newsletter-Daten abrufen. Das ist eine Fähigkeit, die Notion AI nativ nicht hat — und ein Worker schließt diese Lücke in Minuten.
2. Via Webhook-Trigger
Das ist neu seit Dev Day. Workers können jetzt durch Webhooks getriggert werden, also ohne jegliche KI-Beteiligung. Etwas passiert in deinem Workspace → der Worker feuert → der Job ist erledigt. Reine Automation, kein Token-Verbrauch.
Das Mächtige daran: Notion hat Webhooks in seine Datenbank-Automationen integriert. Du kannst eine komplette Kette innerhalb von Notion aufbauen — Datenbank-Automation sendet einen Webhook, Webhook triggert einen Worker, Worker erledigt die Hauptarbeit. Ein vollständiger Automationskreislauf, ohne die Plattform zu verlassen.
3. Nach einem Sync-Zeitplan
Sync-Workers laufen nach einem wiederkehrenden Zeitplan — alle 15 Minuten, stündlich, täglich — und ziehen externe Daten in Notion. Den Sync besprechen wir unten im Detail, weil er einige besondere Eigenschaften hat. Falls du mit externen APIs arbeitest, findest du im Notion API-Guide Infos zu Preisen, Token-Nutzung und Best Practices.
Sechs konkrete Beispiele für Notion Workers
Machen wir das greifbar. Hier sind sechs reale Use Cases, in denen Workers glänzen.
🏢 Company Enricher
Sobald du ein neues Unternehmen in dein CRM einträgst und die Domain angibst, ruft ein Worker das Unternehmenslogo ab und setzt es als Page-Icon. Optional kann er auch die Website scrapen (via Firecrawl) und Properties wie Branche, Größe und aktuelle News automatisch befüllen.
Kleine visuelle Verbesserung, großer Unterschied in der Nutzbarkeit — und skaliert auf Hunderte Einträge ohne einen Handgriff.
✅ Task Generator
Einer der häufigsten Automationsflows, die wir früher mit Make oder N8N gebaut haben. Das Szenario: Bestimmte Projekttypen brauchen immer denselben Satz an Tasks. Eine Marketing-Kampagne hat immer diese sieben Schritte, ein Onboarding immer diese zwölf.
Der Goldstandard: eine separate Prozess-Datenbank, in der du definierst, welche Tasks zu welchem Projekttyp gehören. Ein Worker beobachtet neue Projekte, schlägt im passenden Prozess nach und erstellt alle Tasks automatisch. Früher brauchte das ein externes Tool. Jetzt läuft es nativ in Notion.
🔍 Duplicate Checker
Duplikate in Notion zu finden ist keine schöne Erfahrung — es gibt keine eingebaute Funktion dafür. Du könntest KI nutzen, aber das verbrennt schnell Tokens. In Code ist Duplikaterkennung ein gelöstes Problem. Ein Worker kann jeden neuen Eintrag gegen bestehende Datensätze prüfen und Duplikate sofort markieren oder zusammenführen.
⏰ Overdue Escalator
Ein geplanter Worker, der regelmäßig Task-Deadlines prüft, überfällige Einträge identifiziert, sie den verantwortlichen Team-Leads zuordnet und Benachrichtigungen sendet. Stell es dir als proaktiven Projekt-Gesundheitsmonitor im Hintergrund vor.
💳 External Status Sync
Workers können externe APIs anbinden. Verfolge den Zahlungsstatus von Rechnungen aus Stripe, ziehe Bestellupdates aus Shopify oder sync Ticket-Status aus Zendesk — alles automatisch in deinen Notion-Datenbanken gespiegelt.
📝 Smarter Meeting Notes Sync
Wer ein externes Meeting-Tool nutzt, kennt den Schmerz: Du bereitest eine Agenda in Notion vor, aber die Notizen danach erstellen einen neuen Eintrag statt sich mit dem bestehenden zu verbinden.
Ein Worker kombiniert mit einem Agent löst das elegant. Der Code übernimmt die offensichtlichen Matches (identische Titel, gleiche Startzeiten). Bei unklaren Fällen übernimmt die KI die Kontexteinschätzung. Und weil 80% der Arbeit im Code passiert — der fast kostenlos läuft — sinken deine Agent-Kosten deutlich gegenüber einer rein KI-basierten Lösung.
Pro-Tipp: Dieses letzte Beispiel illustriert ein zentrales Design-Prinzip für Workers. Nutze Code für die deterministischen, repetitiven Teile und reserviere KI für die Urteilsentscheidungen. Dieser Ansatz kann deinen Token-Verbrauch bei gemischten Workflows um 80% oder mehr reduzieren. Strategien zur Kostenoptimierung findest du hier.
Was kosten Workers?
Workers nutzen dasselbe Credit-System wie Notion Agents — aber zu einem Bruchteil der Kosten.
KI-Reasoning ist teuer: Modelle brauchen enorme Rechenleistung, um Probleme durchzudenken. Code-Ausführung ist dagegen günstig. Workers sind also ein kostenpflichtiges Add-on, aber die Preise spiegeln diesen Unterschied wider.
Notion hat einige Beispielrechnungen geteilt:
- Salesforce-Tickets alle 15 Minuten abfragen → 86 Cent pro Monat
- Jira einmal täglich abrufen → 1 Cent pro Monat
- Intensive Nutzung (9.800 Runs/Monat für Help-Desk-Tickets) → rund 13 US-Dollar pro Monat
Außerdem sind Workers bis zum 11. August 2026 komplett kostenlos. Das gibt dir knapp drei Monate zum Bauen, Testen und Optimieren.
Um Workers zu aktivieren, musst du Workspace Owner auf dem Business-Plan oder höher sein. Geh zu Einstellungen → Funktionen → Workers und drücke den Aktivierungsbutton. Für professionelle Unterstützung beim Aufbau deiner Worker-Infrastruktur: Notion Beratung.
Wie funktioniert Notion Sync?
Hinweis: Für tiefere Einblicke in die Orchestrierung mehrerer Agents in Notion, schau dir Multi-Agent-Orchestrierung in Notion an.
Sync ist ein spezieller Worker-Typ für einseitige Datenimporte in Notion — mit eingebautem Schutz gegen versehentliche Überschreibungen.
Wenn du ein externes System als Single Source of Truth hast — Salesforce für deine Deals, ein HRIS für Mitarbeiterdaten, ein Ticketing-System für Support-Anfragen — und diese Daten in Notion sehen willst, ohne das Risiko einzugehen, dass jemand die Sync-Werte versehentlich ändert: Sync ist die Antwort.
Was unterscheidet Sync von einem regulären Worker?
Sync-Workers erstellen und verwalten ihre eigene dedizierte Datenbank. Das ist eine bewusste Design-Entscheidung.
Wenn du einen Sync einrichtest, deklarierst du, welche Properties aus der externen Quelle gezogen werden — Name, Stage, Wert, was auch immer du brauchst. Diese gesyncten Properties sind gesperrt. Du kannst sie sehen und kopieren, aber nicht in der Notion UI bearbeiten. Die Daten fließen nur in eine Richtung: von der externen Quelle in Notion.
Hier wird es clever: Du kannst deine eigenen Notion-nativen Properties oben drauflegen. Weise einen internen Owner zu, verknüpfe den Datensatz mit anderen Notion-Datenbanken, füge Tags oder Notizen hinzu — alles vollständig unter deiner Kontrolle. Die gesyncten Daten bleiben sauber und geschützt; deine interne Anreicherungsebene liegt daneben.
Das löst ein Problem, das wir ständig in der Kundenarbeit sehen: Jemand ändert einen gesyncten Property-Wert in Notion, der nächste Sync überschreibt ihn, und Verwirrung entsteht. Mit Syncs Architektur passiert das schlicht nicht.
Wann verwendest du Sync vs. einen regulären Worker?
Nutze Sync, wenn:
- Das externe System die Single Source of Truth ist
- Du nur Daten in Notion lesen musst (einseitig)
- Du gesperrte Properties willst, die nicht versehentlich geändert werden können
- Du mit einer neuen, dedizierten Datenbank für die gesyncten Daten einverstanden bist
Nutze einen regulären Worker, wenn:
- Du bidirektionalen Sync brauchst (lesen und zurückschreiben)
- Du Daten in eine bestehende Notion-Datenbank pushen möchtest
- Du komplexere Logik brauchst als einfaches Daten-Mirroring
Pro-Tipp: Bei Sync-Datenbanken kannst du Properties umbenennen, ohne den Sync zu unterbrechen — eine interne ID hält die Verbindung aufrecht. Aber du kannst den Property-Typ nicht ändern. Wenn der Sync ein Text-Feld deklariert hat, bleibt es ein Text-Feld.
Was ist das Notion Agent SDK?
Das Agent SDK ermöglicht es externen Tools, mit deinen Notion Agents zu kommunizieren — du kannst also endlich mit Notion AI interagieren, ohne in Notion zu sein.
Das ist eine erhebliche Veränderung. Bis jetzt hieß Notion AI nutzen: Notion öffnen. Die einzige Ausnahme war die Slack-Integration für Custom Agents. Das SDK öffnet diese Tür weit auf — und es funktioniert für beide: Custom Agents und deinen Personal Agent.
Das SDK ist aktuell in der Alpha-Phase mit Zugang via Warteliste. Du kannst dich im offiziellen GitHub-Repository anmelden.
Warum ist das relevant für deinen Workflow?
Stell dir vor, du arbeitest tief in Claude Code an einer Marketing-Kampagne. Du brauchst die neuesten Details aus drei Kunden-Meetings, die in Notion liegen. Früher wärst du rübergewechselt: Notion öffnen, die Meetings suchen, relevante Teile kopieren, zurückpaste.
Mit dem SDK kann Claude Code deinen Notion Agent direkt pingen. Der Agent durchsucht deinen Workspace, zieht die Meeting-Details und schickt sie an Claude zurück — alles ohne, dass du deine Coding-Umgebung verlässt.
Oder umgekehrt: Du hast gerade einen Development-Sprint in Codex abgeschlossen und willst die Ergebnisse in dein Projektmanagement-System in Notion schreiben. Codex könnte das über die API tun. Aber ein Notion Agent, der mit der Struktur, den Namenskonventionen und den verlinkten Datenbanken deines Workspaces vertraut ist, macht das zuverlässiger. Der Agent kennt dein System — das ist seine Zone.
Das “Zone of Genius”-Prinzip
Das ist die Kernidee hinter dem SDK. Jedes Tool hat seinen Sweet Spot:
- Notion AI glänzt bei allem, wo Inputs und Outputs in Notion liegen — suchen, erstellen, verlinken, Workspace-Inhalte aktualisieren
- Claude Code / Codex glänzt beim Schreiben von Code, Arbeiten mit Dateien, Generieren von Assets
- Spezialisierte Agents (Research, Datenanalyse etc.) haben jeweils ihre eigenen Stärken
Das SDK lässt dich jeden Task zu dem Tool routen, das am besten geeignet ist — ohne dass du manuell Informationen zwischen Tools shutteln musst.
In unserer eigenen Arbeit haben wir dieses Muster bereits mit Tools wie OpenClaw erlebt. Das SDK macht es nativ — kein Middleware-Layer nötig.
Zurück zum Multiplayer-Modus
Es gibt einen größeren Trend, den es lohnt zu benennen. Aktuell läuft viel KI-Arbeit im Single-Player-Modus. Alle strömen zu Claude Code oder Codex, bauen Dinge in ihrer eigenen lokalen Umgebung, und der Output bleibt isoliert.
Das ist das Gegenteil von Zusammenarbeit. Wenn du Arbeitsergebnisse erstellst, die in einem zentralen System leben sollten — und Notion ist dieses System — brauchst du eine Brücke zurück.
Das SDK ist diese Brücke. Es macht es einfach, Informationen an den richtigen Ort in deinem Workspace zurückfließen zu lassen, auch wenn die Arbeit woanders entstanden ist.
Was ist die Notion Agent API?
Die Agent API ist das Gegenstück zum SDK. Während das SDK externen Tools erlaubt, mit Notion Agents zu kommunizieren, erlaubt die API externen Agents, in Notion als First-Class Citizens zu leben.
Deine Claude Agents, Codex Agents und alle anderen externen KI-Agents tauchen direkt in deinem Notion Agent-Menü auf. Du kannst mit ihnen interagieren, ihnen Tasks zuweisen und ihre Workflows verwalten — alles aus Notion heraus.
Die Agent API ist aktuell in der Beta-Phase mit Zugang via Warteliste.
Wie verändert das den Alltag?
Stell dir ein gemeinsames Task-Board in Notion vor, auf dem dein gesamtes Team — Menschen und KI-Agents — zusammenarbeitet.
Ein neues Engineering-Ticket kommt rein. Du weist es deinem Claude Code Agent zu, der anfängt, die Implementierung zu bearbeiten. Ein Content-Brief trifft ein — du routest ihn an einen spezialisierten Writing Agent. Eine Datenanalyse-Anfrage? Die geht an deinen Analytics Agent.
Jeder Agent wählt das richtige Tool für den Job. Notion AI übernimmt alles, wo Inputs und Outputs in deinem Workspace liegen. Claude übernimmt den Code. Spezialisierte Agents übernehmen ihre Domänen. Und du orchestrierst alles von einer zentralen Oberfläche.
Wenn Agents ihre Arbeit abschließen, aktualisieren sie den Task-Status, schreiben ihren Output zurück auf das gemeinsame Board und bewegen das Item durch die Pipeline. Kein Copy-Pasten zwischen Tools. Kein verlorener Kontext.
Die Orchestrierungsebene, für die Notion gebaut ist
Das ist wohl die strategisch bedeutsamste Ankündigung des Dev Days. Notion hat immer als Hub-and-Spoke-Modell funktioniert — dein zentrales System, verbunden mit spezialisierten Tools drumherum. Mit zunehmendem Wachstum war Notion nie darauf ausgelegt, das All-in-One-Tool für alles zu sein.
Die Agent API erweitert dieses Modell auf KI. Dein Workspace wird zur Orchestrierungsebene, auf der alle Agents — intern und extern — zusammenkommen.
Wer arbeitet woran? Was ist der nächste Task in der Reihe? Wie ist unsere allgemeine Dokumentation? Das sind dieselben menschlichen Kollaborationsprobleme, die Notion bereits gut löst. Jetzt profitieren alle deine KI-Agents von derselben Koordinationsinfrastruktur.
Wie richtest du das alles ein?
Alles läuft über die Notion CLI (Command Line Interface), zugänglich über den ntn-Befehl in deinem Terminal. Wenn du deine Agents orchestrieren möchtest, helfen dir die Grundlagen der Custom Agents dabei, die Architektur zu verstehen.
Die CLI ermöglicht:
- Login und Autorisierung deines Notion Workspace
- Deployment von Workers
- Prüfen von Worker-Status und Logs
- Konfiguration von Sync-Zeitplänen
- Management des gesamten Worker-Lifecycles
Falls du noch nie mit einem Terminal gearbeitet hast: keine Sorge. Wir veröffentlichen diese Woche ein vollständiges Schritt-für-Schritt-Tutorial, das alles erklärt — auch für Nicht-Techniker. Mit Claude Code oder Codex, der den eigentlichen Code generiert, dreht sich die CLI hauptsächlich ums Deployment und Management.
Das offizielle Workers-Template-Repository findest du unter github.com/makenotion/workers-template. Für das Agent SDK: github.com/makenotion/notion-agents-sdk-js.
Wichtig: Du kannst einen Worker nicht ohne die CLI deployen. Es gibt keinen rein UI-basierten Weg. Aber die Einrichtung ist unkompliziert, sobald du ein paar Kernkonzepte verstehst.
Was bedeutet das für Notion als Plattform?
Notion wird zu einem echten System of Record — einem zentralen Hub, der sich mit jedem KI-Setup verbinden kann, das du darüber aufbaust. Für einen tieferen Einblick in die interne Orchestrierung: Wie Notion KI-Agents intern einsetzt.
| Feature | Was es macht | Verfügbar | Am besten für |
|---|---|---|---|
| Workers (Tool) | Custom Code als Agent-Tool | ✅ Heute | Agent-Fähigkeiten erweitern |
| Workers (Webhook) | Code durch Events triggern | ✅ Heute | Automationen ohne KI |
| Workers (Sync) | Geplanter einseitiger Datenabruf | ✅ Heute | Externe Daten spiegeln |
| Agent SDK | Externe Tools sprechen mit Notion AI | 🔜 Alpha (Warteliste) | Notion AI aus Claude, Codex etc. nutzen |
| Agent API | Externe Agents in Notion | 🔜 Beta (Warteliste) | Alle Agents von einem Hub orchestrieren |
| CLI (ntn) | Alles deployen und verwalten | ✅ Heute | Worker-Deployment und -Lifecycle |
Diese Tabelle gibt dir den Überblick. Aber das größere Bild ist entscheidend.
Wir alle wissen mittlerweile: Kontext ist die wichtigste Zutat für effektive KI. Das Wissen deines Unternehmens, seine Prozesse, Beziehungen und Geschichte — das macht KI nützlich, nicht das Modell selbst.
Notion positioniert sich als dein Context in a Box. Ein zentrales Repository, auf das jeder Agent — intern oder extern — zugreifen kann. Ob Notions eigene Custom Agents, Claude, Codex oder ein spezialisierter Drittanbieter-Agent — sie alle können auf denselben Kontext zugreifen und im selben Raum zusammenarbeiten.
Der Übergang von No-Code zu Code
Es gibt einen Meta-Trend, den es lohnt anzusprechen. Workers und No-Code-Tools (Make, N8N, Zapier) lösen im Wesentlichen dasselbe Problem: Notion über seine eingebauten Fähigkeiten hinaus erweitern.
Im Venn-Diagramm ist die Überschneidung fast 100%. Beide ermöglichen Automationen, externe Service-Verbindungen und Custom Logic.
Aber Workers haben strukturelle Vorteile, die sich mit der Zeit verstärken:
- Kein zusätzliches Tool zu pflegen, zu bezahlen oder zu genehmigen — Workers laufen innerhalb von Notion
- Code wird jeden Monat einfacher zu schreiben — KI-gestützte Entwicklung bedeutet: beschreib auf Deutsch, was du willst
- Direkte Integration mit Custom Agents — Workers können Tools sein, die Agents nutzen, was mit No-Code viel schwerer umzusetzen ist
- Kosteneffizienz — keine Middleware-Abonnementgebühren
Intern haben wir aufgehört, No-Code-Automationen für unsere eigenen Workflows zu bauen. Für bestimmte Kundensituationen setzen wir sie noch ein, wo Workers Einschränkungen haben (Laufzeitbegrenzungen, begrenzte Übergaben zwischen Workers), aber die Richtung ist klar.
Werden wir in sechs Monaten noch mit Make oder N8N bauen? Ehrlich gesagt: für die meisten Use Cases wahrscheinlich nicht. Wer die Umstellung plant: Notion Beratung kann dich beim Übergang unterstützen.
Pro-Tipp: Reiß nicht morgen alle bestehenden No-Code-Automationen raus. Aber für jede neue Automation überleg, ob ein Worker es übernehmen könnte. Fang mit etwas Einfachem an — einem Company Enricher oder einem Webhook-getriggerten Status-Updater — und bau von dort aus Vertrauen auf. Abonniere Notion for Teams für wöchentliche Frameworks zum Workspace-Aufbau.
Notion übergibt dir die Schlüssel
Wer die Entwicklung des Notion-Ökosystems verfolgt, erkennt ein Muster. Die frühen Tage drehten sich um kreative Workarounds — Features zusammenkleben, um Dinge zu tun, für die das Tool nicht gebaut war. Mit der Zeit wurden die Workarounds überflüssig, weil Notion native Features geliefert hat.
Jetzt steigt die Decke wieder. Die Möglichkeit, Code innerhalb von Notion auszuführen, Notion Agents von überall anzusprechen und externe Agents in deinen Workspace zu bringen — das erschließt Möglichkeiten, die wir uns noch nicht mal vorstellen können. Abonniere unseren Newsletter für Updates, während sich dieses Ökosystem weiterentwickelt.
Notion übergibt dir die Schlüssel zum Maschinenraum. Was du damit baust, liegt bei dir.
Häufig gestellte Fragen
Muss ich coden können, um Workers zu nutzen?
Nicht wirklich. Workers sind zwar in TypeScript geschrieben, aber KI-Coding-Tools wie Claude Code und Codex können aus einer einfachen Beschreibung einen vollständig funktionierenden Worker generieren. Du musst die Notion CLI (ntn) zum Deployen nutzen, aber der Prozess ist unkompliziert. Wir veröffentlichen diese Woche ein vollständiges Einsteiger-Tutorial, das jeden Schritt erklärt.
Was kosten Workers nach dem kostenlosen Zeitraum?
Workers nutzen dasselbe Credit-System wie Notion Agents, aber zu einem Bruchteil des Preises. Code-Ausführung ist um Größenordnungen günstiger als KI-Reasoning. Notions Beispielrechnungen zeigen Kosten zwischen 1 Cent pro Monat (täglicher Jira-Abruf) und rund 13 US-Dollar für intensive Nutzung (9.800 Runs). Der kostenlose Zeitraum läuft bis zum 11. August 2026 — genug Zeit zum Bauen und Optimieren.
Was ist der Unterschied zwischen Agent SDK und Agent API?
Das SDK ermöglicht es externen Tools (Claude Code, Codex, OpenClaw), deine Notion Agents von außerhalb Notions anzusprechen. Die API dreht das um — sie bringt externe Agents als First-Class Citizens in Notion. Einfach gesagt: SDK = ausgehend (Notion Agents antworten auf externe Anfragen), API = eingehend (externe Agents erscheinen in deinem Notion Workspace).
Kann ich Workers mit meinen bestehenden Datenbanken verwenden?
Ja, für reguläre Workers und Webhook-getriggerte Workers — sie können jede Datenbank lesen und beschreiben, auf die du ihnen Zugriff gibst. Sync-Workers sind die Ausnahme: sie erstellen und verwalten ihre eigene dedizierte Datenbank mit gesperrten Properties. Wenn du externe Daten in eine bestehende Datenbank pushen willst, nutze stattdessen einen regulären Worker.
Wann sind Agent SDK und Agent API allgemein verfügbar?
Beide sind aktuell auf Wartelisten — das SDK in der Alpha, die API in der Beta. Notion rollt den Zugang schrittweise aus. Du kannst dich über die Links in der offiziellen Dokumentation und im Agent SDK GitHub-Repository anmelden. Workers, Webhooks und Sync sind heute für Business-Plan-Workspaces und höher verfügbar.
