Notion Workers: Der komplette Einsteiger-Guide

Notion Workers sind der größte Fortschritt, den die Plattform seit Jahren gemacht hat – und kaum jemand kann sie schon nutzen. Es sind kleine TypeScript-Programme, die Du auf Englisch beschreibst, mit einem einzigen Befehl deployest und die Notion für Dich ausführt – keine Server, kein DevOps, kein Stress. Das Versprechen ist enorm: externe Daten in Notion ziehen, Notion-Daten in andere Tools pushen, jede beliebige Business-Logik umsetzen und deinen Custom AI-Agenten völlig neue Fähigkeiten geben. Der Haken laut offizieller Dokumentation: Du musst Code schreiben. Die Realität im Jahr 2026: Das musst Du nicht – Du brauchst nur einen KI-Coding-Assistenten und die Fähigkeit, klar zu denken, was Du willst. Dieser Leitfaden ist Dein vollständiges Walkthrough: Am Ende hast Du ein klares mentales Modell für die drei Worker-Archetypen, ein sauberes Setup auf deinem Rechner und drei fertige Worker, die drei verschiedene Probleme in deinem Notion Workspace lösen.

Warum sind Notion Workers wichtig?

Notion Workers sind wichtig, weil sie endlich die drei größten Lücken schließen, auf die jedes ernsthafte Notion-Setup früher oder später stößt: Daten rein, Daten raus und komplexe interne Logik, die eingebaute Automationen nicht bewältigen können.

Wenn Du schon einmal einen Notion Workspace für ein echtes Team betrieben hast, kennst Du die Wand. Notion ist großartig für strukturierte Zusammenarbeit – Datenbanken, Relationen, Views, KI on top – aber sobald Du Daten aus einem Tool ziehen musst, das Notion nicht nativ verbindet, etwas zu WordPress oder Slack nach einem Zeitplan pushen oder Logik ausführen möchtest, die komplexer ist als „wenn X passiert, setze Y“, stößt Du an die Grenzen der eingebauten Automationen.

Bis jetzt war die Antwort immer ein externes System. Make, Zapier, n8n, ein kleines Skript auf dem Laptop von jemandem, ein gehosteter Server irgendwo. Workers ersetzen diese gesamte Schicht – und laufen auf Notions Infrastruktur, sodass Du selbst nichts hostest.

Hier sind die drei klassischen Situationen, in denen Du Notions Standards überholst:

• Externe Daten in Notion. Deine CRM-Deals, deine Stripe-Kunden, deine Ōura-Ring-Daten, deine Newsletter-Analytics oder alles aus einem Tool, für das Notion keinen vorgebauten Connector hat.
• Daten aus Notion heraus. Eine Notion-Seite zu WordPress veröffentlichen, Zeilen in dein Newsletter-Tool synchronisieren, Projekt-Updates in einen Slack-Channel pushen, Rechnungen aus einem Meilenstein generieren.
• Komplexe interne Logik. „Wenn ein Projekt auf In Bearbeitung wechselt, prüfe unsere Prozess-Datenbank, finde die Standard-Aufgaben für diesen Projekttyp, erstelle sie in der Aufgaben-Datenbank, weise sie der richtigen Rolle zu und setze Fälligkeitsdaten basierend auf dem Projektstartdatum.“ Eingebaute Automationen schaffen das nicht. Ein Worker schon.

Sind No-Code-Tools tot?

Kurze Antwort: ja, mit einer Handvoll Ausnahmen. Die drei Gründe, warum No-Code-Tools existierten – Geschwindigkeit, Kosten, Zugänglichkeit – sind im Jahr 2026 keine Gründe mehr.

Das ursprüngliche Versprechen von No-Code war solide. Du konntest Workflows schneller aufbauen als mit klassischer Entwicklung, zahltest einen Bruchteil der Kosten für Custom-Software und brauchtest keinen Ingenieur, um alles zu verkabeln. KI-Coding-Assistenten haben alle drei Aussagen auf den Kopf gestellt.

• Geschwindigkeit. Eine gut formulierte Claude-Code- oder Codex-Session kann einen fertigen Notion Worker schneller scaffolden und deployen, als Du denselben Flow in Make per Drag-and-Drop aufbauen kannst.
• Kosten. Workers laufen auf Notions Infrastruktur. Du zahlst nicht pro Operation, pro Minute oder pro Szenario-Run.
• Zugänglichkeit. Dieser Leitfaden ist der Beweis. Du wirst drei Worker deployen, ohne selbst eine Zeile Code anzufassen.

