Multi-Agent-Orchestrierung in Notion ermöglicht es dir, mehrere spezialisierte KI-Agenten zu einem produktiven Workflow zu verknüpfen — und das schlägt einzelne, monolithische Agenten konsistent. Wenn du schon mal versucht hast, einen einzigen Agenten einen gesamten Prozess von Anfang bis Ende abwickeln zu lassen, hast du wahrscheinlich bemerkt, dass die Qualität einbricht, sobald die Komplexität steigt. Der Fix ist kein besserer Prompt. Es ist die Aufteilung der Arbeit auf mehrere spezialisierte Agenten — jeder verantwortlich für einen klar definierten Job. Hier erfährst du, wie du Multi-Agent-Flows in Notion mit vier Kernbausteinen designst, aufbaust und betreibst: Jobs, Contracts, Drivers und Logs.
Warum Multi-Agent-Orchestrierung wichtig ist
Einen riesigen Agenten zu betreiben, der alles erledigt, klingt effizient. In der Praxis ist es das Gegenteil.
Es gibt vier Kerngründe, warum die Aufteilung der Arbeit auf mehrere Agenten bessere Ergebnisse liefert.
Monolithische Flows verschlechtern sich mit wachsender Komplexität. LLMs haben heute riesige Context Windows — aber nur weil sie enorme Datenmengen verarbeiten können, bedeutet das nicht, dass sie es sollten. Ein bekanntes Beispiel: Meta KI-Sicherheitsforscherin Summer Yue wies OpenClaw auf ihr Postfach hin — mit klarer Anweisung, nichts zu löschen. Das Postfach war so groß, dass der Agent seine ursprüngliche Anweisung während des Laufs aus den Augen verlor und anfing, E-Mails zu löschen. Sie musste physisch zu ihrem Mac mini rennen, um ihn zu stoppen.
Wenn ein Prozess vier separate Schritte hat, gibt es keinen Grund, warum Schritt vier noch den irrelevanten Kontext aus Schritt eins tragen sollte. Fokus produziert bessere Ergebnisse — für Menschen und KI gleichermaßen.
Kosten skalieren mit dem anspruchsvollsten Teilschritt. Wenn du alles in einen Agenten packst, bestimmt der anspruchsvollste Schritt das Modell. Du würdest deinen Senior-Entwickler nicht für Aufgaben einsetzen, die ein Junior-Research-Assistent erledigt. Genau das passiert aber, wenn ein Agent auf Opus laufen muss, weil einer seiner vielen Schritte komplexes Denken erfordert. Mit Multi-Agent-Flows setzt du teure Modelle nur dort ein, wo sie gebraucht werden — und lässt günstigere den Rest erledigen.
Troubleshooting wird möglich. KI-Outputs sind nicht-deterministisch. Wenn in einem riesigen Block etwas schiefläuft, viel Spaß beim Herausfinden wo. Mit Multi-Agent-Flows ist jeder Agent für ein Ergebnis verantwortlich. Du kannst genau feststellen, welcher Schritt — Recherche, Aggregation, Entwurf — bessere Anweisungen oder mehr Kontext braucht.
Retries sind chirurgisch, nicht atomar. Wenn ein monolithischer Agent scheitert, führst du die gesamte Sequenz erneut aus. Bei Multi-Agent-Chains startest du ab Schritt drei oder vier neu. Du kannst einen menschlichen Kontrollpunkt genau dort einbauen, wo er wichtig ist. Das senkt Kosten und Troubleshooting-Aufwand dramatisch.
Wie Multi-Agent-Orchestrierung in Notion funktioniert
In Notion funktioniert Multi-Agent-Orchestrierung über lineare Übergabe-Chains — Agent A schließt seinen Job ab, gibt Ergebnisse an Agent B weiter, der an C weitergibt, und so fort.
Das unterscheidet sich von Orchestrator-Tools wie Claude Code oder dedizierten Agent-Frameworks, wo ein Hauptorchestrator spontan entscheidet, welche Sub-Agenten er braucht und sie parallel ausführt. In Notion kann ein Agent derzeit keine mehreren Sub-Agenten innerhalb derselben Session starten.
Das ist aber tatsächlich eine Stärke, keine Einschränkung.
Für die meisten Produktions-Workflows würdest du den genauen Datenfluss ohnehin im Voraus planen wollen. Vorab geplante Chains produzieren zuverlässige Ergebnisse. Ad-hoc-Orchestrierung produziert variable Ergebnisse. Wenn du Workflows aufbaust, die im Hintergrund ohne deine Aufmerksamkeit laufen, gewinnt Zuverlässigkeit immer.
Du kannst trotzdem Logik verzweigen — “wenn X passiert, übergib an diesen Agenten; wenn Y passiert, an jenen.” Aber das Kernkonzept ist ein Fließband. Dinge durchlaufen eine definierte Sequenz in Richtung des gewünschten Ergebnisses.
Pro Tip: Beginne damit, deine Chain auf Papier oder einem Whiteboard zu skizzieren, bevor du Notion anfasst. Notion hat noch keinen visuellen Workflow-Builder, daher verhindert das Skizzieren des Flows vorab, dass du etwas baust, das sich in sieben Richtungen verzweigt, bevor du den Kernpfad bewiesen hast.
Die vier Bausteine
Jedes Multi-Agent-System in Notion ruht auf vier Bausteinen: Jobs, Contracts, Drivers und Logs. Bau diese richtig, und deine Agenten laufen wie ein gut geöltes Fließband.
Hier erklärt, wie jeder funktioniert — illustriert anhand einer Live-Content-Produktions-Pipeline, die YouTube-Video-Transkripte in veröffentlichte Blog-Posts verwandelt. Für ein umfassendes Tutorial zum Aufbau dieser Systeme lies den vollständigen Custom Agents Guide.
Baustein 1: Wie definierst du Jobs?
Ein Agent, ein Job. Das ist die Regel.
Schau dir deinen Prozess an und teile ihn in die Teilschritte auf, die ein Mensch durchführen würde. Auch wenn es sich wie eine Aufgabe anfühlt, ist es wahrscheinlich ein Projekt mit unterschiedlichen Phasen. Das ist der Kern der Notion AI Skill Engineering — die Aufteilung komplexer Prozesse in fokussierte, spezialisierte Jobs. Je granularer und präziser du wirst, desto besser sind deine Ergebnisse. Lerne, wie du diese Job-Grenzen designst mit den Frameworks, die Top-Teams verwenden.
Nehmen wir eine Content-Produktions-Pipeline als Beispiel. Ein monolithischer Agent müsste den Artikel entwerfen, Links platzieren, Assets generieren, SEO-Metadaten schreiben und übersetzen — alles in einem Lauf mit einem Modell. Context-Bloat, zweifelhafte Qualität und horrende Kosten, weil alles auf Opus läuft.
Teile das in dedizierte Jobs auf, und das Bild ändert sich komplett:
- Transkript → Artikel (Opus — der einzige Schritt, der komplexes Denken braucht)
- Link-Platzierung (Haiku — folgt klaren Richtlinien, keine komplexe Logik)
- Asset-Generierung (generiert unterstützende Grafiken für den Post)
- SEO-Metadaten (Haiku — einfacher, formelhafter Output)
- Übersetzung ins Deutsche (unkomplizierte Sprachaufgabe)
Jeder Agent macht eine Sache gut. Jeder kann das günstigste Modell verwenden, das den Job erledigt. Für Team-basierte Setups skaliert diese Struktur wunderbar über Abteilungen hinweg.
Pro Tip: Wenn du dir einen Prozess aussuchst, der sich auf halbem Weg in sieben Richtungen verzweigt, fang einfacher an. Finde den Kern-80/20-Workflow — die drei bis sechs Schritte, die bereits Mehrwert liefern. Bau darauf auf, wenn er bewiesen ist.
Baustein 2: Wie funktionieren Contracts zwischen Agenten?
Contracts sind die Handshakes zwischen Agenten. Sie definieren, was ein Agent produzieren muss, damit der nächste nahtlos weitermachen kann.
Denk daran wie menschliche Übergaben. Wenn dein Editor einen Entwurf an die nächste Person in der Chain weitergibt, muss jeder das genaue Format, den erwarteten Output und den Inhalt kennen. Ein Mensch kann einen Kollegen nachhaken und fragen: “Ich brauchte die Dateien eigentlich in einem anderen Format.” Agenten können das nicht — Agent B kann nicht zu Agent A zurückrufen. Also muss der Contract von Anfang an stimmen.
Wie optimierst du Tokens über die Chain?
Die zweite Dimension von Contracts ist Token-Effizienz. KI ist nicht kostenlos, und immer mehr Tools gehen zu nutzungsbasierter Preisgestaltung über. Wenn du diese Flows baust, willst du, dass jede Übergabe so schlank wie möglich ist.
Der Vergleich mit menschlichen Teams gilt: Person drei in der Chain würde nicht exakt dasselbe Quellmaterial noch einmal lesen wie Person eins. Idealerweise bereiten frühere Schritte Informationen für spätere vor und komprimieren sie.
Im Content-Pipeline-Beispiel sieht nach dem ersten Agenten, der das Transkript in einen Artikel umwandelt, kein nachfolgender Agent das Transkript je wieder. Das Transkript ist das größte, teuerste Datenstück. Alle nachgelagerten Agenten lesen nur den Artikel.
In anderen Szenarien kannst du noch weiter gehen. Wenn du ein tägliches Briefing-System mit Agenten aufbaust, die Meetings, E-Mails und Aufgaben separat verarbeiten, sollte jeder eine kurze Zusammenfassung auf einer gemeinsamen Seite ausgeben. Der finale Briefing-Agent liest nur diese Zusammenfassungen — niemals die rohen Transkripte oder Posteingänge.
Pro Tip: Such nach Synergien über Flows hinweg. Wenn du bereits einen Agenten hast, der Meeting-Transkripte verdaut und Action Items extrahiert, könnte es effizienter sein, eine zusätzliche Output-Zeile anzuhängen (“welche wichtigen Erkenntnisse gibt es für X?”), als einen separaten Agenten dasselbe Transkript lesen zu lassen. Das steht im Widerspruch zum Ein-Agent-ein-Job-Prinzip — es ist mehr Kunst als Wissenschaft. Aber wenn es ein einfacher Zusatz für einen Agenten ist, der diesen Kontext ohnehin schon synthetisiert, sind die Token-Einsparungen es wert.
Warum ist das Externalisieren von Memory so wichtig?
Jeder Agent ist eine eigenständige Session. Er hat nur den Kontext, den du ihm gibst.
Das ist der fundamentale Trade-off gegenüber einem monolithischen Flow, wo der Agent zumindest theoretisch frühere Schritte in Erinnerung hat (obwohl das in der Praxis oft schlecht funktioniert).
Damit Multi-Agent-Flows funktionieren, muss jedes relevante Arbeitsergebnis aufgeschrieben werden — externalisiert auf eine Notion-Seite oder Datenbank-Property. In Notion ist das einfach. Du hast Datenbanken für strukturierte Daten und Seiten mit Markdown für unstrukturierte Inhalte.
Aber hier ist der kritische Unterschied zu menschlichen Teams: Wenn ein Kollege vergisst, etwas aufzuschreiben, kannst du rübergehen und fragen. Agenten können das nicht. Agent B kann Agent A nichts fragen. Und selbst wenn er könnte, hätte Agent A drei Wochen später null Erinnerung. Alles irgendwie Relevante muss externalisiert werden. Keine Ausnahmen.
Baustein 3: Was treibt die Übergabe zwischen Agenten?
Drivers sind der Mechanismus, der dem nächsten Agenten mitteilt, dass es Zeit ist zu starten. In Notion funktioniert das über strukturierte Daten in deinen Datenbanken.
Ein Agent kann nicht direkt einen anderen Custom Agent aufrufen und Informationen an ihn übergeben. Aber er kann seine Ergebnisse externalisieren, einen Property-Wert setzen — und der nächste Agent kann auf diese Property-Änderung triggern.
Das Dual-Status-Muster
Der praktischste Ansatz ist das Hinzufügen einer zweiten Status-Property, die speziell für KI-Übergaben gedacht ist.
Normalerweise würde man stark davon abraten, zwei Status-Properties in einer Datenbank zu haben — das wird verwirrend. Aber wenn du für menschliche und KI-Workflows zusammen designst, ergibt es Sinn. Lerne mehr über Custom Agent-Konfiguration, um zu sehen, wie dieses Muster in der Praxis funktioniert.
Menschliche Statuses sind tendenziell übergeordnet: In Progress, In Review, Done. Granulare Teilschritte zu aktualisieren wäre für eine Person überwältigend. Aber genau das braucht KI.
Also erstellst du eine dedizierte AI Stage-Property mit Werten wie:
- Transkript bereit → triggert den Artikel-Entwurfs-Agenten
- Entwurf bereit → triggert den Link-Platzierungs-Agenten
- Links platziert → triggert die Asset-Generierung
- SEO abgeschlossen → triggert die Übersetzung
Die finale Anweisung jedes Agenten: setze die AI Stage auf den nächsten Wert. Der Trigger jedes nachfolgenden Agenten: wenn AI Stage sich auf seinen designierten Wert ändert.
Das macht auch das Aufspüren von Fehlern trivial. Du siehst auf einen Blick, in welchem Stadium ein Inhalt stecken geblieben ist.
Pro Tip: Weise deine Agenten an, einen Seitenkommentar zu hinterlassen, wenn sie ihre Aufgabe nicht erfüllen können. Notion-Agenten haben ein Kommentar-Tool — sie können Notizen hinterlassen wie jede menschliche Mitarbeitende, ohne den Hauptseiteninhalt zu überladen. Das macht die Überprüfung mühelos.
Kannst du stattdessen Tasks verwenden?
Eine Alternative zu statusbasierten Drivers ist die Verwendung deiner bestehenden Task-Datenbank. Statt “AI Stage geändert auf Entwurf bereit” lautet der Trigger dann “neue Aufgabe zugewiesen an Agent B: Blog Post X aktualisieren.”
Beide Ansätze funktionieren. Statusbasierte Drivers sind einfacher einzurichten. Taskbasierte Drivers geben dir mehr Sichtbarkeit — du siehst, wie Dinge abgehakt werden — und sie integrieren sich natürlich, wenn du bereits ein robustes Task-Management-System hast.
Ein Workflow, wo taskbasierte Übergaben glänzen: Kommunikations-Chains. Ein Projektmanager-Agent prüft, welche Kommunikation nötig ist, und erstellt dann Entwurfsaufgaben für einen Schreib-Agenten. Der Schreib-Agent nimmt jede Aufgabe auf, prüft das Briefing und entwirft die Nachricht.
Baustein 4: Warum sind Logs unverzichtbar?
Dein System kann mit nur den ersten drei Bausteinen funktionieren. Aber Logs sind das, was den langfristigen Unterschied macht.
Sichtbarkeit darüber zu schaffen, was deine Agenten tun, wo sie erfolgreich sind und wo sie scheitern, ist entscheidend. Das wird beim ersten Mal nicht perfekt funktionieren. Wenn etwas schiefgeht — und das wird es — musst du es schnell erkennen, besonders in Flows, an denen mehrere Personen beteiligt sind.
Allgemeine Agent-Run-Logs
Erstelle eine zentrale Datenbank für alle Agent-Runs. Am Ende jedes Runs protokolliert jeder Agent seinen Output: welcher Agent lief, zu welchem Flow er gehörte, eine Zusammenfassung des Ergebnisses und ob es upstream oder downstream Probleme gab.
Du kannst eine Posteingangs-Ansicht für den Prozessverantwortlichen erstellen, die alle fehlgeschlagenen Runs anzeigt, die überprüft werden müssen. Du kannst Slack-Benachrichtigungen bei Fehlern auslösen. Und vor allem kannst du die Daten nutzen, um deine Flows im Laufe der Zeit zu verbessern.
Dedizierte Feedback-Loop-Logs
Für Flows mit einer spezifischen Qualitätsdimension ist eine dedizierte Log-Datenbank die Investition wert.
Beispiel: ein Wissens-Bot in Slack, der Team-Fragen aus deinem Company-Wiki beantwortet. Jedes Mal, wenn der Agent antwortet, bewertet er die Qualität seiner eigenen Antwort. Hat er die Information gefunden? War die Antwort vollständig? Immer wenn die Antwort unvollständig oder fehlend ist, empfiehlt der Agent, wie die Dokumentation verbessert werden kann.
Im Laufe der Zeit erzeugt das einen positiven Flywheel. Jeder Run, bei dem der Agent nicht vollständig antworten kann, zeigt eine Lücke. Der Prozessverantwortliche füllt die Lücke. Der nächste Run ist besser. Compound Value.
Dieses Prinzip gilt weit über Wissens-Bots hinaus:
- Asset-Generierung → Outputs für menschliche Qualitätsprüfung protokollieren
- Social-Media-Hooks → Scores und Feedback erfassen
- E-Mail-Entwürfe → verfolgen, welche starke Bearbeitung brauchten
Jeder Flow, bei dem menschliches Feedback die KI beim nächsten Mal besser machen würde, ist eine Chance für ein dediziertes Feedback-Log.
Monolithischer Agent vs. Multi-Agent-Chain: Im Vergleich
Hier ein Vergleich beider Ansätze über die Dimensionen, die in der Produktion am meisten zählen:
| Monolithischer Agent | Multi-Agent-Chain | |
|---|---|---|
| Context-Management | Alle Schritte teilen ein wachsendes Context Window — Risiko des Instruktionsverlusts bei steigender Komplexität | Jeder Agent bekommt nur den Kontext, den er braucht — fokussiert, schlank, zuverlässig |
| Modellkosten | Der anspruchsvollste Teilschritt bestimmt das Modell für den gesamten Run (z.B. Opus für alles) | Teure Modelle nur wo nötig — günstige Modelle erledigen einfache Schritte |
| Troubleshooting | Black Box — schwer zu isolieren, wo Anweisungen oder Kontext versagt haben | Jeder Agent verantwortet ein Ergebnis — Fehler sofort lokalisierbar |
| Retry-Kosten | Vollständiger Re-Run bei jedem Fehler | Neustart ab dem fehlgeschlagenen Schritt |
| Menschliche Kontrolle | Alles oder nichts — Überprüfung des gesamten Outputs am Ende | Kontrollpunkte an jedem Schritt in der Chain einbaubar |
| Skalierbarkeit | Neue Schritte erhöhen Context-Bloat und Fehlerrisiko | Neue Schritte fügen sich in die Chain ein, ohne bestehende Agenten zu beeinflussen |
Nächste Schritte
Wenn du bereit bist, dein erstes Multi-Agent-System in Notion zu bauen, beginne mit dem vollständigen Custom Agents Tutorial. Dort findest du Schritt-für-Schritt-Anleitungen, Code-Beispiele und echte Implementierungen.
Für Teams, die Notion AI und Custom Agents professionell implementieren möchten, biete ich spezialisierte Beratung und Setups an.
Häufig gestellte Fragen
Können Notion-Agenten direkt miteinander kommunizieren?
Nicht im traditionellen Sinne. Notion-Agenten können innerhalb einer Session keine anderen Agenten aufrufen oder starten. Stattdessen kommunizieren sie über strukturierte Daten — ein Agent schreibt seine Ergebnisse auf eine Seite oder in eine Datenbank-Property, und der nächste Agent triggert auf diese Änderung. Es ist ein lineares Übergabe-Modell statt eines Live-Orchestrierungsmodells — und für Produktions-Workflows liefert das tatsächlich zuverlässigere Ergebnisse.
Wie viele Agenten sollten in einer Chain sein?
Beginne mit drei bis sechs. Teile deinen Prozess in die kleinstmöglichen sinnvollen Teilschritte auf — aber fragmentiere nicht zu stark. Jeder Agent sollte einen klaren, distinkten Job mit einem definierten Output haben. Wenn zwei Schritte trivial einfach und eng verwandt sind, kann ihre Zusammenführung in einen Agenten Tokens sparen, ohne Qualität zu opfern. Der Sweet Spot: jeder Agent kann unabhängig getestet und verbessert werden.
Kostet Multi-Agent-Orchestrierung mehr als ein einzelner Agent?
Nicht unbedingt. Zwar führst du mehr einzelne Agent-Sessions aus, aber jede Session ist schlanker. Günstigere Modelle wie Haiku erledigen einfache Schritte, und kein Agent verarbeitet Kontext, den er nicht braucht. In vielen Fällen sind die gesamten Token-Kosten niedriger als bei einem Opus-Agenten durch einen gesamten Prozess — plus du sparst bei fehlgeschlagenen Retries, da du nur den kaputten Schritt wiederholst.
Was ist der beste Weg, Fehler in einer Multi-Agent-Chain zu behandeln?
Nutze eine Kombination aus Agent-Run-Logs und Seitenkommentaren. Weise jeden Agenten an, seinen Run in einer zentralen Datenbank zu protokollieren und einen Kommentar auf der Seite zu hinterlassen, wenn er auf ein Problem stößt. Erstelle eine Posteingangsansicht, gefiltert nach fehlgeschlagenen Runs, damit der Prozessverantwortliche Probleme sofort sieht. Für kritische Flows kannst du auch Slack-Benachrichtigungen bei Fehler-Status-Änderungen auslösen.
Brauchst du zwei Status-Properties für jede Datenbank?
Nicht für jede Datenbank — nur für solche, in denen KI-Agenten Teil eines mehrstufigen Workflows sind. Das Dual-Status-Muster (eine für Menschen, eine für KI) verhindert, dass dein Team granulare KI-Teilschritte in seiner regulären Status-Property tracken muss. Wenn dein Agenten-Flow einfach ist — ein Trigger, ein Agent, fertig — ist eine einzelne Status-Property völlig ausreichend.
