Guillaume Duvernay

Die Beherrschung von n8n-Sub-Workflows kann Sie gefährlich gut in KI machen

12 Min. Lesezeit

n8nagentsAI efficiencyarchitecture

Ein Sub-Workflow in n8n ist ein Workflow, dessen Trigger When executed by another workflow lautet. Sie definieren die Eingabewerte, bauen die Schritte, und das Ergebnis des letzten Knotens ist das, was der aufrufende Workflow zurückerhält.

Es ist eine Funktion, oder ein Microservice, wenn Sie diesen Begriff bevorzugen. Man kann alles bauen, ohne jemals einen zu verwenden, weshalb das viele Menschen auch tun.

Ich möchte eine weitreichendere Behauptung aufstellen, als es der Videotitel suggeriert. Die Beherrschung dieser Technik ist keine n8n-spezifische Fähigkeit. Es ist ein Lernprozess auf einem Canvas, auf dem jeder Schritt sichtbar ist. Hier lernt man die vier Dinge, die entscheiden, ob eine KI-Lösung bezahlbar ist: wiederkehrende Aufgaben in Schritte unterteilen, jedem Schritt nur den nötigen Kontext geben, pro Schritt ein Modell wählen und aufhören, Entscheidungen an einen Agenten zu delegieren, sobald die Reihenfolge feststeht. n8n ist nicht das Thema. Es ist der Ort, an dem diese vier Punkte am deutlichsten werden.

Sub-Workflows eignen sich für zwei Dinge. Das erste ist offensichtlich und spart Wartungsaufwand. Das zweite ist das, was mich all dies gelehrt hat.

Video: Sub-Workflows in n8n: Optimieren Sie Ihre KI-Agenten & skalieren Sie die AutomatisierungPlay

Der langweilige Vorteil: Einmal bauen

Ein Beispiel aus dem Sales Ops: Ein Workflow bearbeitet Demo-Anfragen. Ein anderer verarbeitet eine CSV-Datei mit Event-Teilnehmern. Beide müssen an einem bestimmten Punkt einen Lead anreichern: eine E-Mail nehmen, Firma und Branche von einem Datenanbieter abrufen, ein Modell die Tätigkeit des Unternehmens zusammenfassen lassen und den Lead bewerten.

Das sind fünf oder sechs Nodes. Man kann sie im Workflow für Demo-Anfragen bauen, dann erneut im CSV-Workflow und dann noch in den acht anderen Bereichen, die am Ende dasselbe benötigen.

Die Ausgabe des letzten Nodes ist die Ausgabe des Subworkflows, daher beende ich diese mit einem Edit Fields Node. Das ist der Vertrag, und es lohnt sich, diesen explizit zu definieren, anstatt alles durchsickern zu lassen, was der vorherige Node zurückgegeben hat.

Der Lohn zeigt sich nach sechs Monaten, wenn der Datenanbieter wechselt oder jemand ein zusätzliches Feld in der Ausgabe möchte. Man bearbeitet einen einzigen Workflow. Jeder Aufrufer profitiert davon.

Der interessante Vorteil: Ein Tool, das nur das liefert, was wichtig ist

Das Setup: Ein Biologiekurs liegt in Airtable vor: 15 Kapitel, jedes mit einem Namen, einer Zusammenfassung und dem vollständigen Inhalt. Ein Agent beantwortet Fragen dazu.

Dieser Agent ist bereits besser als die naive Version. Er verfügt über zwei Tools statt eines riesigen Datendumps: die Suche in allen Kapiteln, die nur IDs und Zusammenfassungen zurückgibt, und den Abruf des Kapitelinhalts. Der System-Prompt weist ihn an, zuerst die Zusammenfassungen zu lesen, ein bis drei Kapitel auszuwählen und diese dann abzurufen.

Dieses zweistufige Design ist bereits der größte Gewinn.

Gemessen durch Kopieren der tatsächlichen Tool-Ausgaben in einen Zeichenzähler. Der dritte Balken zeigt, was ein naives Setup bei jeder einzelnen Frage sendet, auch bei Fragen zu nur einem Kapitel.

Warum also noch etwas ändern? Zwei Gründe, und keiner davon hat mit der Wortzahl zu tun.

Das große Modell läuft bei jedem Tool-Aufruf

Betrachten wir eine Ausführung. GPT-5.1 ist angebunden, es ist teuer und leistungsfähig, und es wurde dreimal aufgerufen: einmal für die Entscheidung, Kapitel zu suchen, einmal für den Abruf der Inhalte und einmal für das Schreiben der Antwort.

Jeder dieser Aufrufe enthält die Systemnachricht und den angesammelten Speicher der vorherigen Tool-Ergebnisse. Der Input wächst mit jedem Schritt.