Es gibt noch ein paar legitime Anwendungsfälle für klassische No-Code-Plattformen – aber sie sind eng und schrumpfen schnell. Für 90 % dessen, was Teams früher in Make oder Zapier gebaut haben, ist Workers + Coding-Agent jetzt die bessere Antwort.

💡 Tipp: Wenn Du einen Hammer hast, sieht alles wie ein Nagel aus. Workers fühlen sich anfänglich redundant an, wenn Du bereits in No-Code-Begriffen denkst. Der Durchbruch ist nicht „Workers ersetzen No-Code eins zu eins“. Der Durchbruch ist: „KI-generierter Code ist jetzt dein No-Code.“

Was sind die drei Typen von Notion Workers?

Notion liefert drei Worker-Archetypen, und Du wählst zwischen ihnen basierend darauf, was den Worker auslöst und ob er seine eigene Datenbank verwaltet. Wähle den falschen Typ, und Du kämpfst stundenlang gegen das System; wähle den richtigen, und der Build ist fast trivial.

Hier die Übersicht auf einen Blick:

Aspekt	Webhook-Worker	Sync-Worker	Tool-Worker
Auslöser	Eine Notion-Automation, ein Button oder ein beliebiger externer HTTP-Call	Ein Zeitplan (cron), den Du festlegst	Ein Custom-Agent, der ihn als Tool aufruft
Datenbank	Arbeitet auf jeder vorhandenen Datenbank	Erstellt und verwaltet seine eigene Read-only-Datenbank	Arbeitet auf jeder vorhandenen Datenbank
Native Planung	Nein (Workaround: geplanter Webhook aus einer Notion-Automation)	Ja (der einzige Worker-Typ mit eingebautem cron)	Nein
Am besten geeignet für	Business-Logik, Aufgaben-Automation, Event-getriebene Flows	Externe Daten nach Zeitplan in Notion ziehen	KI-Agenten-Fähigkeiten erweitern, deterministische Arbeit auslagern
Tutorial-Beispiel	Aufgaben automatisch aus einer Prozess-Datenbank erstellen	Hacker News Top 10 täglich abrufen	Glossar-Einträge von Wikipedia anreichern

Die drei Typen überlappen sich etwas – ein Sync läuft nach Zeitplan, aber ein Webhook kann auch nach Zeitplan aus einer Notion-Automation ausgelöst werden – aber das klarste mentale Modell ist die obige Tabelle. Entscheide nach Auslöser und Datenbankbesitz.

Eine zweite Sicht, die bei der Auswahl hilft, basierend auf dem, was Du tun möchtest:

Du möchtest…	Nutze diesen Worker
Reagieren, wenn sich etwas in Notion ändert (Status, Button, Seite erstellt)	Webhook
Eine externe Datenquelle in Notion spiegeln (einseitig)	Sync
Etwas nach einem festen Zeitplan ausführen, in bestehende Datenbanken schreiben	Webhook (ausgelöst durch eine geplante Notion-Automation)
Einem Notion Custom-Agenten die Fähigkeit geben, eine externe API aufzurufen	Tool
Einen Custom-Agenten günstiger machen, indem deterministische Arbeit ausgelagert wird	Tool
Einen Zwei-Wege-Sync zwischen Notion und einem externen System aufbauen	Webhook (Sync-Worker sind nur einseitig)

Mit dieser Übersicht im Kopf zeigt der Rest dieses Leitfadens einen vollständigen Build für jeden Typ.

Wie richtest Du Notion Workers zum ersten Mal ein?

Das einmalige Setup dauert etwa 15 Minuten und wiederholt sich nie. Du installierst eine Coding-Agent-App, erstellst einen Top-Level-Ordner, installierst die Notion CLI, autorisierst deinen Workspace und aktivierst Workers in den Notion-Einstellungen.

Hier die Checkliste:

Schritt	Was Du tust	Wo
1	Claude (oder Codex) Desktop-App installieren	Dein Rechner
2	Einen Top-Level-Ordner /Claude oder /Codex im Benutzerverzeichnis erstellen	Finder / Datei-Explorer
3	Die Notion CLI installieren (ntn)	Terminal oder über deinen Coding-Agenten
4	Deinen Notion Workspace autorisieren (ntn login)	Terminal
5	Workers unter Einstellungen → Features → Workers aktivieren	Notion-App
6	VS Code als Datei-Browser installieren	Dein Rechner
7	Ein Diktat-Tool installieren (Monologue auf Mac, Wispr Flow auf Windows)	Dein Rechner