Zwei dieser drei Aufrufe erforderten keine Logik, die ein teures Modell rechtfertigen würde. Sie wählten lediglich aus einer Liste von Zusammenfassungen die relevanten Kapitel aus.

Das Tool liefert Felder, nach denen nicht gefragt wurde

Das Get Record Tool von Airtable hat keinen Feldfilter. Fordert man den vollständigen Inhalt eines Kapitels an, erhält man auch den Kapitelnamen, den Erstellungszeitpunkt und die Zusammenfassung, die man bereits aus dem ersten Aufruf hatte und nun doppelt mitschleppt.

Das lässt sich im Tool selbst nicht beheben. Man kann es einen Schritt später korrigieren, sofern es einen weiteren Schritt gibt.

Ein Subworkflow für den gesamten Abruf

Löschen Sie beide Tools. Ersetzen Sie sie durch ein einziges Subworkflow-Tool, das von einem Thema direkt zum vollständigen Inhalt der richtigen Kapitel führt.

Der einzige farbig markierte Knoten ist das einzige Modell auf diesem Canvas, und es ist ein kleines. Alles andere ist Datentransfer, wofür n8n eigentlich gedacht ist.

Der Auswahlschritt ist derjenige, auf den es ankommt. Sein System-Prompt besteht aus einem Satz: Die User-Nachricht nennt ein Thema, finde ein bis drei relevante Kapitel, hier ist die vollständige Liste der Kapitel mit ihren Zusammenfassungen. Der strukturierte Output ist eine Liste von Record-IDs.

Das ist eine reine Sortieraufgabe gegenüber einer Liste von 15 Zusammenfassungen. GPT-4.1 Mini erledigt das korrekt und schnell, und ich zahle dafür keine Frontier-Preise.

Von zwei auf einen Aufruf bei der Entscheidung, und der gestrichene Schritt ist der, der den meisten akkumulierten Memory-Ballast trug.

Und da sich zwischen Airtable und dem Output ein Set-Knoten befindet, gebe ich nur den Kapiteltitel und den vollständigen Inhalt zurück. Nichts anderes wird übertragen.

Der System-Prompt des Agenten wird ebenfalls kürzer, was meiner Meinung nach viel größeren Einfluss hat, als ich erwartet hätte. Er lautet nun: Antworte basierend auf dem Biologie-Kurs, rufe immer zuerst dieses Tool auf und antworte dann nur mit den Informationen daraus. Ein Tool, keine Sortierregeln, nichts, was schiefgehen kann.

Der gleiche Trick für ein Web-Search-Tool

Zweites Beispiel, gleiches Prinzip. Ein Agent mit einem Web-Search-Tool, in meinem Fall Linkup, wobei Perplexity oder andere Dienste genauso funktionieren.

Verbindet man die API direkt, stößt man auf zwei Probleme. Erstens akzeptiert sie nur eine Frage pro Aufruf, sodass eine breite Frage in Stücken gestellt werden muss, mit jeweils einem Roundtrip. Zweitens enthält die Antwort die vollständige Quellenliste, die ungefragt im Kontext landet.

Vier Knoten, wovon zwei nur dazu da sind, Daten zu verwerfen. Der API-Aufruf in der Mitte ist der Teil, den man auch bei einer direkten API-Anbindung hätte.

Fragt man beispielsweise, wie SEO und Generative Engine Optimization im Jahr 2026 zusammenpassen, zerlegt der Agent dies selbstständig in drei Suchanfragen: Trends und Strategien, Optimierung für beides, Best Practices nach Unternehmensgröße. Ein Tool-Aufruf, drei parallele Suchen, ein bereinigtes aggregiertes Element zurück.

Die Parallelisierung ist das, was man als gefühlte Geschwindigkeit wahrnimmt. Drei sequentielle Zehn-Sekunden-Aufrufe bedeuten eine halbe Minute Wartezeit für den User.

Ein Skelett, nicht drei Workflows

Ich habe einen dritten dieser Workflows für einen RAG-Agenten gebaut, basierend auf einem vektorisierten Kurs in Supabase. Er sieht im Canvas anders aus, ist aber im Kern dasselbe.

Jeder meiner Retrieval-Sub-Workflows folgt diesem Muster. Die variablen Schritte sind die Quelle in der Mitte und ob es Filterkriterien gibt.

Der Filter ist der Schritt, den die anderen beiden nicht haben, da ein Vector Store einen Similarity-Score zurückgibt, Airtable hingegen nicht. Wenn die Quelle eine Zahl liefert, können Ergebnisse verworfen werden, die nicht gut genug sind. In diesem Workflow liegt die Grenze bei 0,4; alles darunter erreicht den Agenten nicht.