Claude oder Codex installieren

Du brauchst einen Coding-Agenten. Die zwei benutzerfreundlichsten Optionen sind die Claude-Desktop-App (wechsle oben links in den Code-Modus) und Codex von OpenAI. Beide funktionieren hervorragend. Claude Code im Terminal ist ebenfalls fein, wenn Du dort bereits wohlfühlst, aber die Apps sind für Einsteiger einfacher.

Ein paar App-weite Einstellungen, die Du einmal setzen solltest:

• Modell: das leistungsstärkste verfügbare (Opus 4.7 oder GPT-5.5 / Äquivalent). Wenn Du lernst, nutze das beste Modell.
• Reasoning-Level: high oder extra high. Reduziere nur, wenn Du dein Usage-Limit ausreizt.
• Permission-Modus: Starte mit auto, damit der Agent vor destruktiven Aktionen fragt. Wechsle zu bypass, sobald Du weißt, was Du erwartest.
• Fast Mode: aus. Er verbraucht Credits viel schneller.

Einen Top-Level-Ordner erstellen

Erstelle auf deinem Rechner einen einzelnen Top-Level-Ordner namens /Claude (oder /Codex) in deinem Benutzerverzeichnis. Jeder Worker, den Du baust, lebt als eigener Unterordner darin. Das ist die gesamte „Projektstruktur“, die Du brauchst.

Die Notion CLI installieren

Die Notion CLI ist ein kleines Command-Line-Tool namens ntn. Damit authentifiziert sich dein Rechner bei Notion und Du deployest Worker. Installiere es mit einem einzigen Shell-Befehl – der einfachste Weg ist, deinen Coding-Agenten einfach zu fragen:

Can you please install the Notion CLI on this machine? Here is the documentation: [link to Notion's CLI install page]

Der Agent führt die Installation durch, bestätigt, dass es funktioniert, und listet nützliche Befehle wie ntn doctor für die Diagnose auf.

Deinen Notion Workspace autorisieren

Sobald ntn installiert ist, führe ntn login in deinem Terminal aus. Ein Browser-Fenster öffnet sich, Du wählst den Notion Workspace, in den Du Worker deployen möchtest, und bestätigst. Das war’s.

Workers in den Notion-Einstellungen aktivieren

Der letzte Vorbereitungsschritt findet in Notion statt. Öffne Einstellungen → Features → Workers. Zwei Dinge zu beachten:

• Du musst einen Business– oder Enterprise-Plan haben.
• Du musst Workspace-Eigentümer sein, um Workers für den Workspace zu aktivieren.

Nach der Aktivierung wählt die zuständige Person, wer Worker deployen darf: alle, nur Admins oder bestimmte Gruppen.

💡 Tipp: Installiere Monologue (Mac) oder Wispr Flow (Windows), bevor Du anfängst. Diktat verändert die Arbeit mit Coding-Agenten grundlegend – Du beschreibst komplexe Builds in 30 Sekunden, statt fünf Minuten zu tippen.

Welche Ordnerstruktur sollte jeder Worker haben?

Jeder Worker bekommt seinen eigenen Unterordner mit demselben Viererdatei-Gerüst: ein README, eine LEARNINGS-Datei, ein CHANGELOG und die Notion-Worker-Skills aus den offiziellen Docs. Die KI pflegt all das – Du bearbeitest sie nie manuell.

Warum das wichtiger ist, als es klingt:

• README – erklärt das Was und Warum dieses spezifischen Workers. Wenn Du in drei Wochen zurückkommst, erinnerst Du Dich in 30 Sekunden an das Ziel.
• LEARNINGS – jedes Mal, wenn die KI eine Eigenheit der Notion API oder deines Workspace herausfindet, schreibt sie es auf. In der nächsten Session lernt sie dieselbe Lektion nicht erneut.
• CHANGELOG – eine laufende Geschichte dessen, was sich verändert hat. Nützlich für das Debugging und um dort weiterzumachen, wo eine vorherige Session aufgehört hat.
• Notion-Workers-Skills – kleine Anweisungsdateien (aus Notions offiziellem Skill-Repository geladen), die deiner KI genau beibringen, wie das Worker SDK funktioniert.

Wenn Du jedes neue Projekt startest, ist deine erste Nachricht an den Agenten im Wesentlichen:

Before we start, please set up the standard structure for this project:
README, LEARNINGS, CHANGELOG, and load the Notion Workers skills from
[link to Notion's skills doc]. Keep all of these maintained as we go.

Der Agent übernimmt alles von dort. Du berührst diese Dateien nie selbst.

Wie baust Du einen Webhook-Worker? (Worker 1)

Webhook-Worker feuern, wenn etwas passiert. Der klassische Anwendungsfall ist die automatische Aufgabenerstellung, wenn ein Projekt auf In Bearbeitung wechselt, die Standard-Aufgabenliste aus einer Prozess-Datenbank zieht, jede Aufgabe der richtigen Rolle zuweist und Fälligkeitsdaten basierend auf dem Projektstartdatum setzt.

Das ist die Art von Business-Logik, die Teams schon immer in Notion wollten. Eingebaute Automationen bringen Dich 60 % des Weges; Worker bringen Dich den Rest.

Die Notion-Seite: Projekte, Prozesse, Aufgaben

Du brauchst drei Datenbanken:

• Projekte – Deine vorhandene Projektdatenbank mit einer Status-Eigenschaft, einer Projekttyp-Eigenschaft (Select), einer Startdatum-Eigenschaft (Date) und einer Verantwortlichen-Eigenschaft (Person).
• Aufgaben – Deine vorhandene Aufgabendatenbank, die mit Projekten verknüpft ist.
• Prozesse – eine neue Datenbank, die die Standard-Aufgaben für jeden Projekttyp auflistet. Jede Zeile hat einen Aufgabennamen, eine Projekttyp-Relation oder Select, eine Reihenfolge (Zahl), einen Fälligkeitsdatum-Offset in Tagen (Zahl) und eine Rolle (eine Person-Eigenschaft).

Die Prozess-Datenbank ist deine lebende Dokumentation. Die sieben Standard-Aufgaben für eine Marketing-Kampagne leben hier als sieben Zeilen. Wenn das Team neun Schritte für den nächsten Kampagnentyp hinzufügt, fügst Du neun Zeilen hinzu. Der Worker liest, was aktuell ist – so ist deine Dokumentation automatisch die maßgebliche Quelle für die Ausführung.

💡 Tipp: Dieses Muster allein ist den Einstieg wert. Die meisten Teams haben ein Dokumentationsproblem – sie schreiben SOPs, die niemand befolgt, oder führen Aufgaben aus, die niemand dokumentiert. Eine mit einem Worker verbundene Prozess-Datenbank verbindet beides: Die Dokumentation zu aktualisieren ist die Ausführung zu aktualisieren.

Beschreibe, was Du bauen möchtest

Öffne einen neuen Projektordner, bitte deinen Coding-Agenten, README / LEARNINGS / CHANGELOG / Skills einzurichten, und diktiere dann, was Du willst.

In Notion, we have a Projects database. When a project's status moves
to "In Progress", I want the worker to check our Processes database,
find all process rows matching that project's Type, and create one
task per process row in the Tasks database.

Each task should:
- Be related back to the project
- Have its due date set to the project start date plus the
  process row's Due Date Offset
- Be assigned to the person matching that process row's Role on
  the project (falling back to the project owner, then to the
  person who created the project)

Three databases: Projects, Processes, Tasks. Here are the links:
[paste your three database URLs]

Before you build anything, ask me any clarifying questions you need.

Der letzte Satz ist das Entscheidende. Versteckte Annahmen sind der wichtigste Grund, warum KI-Builds scheitern. Den Agenten zu zwingen, Dich fünf Minuten lang auszufragen, erspart Dir eine Stunde Debugging.

Deinen ersten Worker deployen

Der Build selbst dauert für den Agenten ein paar Minuten. Wenn er bereit ist zu deployen, werden zwei Dinge das erste Mal blockieren:

• Ein Integration-Token. Der Worker braucht einen Weg, die Notion API tatsächlich aufzurufen. Du erstellst eine interne Integration im Notion-Developer-Portal, gibst ihr einen Namen und kopierst den Token.
• Datenbankzugriff. Dieser Integration-Token funktioniert nur auf Datenbanken, die Du ihm explizit verbindest. Auf jeder Datenbank öffne das Drei-Punkte-Menü → Verbindungen → Verbindung hinzufügen und füge deine neue Integration hinzu.

Den Webhook in Notion verbinden

Ein Webhook-Worker tut nichts, bis ihn etwas anpingt. Der Agent gibt Dir eine Webhook-URL in einer Textdatei – die URL ist faktisch ein Passwort.

In deiner Projekte-Datenbank:

1. Klicke auf + Neue Automation.
2. Setze den Auslöser: Wenn Status auf „In Bearbeitung“ gesetzt wird.
3. Füge die Aktion hinzu: Webhook senden.
4. Füge die Webhook-URL deines Workers ein.
5. Klicke auf Aktivieren.

💡 Tipp: Notion-Webhook-Aktionen können keine benutzerdefinierten Body-Inhalte senden – nur Header. Wenn Claude oder Codex Dich bittet, Werte in den Request-Body zu setzen, erinnere ihn daran: Notions Automation erlaubt nur das Setzen von Headern.

Deinen Webhook mit einem Header-Secret absichern

Jeder mit deiner Webhook-URL kann deinen Worker anpingen. Für alles Echte möchtest Du ein gemeinsames Secret hinzufügen.

Bitte deinen Agenten: „Bitte füge ein Header-Secret hinzu, damit der Worker alle Anfragen ablehnt, die nicht den richtigen Wert enthalten.“ Er generiert ein zufälliges Secret, speichert es in der Umgebung des Workers und sagt Dir, was Du in die Notion-Automation eintragen sollst. Fünf Minuten extra, deutlich bessere Sicherheit.

Testen, Troubleshooting, Iterieren

Bevor Du irgendeinen Status änderst, bitte den Agenten, den Worker zu beobachten:

Ready to test. Please watch the worker logs while I trigger
a few runs, and let me know what happens.

Dann löse ihn aus. Probiere den Happy Path. Probiere ein Projekt ohne Projekttyp. Probiere ein Projekt ohne Startdatum. Jeder Edge Case bringt dem Agenten etwas bei – und da LEARNINGS kontinuierlich aktualisiert wird, bleiben diese Lektionen für die nächste Session erhalten.

Ein echtes Beispiel aus dem Build: Ein Projekt mit einem Typ aber ohne Startdatum scheiterte beim ersten Run, weil der Worker das Startdatum als Pflichtfeld behandelte. Die Lösung brauchte einen Satz: „Wenn kein Startdatum vorhanden ist, falle auf heute zurück.“

Wie baust Du einen Sync-Worker? (Worker 2)

Sync-Worker ziehen externe Daten nach Zeitplan in Notion und schreiben sie in eine Datenbank, die der Worker selbst verwaltet. Die Notion-Seite ist read-only, was garantiert, dass die Daten immer mit der Quelle übereinstimmen.

Das kanonische Beispiel: Jeden Morgen um 7 Uhr die Top-10-Stories von Hacker News abrufen und in eine Notion-Datenbank spiegeln. Ersetze „Hacker News“ durch dein CRM, deine Produktanalysen, dein Newsletter-Tool, deinen Ōura-Ring – dasselbe Muster.

Was macht Sync-Worker besonders?

Drei Dinge unterscheiden Sync-Worker von den anderen beiden Typen:

• Sie verwalten ihre eigene Datenbank. Du kannst einen Sync-Worker nicht auf eine vorhandene Datenbank zeigen. Er erstellt eine neue, besitzt das Schema und schreibt darin.
• Sie sind der einzige Worker-Typ mit nativem cron. Wenn Du möchtest, dass etwas alle 15 Minuten, stündlich oder täglich läuft – und in seine eigene dedizierte Datenbank schreibt – ist Sync der richtige Weg.
• Sie sind einseitig. Sync-Worker schützen synchronisierte Felder vor Bearbeitungen in Notion, was die Integrität garantiert.

Einen Hacker-News-Top-10-Sync bauen

Neuen Projektordner öffnen, Standard-Gerüst einrichten, dann diktieren:

New worker — a sync worker this time. I want to pull the top 10
front-page stories from Hacker News once per day and mirror them
into a managed Notion database under [paste a parent page URL].

Each story should include: title, author, source URL, Hacker News
discussion URL, points, comment count, and posted-at time.

From one daily run to the next, replace — I only want to see the
current top 10, not the historical accumulation.

Ask me any clarifying questions before you build.

Ein paar Minuten später öffnest Du Notion und die Datenbank ist da. Die synchronisierten Spalten sind sichtbar gesperrt.

Deine synchronisierte Datenbank mit eigenen Eigenschaften erweitern

Die synchronisierten Spalten sind read-only. Alles andere gehört Dir. Du kannst hinzufügen:

• Eine Tags-Eigenschaft und einen Custom-Agenten jede Story klassifizieren lassen.
• Eine Relation zu deiner internen Content-Ideen-Datenbank.
• Einen zweiten Worker, der jede Story-URL liest und eine Zusammenfassung in den Seitentext einfügt.

Brauchst Du einen Zwei-Wege-Sync? Hier ist der Workaround

Sync-Worker sind einseitig. Wenn Du einen Zwei-Wege-Sync brauchst, verwende stattdessen einen Webhook-Worker und löse ihn nach einem Zeitplan aus einer Notion-Automation aus.

💡 Tipp: Wenn Du eine verwaltete Sync-Datenbank und die Möglichkeit zur Bearbeitung willst, kannst Du beides derzeit nicht haben. Entscheide basierend darauf, was mehr zählt – Integritätsgarantien (Sync) oder Bearbeitbarkeit (Webhook).

Wie baust Du einen Tool-Worker für einen Custom-Agenten? (Worker 3)

Tool-Worker erweitern die Fähigkeiten von Notion Custom-Agenten. Der Agent gewinnt eine neue Fähigkeit – eine externe API aufrufen, eine deterministische Berechnung ausführen, in ein anderes System posten – und entscheidet selbst, wann er sie nutzt.

Es gibt zwei Gründe, einem Agenten ein Tool zu geben:

• Fähigkeit. Lass den Agenten mit Systemen sprechen, die er sonst nicht erreicht. Dein Data Warehouse abfragen. Zu WordPress veröffentlichen. Jede API aufrufen, die dein Unternehmen nutzt.
• Kosten. Deterministische Arbeit vom Agenten auslagern. Ein Deduplizierungs-Tool, das zurückgibt „diese drei Zeilen sehen wie dieselbe Person aus“, ist hunderte Male günstiger, als den Agenten Zeile für Zeile eine Datenbank scannen zu lassen.

Warum gibst Du deinem Agenten Tools?

Agenten sind gut im Nachdenken. Code ist gut darin, dieselbe Sache zuverlässig und günstig immer wieder auszuführen. Ein gut gestalteter Custom-Agent verwendet Tools für die zweite Kategorie und spart seine Token für die erste.

Einen Wikipedia-Anreicherungs-Worker bauen

Der einfachst mögliche Tool-Worker: Gegeben ein Thema, die Wikipedia-Zusammenfassung abrufen, einen Glossar-Eintrag schreiben und eine Bestätigung zurückgeben.

I want a tool worker that exposes one tool to a Notion custom agent.
The tool takes a topic name, calls the Wikipedia REST API for that
topic, and writes a new row into our existing Glossary database
[paste URL] with the summary, source URL, and thumbnail.

This writes into an existing database — not a managed one.

Ask me any clarifying questions before you build.

Den Worker mit einem Custom-Agenten verbinden

Tools können nur mit Custom-Agenten verbunden werden, nicht mit deinem persönlichen Notion-Agenten.

In den Custom-Agent-Einstellungen:

1. Öffne Verbindungen am unteren Ende der Agenten-Konfiguration.
2. Klicke auf Verbindung hinzufügen und wähle deinen Worker aus der Liste.
3. Wähle, welche Tools des Workers verfügbar gemacht werden sollen.
4. Speichern und den Agenten ausführen.

Dann testen: „Füge einen Glossar-Eintrag für Capybara hinzu.“ Der Agent ruft das Tool auf, das Tool ruft Wikipedia auf, die Zeile erscheint im Glossar.

⚠️ Hinweis: Nur die Person, die den Worker deployed hat, kann ihn mit einem Custom-Agenten verbinden. Andere Teammitglieder können denselben Worker nicht in einen anderen Agenten auf eigene Faust verdrahten.

Ein Worker, viele Tools

Ein Worker kann viele Tools bereitstellen. Wenn dein Data-Agent 15 verschiedene SQL-Abfragen gegen dein Warehouse braucht, deployest Du nicht 15 Worker – Du deployest einen Worker mit 15 Tools. So skalieren reife Teams: eine kleine Anzahl gut organisierter Worker, jeder mit einem kohärenten Toolkit.

Wie solltest Du mit KI beim Bauen von Workers arbeiten?

Das ist der Abschnitt, den die meisten Tutorials überspringen, und der den Unterschied macht zwischen dem Deployen in 20 Minuten und dem Aufgeben nach einer Stunde. Mit KI zu bauen ist eine Disziplin – eine kleine, aber echte.

Die Kernprinzipien:

Prinzip	Was das in der Praxis bedeutet
Versteckte Annahmen zerstören Builds	Zwinge die KI, Dich mit Klärungsfragen auszufragen, bevor sie Code schreibt
Du bist Product, KI ist Engineering	Entscheide was und warum. Lass die KI wie entscheiden
Manage dein Context-Window	Übergib an eine neue Session bei etwa 120–150k Token, bevor die Qualität sinkt
Lebende Docs statt neuer Prompts	README / LEARNINGS / CHANGELOG sind das Arbeitsgedächtnis der KI über Sessions hinweg
Diktiere, tippe nicht	Spracheingabe ist 5–10× schneller als Tippen für komplexe Beschreibungen
Bestes Modell beim Lernen	Opus 4.7 oder Äquivalent. Wechsle zu günstigeren Modellen erst, wenn Du weißt, was Du erwartest

Versteckte Annahmen sind der wichtigste Grund, warum KI-Builds scheitern

KI scheitert nicht am Bauen. KI scheitert daran, das zu bauen, was Du eigentlich gemeint hast. Die Lücke zwischen was Du gesagt hast und was Du gemeint hast ist der Ort, an dem jeder missratene Build lebt.

Die Lösung ist mechanisch: Lass den Agenten nie bauen, bevor er Klärungsfragen gestellt hat. Zwei Wege:

• Füge es in deinen Prompt ein. Beende jeden Build-Prompt mit „Bevor Du irgendetwas baust, stelle mir alle Klärungsfragen, die Du hast.“
• Nutze den Plan-Modus oder einen Grill-Skill. Claude hat einen eingebauten Plan-Modus. Der grill-me-Skill von Peter Pocock zwingt den Agenten, weit mehr Fragen zu stellen, als sich angenehm anfühlt.

Du bist Product. KI ist Engineering.

Wenn der Agent eine Product-Frage stellt (soll das stündlich oder täglich laufen?), beantworte sie. Wenn er eine Engineering-Frage stellt (welcher Hacker-News-Endpunkt ist effizienter?), sag ihm, er soll die Entscheidung treffen.

Manage dein Context-Window aggressiv

In der Praxis ist 120–150k Token der Sweet Spot – darüber hinaus sinkt die Antwortqualität. Wenn Du diese Schwelle überschreitest, bitte den Agenten, ein Übergabe-Dokument zu schreiben:

We're at about 130k tokens of context. Before we go further,
please document everything we've decided and built so far
into the project's HANDOFF.md. Then write me a one-paragraph
prompt I can paste into a fresh session to continue from
where we are.

Du schließt die Session, öffnest eine neue, fügst den Prompt ein und bist wieder bei ~5k Token Kontext ohne Qualitätsverlust.

Plan-Modus und Grill-Me-Skills nutzen

• Plan-Modus (Claude) – schaltet den Agenten in „nicht ausführen, nur planen“-Modus.
• grill-me-Skill (Peter Pocock) – erzwingt einen viel tieferen Frage-Durchgang. Brutal für einfache Builds; perfekt für komplexe.

Diktiere, tippe nicht

Für komplexe Prompts ist Sprache 5–10× schneller als Tippen. Monologue (Mac) und Wispr Flow (Windows) funktionieren überall auf deinem Rechner – in Claude, Codex, deinem Terminal und deinem Browser.

Lass deine Dokumente leben

README, LEARNINGS, CHANGELOG, HANDOFF – das ist, wie der Agent sich über Sessions hinweg erinnert, und wie Du Dich erinnerst, wenn Du in drei Wochen zurückkommst.

Welche Sicherheits-Best-Practices gelten für Notion Workers?

Ein paar Nicht-Verhandelbare:

• Füge niemals Integration-Token oder Secrets direkt in den Chat ein. Nutze eine .env-Datei.
• Füge jedem Webhook-Worker ein Header-Secret hinzu. Verhindert, dass jeder mit der URL deinen Worker auslösen kann.
• Scope deine Integration-Token eng. Gib der Integration nur Zugriff auf die Datenbanken, die sie braucht.
• Rotiere Keys, wenn Du sie je offenlegst. Wenn ein Token in einem Screenshot oder öffentlichen Dokument erscheint – rotiere ihn sofort im Notion-Developer-Portal.
• Nutze VS Code als glorifizierten Datei-Browser. Das Inspizieren deiner .env– und Übergabe-Dokumente in einem echten Editor erkennt Fehler, die der Chat nie sieht.

💡 Tipp: Behandle jede Webhook-URL wie ein Passwort. Füge sie niemals in Slack, E-Mail oder anderswo ein, wo sie bestehen bleiben könnten.

Was solltest Du als Nächstes bauen?

Drei fertige Worker später ist die Welt wirklich deine Austernschale. Der schwierige Teil war nie das Bauen – es war zu wissen, nach welchem Worker-Typ Du greifen und wie Du mit der KI sprechen solltest.

Ein paar Startpunkte:

• Webhook: Wenn ein Deal in deinem CRM auf Won wechselt, erstelle ein Kick-off-Projekt mit allen Standard-Aufgaben.
• Webhook: Wenn eine wiederkehrende Aufgabe abgeschlossen ist, erstelle die nächste Instanz.
• Sync: Spiegle deine Stripe-Kunden in eine Notion-Datenbank zur Querverweisierung mit Kunden in deinem CRM.
• Sync: Ziehe deine wöchentlichen Fitness-Daten (Ōura, Whoop, Apple Health) in ein persönliches Dashboard.
• Tool: Gib deinem Team-„Frag-Alles“-Agenten die Fähigkeit, dein Data Warehouse für Live-Zahlen abzufragen.
• Tool: Lass einen Content-Custom-Agenten einen fertigen Post in einem Schritt zu WordPress veröffentlichen.

Notion hat Workers gebaut, um mit KI-Coding-Agenten gebaut zu werden. Du musst kein TypeScript lernen. Du musst wissen, was Du willst, und die Disziplin mitbringen, gut mit KI zu arbeiten. Dieser Leitfaden hat Dir beides gegeben.

Häufig gestellte Fragen

Muss ich programmieren können, um Notion Workers zu nutzen?

Nein. Notion hat Workers explizit dafür entwickelt, mit KI-Coding-Agenten wie Claude Code oder Codex gebaut zu werden. Du beschreibst, was Du willst, der Agent generiert das TypeScript und Du deployest es mit einem einzigen Befehl.

Welchen Plan brauche ich für Notion Workers?

Workers befinden sich in der öffentlichen Beta auf Business– und Enterprise-Plänen. Während der Beta kostenlos. Ab dem 11. August 2026 werden Notion-Credits benötigt.

Können die Tools eines Custom-Agenten im Team geteilt werden?

Indirekt. Nur die Person, die den Worker deployed, kann seine Tools mit einem Custom-Agenten verbinden. Andere Teammitglieder können den Agenten nutzen, sobald er mit ihnen geteilt wird.

Kann ein Sync-Worker in eine Datenbank schreiben, die ich bereits habe?

Nein. Sync-Worker erstellen und besitzen ihre Datenbank. Wenn Du in eine vorhandene Datenbank nach einem Zeitplan schreiben musst, verwende einen Webhook-Worker.

Wie baue ich einen Zwei-Wege-Sync zwischen Notion und einem externen System?

Nicht mit einem Sync-Worker – die sind nur einseitig. Verwende einen Webhook-Worker und richte eine Notion-Automation ein, die den Webhook nach einem Rhythmus auslöst.

Sollte ich alle meine Make- oder Zapier-Szenarien durch Workers ersetzen?

Für die meisten Fälle ja – letztendlich. Workers sind schneller zu bauen, günstiger im Betrieb und flexibler.

Wie debugge ich einen Worker, der nicht korrekt läuft?

Bitte deinen Coding-Agenten, die Worker-Logs zu lesen. Notion protokolliert jeden Worker-Run automatisch. Der Ablauf: „Der Worker hat in den letzten 10 Minuten viermal laufen und die erwarteten Aufgaben nicht erstellt. Kannst Du die Logs prüfen?“ Der Agent liest die Logs, identifiziert das Problem, schlägt einen Fix vor und deployet neu.