Zwei Dinge, die ich beim Bau des dritten Workflows gelernt habe und die ich nun in allen drei implementieren würde.

Output-Felder benennen. Die Aggregation am Ende sollte kein anonymer Blob sein, sondern ein Feld namens Knowledge base retrieval, in dem jeder Eintrag Query to the knowledge base mit Chunks returned paart. Das Modell liest diese Namen. Ihm einfach ein Array zu übergeben und zu hoffen, dass es errät, welches Ergebnis zu welcher Frage passt, ist ein Preis, den man am Ende bei der Antwortqualität zahlt.

Mitteilen, wenn nichts gefunden wurde. Ein Filter, der alles entfernt, produziert keine Elemente. Keine Elemente bedeuten, dass der nächste Knoten nie ausgeführt wird und der Agent Stille erhält. Daher folgt nach dem Filter ein IF-Knoten, dessen leerer Zweig einen Satz schreibt: Für diese Anfrage wurde keine Relevanzschwelle erreicht. In n8n bedeutet das auch, den Filter so einzustellen, dass er immer Daten ausgibt, da sonst der für diesen Fall geschriebene Zweig niemals feuert.

Der zweite Punkt ändert, was der Agent tun kann. Sein System-Prompt endet mit der Anweisung, dass er angeben soll, wenn er etwas nicht weiß, anstatt auf allgemeines Wissen zurückzugreifen. Diese Anweisung ist nur ehrlich, wenn auch die darunter liegende Abfrage ehrlich kommuniziert, dass sie leer zurückkam.

Das alles hat eigentlich nichts mit n8n zu tun

Alle drei Ansätze tun dasselbe: Sie schalten Schritte zwischen den Agenten und die rohe Antwort und werfen in diesen Schritten Dinge weg. Hier ist der Grund, warum ich glaube, dass das wertvoller ist als ein einfacher Workflow.

Ein wiederkehrendes Problem in Einzelschritte zu zerlegen, ist der entscheidende Punkt. Eine Aufgabe, die man nur einmal ausführt, darf schlampig sein. Eine Aufgabe, die man dreihundertmal ausführt, rächt sich dreihundertmal für diese Schlampigkeit. Wenn ein Agent bei jedem dieser Durchläufe die Reihenfolge selbst entscheiden muss, bezahlt man ein Modell dafür, dass es eine Zeichnung neu entdeckt, die man längst auf Papier hätte festlegen können. Sobald man die Schritte kennt, ist das schriftliche Fixieren kein Verlust an Flexibilität, sondern genau das Ziel.

Jeder Schritt erhält nur den Kontext, den er benötigt, und sonst nichts. Genau das bewirken alle Clean-up-Knoten in diesem Artikel. Das ist es auch, was ich mit Jev gemessen habe: Ein kleiner Classifier vor einem Agenten, der entscheidet, welche Skills vorab geladen werden und Felder aus jeder Tool-Antwort entfernt, die niemals gelesen werden. Das war im Durchschnitt 29 % günstiger und bei der besten Aufgabe sogar 61 %, ohne Qualitätsverlust. Gleiche Idee, eine Ebene höher. Kontext ist nicht kostenlos, und ein Großteil dessen, was ankommt, würde sowieso nie gelesen werden.

Das richtige Modell für jeden Schritt. Eine Sortierung anhand von fünfzehn Zusammenfassungen ist keine Aufgabe für ein Frontier-Modell. Sobald die Schritte getrennt sind, ist das keine bloße Meinung mehr, sondern eine Einstellung, die man pro Knoten ändern kann.

Dann orchestrieren statt delegieren. Die Schritte müssen sich gegenseitig etwas Nützliches übergeben. Deshalb erhalten die Ausgabefelder Namen und ein leeres Ergebnis wird explizit so benannt. Das ist Orchestrierung, und genau diesen Teil erledigt ein Agent unsichtbar und schlecht.

Das ist dieselbe Überlegung, warum ich aufgehört habe, MCP für alles zu verwenden, was sich wiederholt: ein Skript gegen die API kann das Filtern, das Mapping und die Schleife ohne ein Modell dazwischen erledigen, und MCP kann das nicht, weil das Modell eben genau die Mitte ist.

Agenten verstecken all diese vier Punkte, und genau deshalb lohnt es sich, einmal einen selbst gebaut zu haben. Wenn ich in Claude Code bin und etwas langsam oder teuer erscheint, suche ich nach dem Schritt, der alles zurückgegeben hat, obwohl ich nur drei Felder brauchte. Das ist fast immer der Fall, und ich weiß nur deshalb, wonach ich suchen muss, weil ich diesen Schritt einmal selbst verdrahtet und die Token-Zahl beobachtet habe.

Quellen