Multi-Agent-Orchestrierung in n8n: Agenten-Teams für den Mittelstand

Der Agent läuft seit drei Monaten und wird jede Woche ein bisschen schlechter. Anfangs hat er Angebote aus Stichpunkten geschrieben, das war ordentlich. Dann kamen die Preise aus dem ERP dazu, danach die Lieferzeiten, dann die Kundenhistorie, dann die Freigabe per Mail. Heute hängen 34 Werkzeuge in einem einzigen Agenten, der Prompt ist auf 4.000 Tokens gewachsen, und die Trefferquote liegt gefühlt bei zwei von drei Versuchen. Die Kosten pro Lauf sind im selben Zeitraum um 180 Prozent gestiegen. Der Agent ist nicht kaputt. Er ist überladen.

Das Muster ist kein Einzelfall, sondern die typische Kurve jedes ambitionierten Automatisierungsprojekts: Alles, was irgendwie dazugehört, wird in denselben Agenten gesteckt, weil das am Anfang schneller geht. Ab einem bestimmten Punkt kippt die Sache, und zwar nicht leise, sondern mit falschen Zahlen in echten Angeboten.

In diesem Artikel erfährst du, warum der Alleskönner-Agent zwangsläufig scheitert, wie ein Koordinator mit drei Spezialisten aufgebaut ist, wie du das in n8n konkret verdrahtest, was es an Kosten spart und wie du in fünf Tagen von einem überladenen Agenten zu einem kleinen Agenten-Team kommst.

---

Inhaltsverzeichnis

1. Warum der Alleskönner-Agent scheitert
2. Das Muster: ein Koordinator, mehrere Spezialisten
3. Praxis: drei Agenten in n8n verdrahten
4. Kosten, Modelle und Messgrößen
5. In fünf Tagen zum Agenten-Team
6. Fazit

---

Warum der Alleskönner-Agent scheitert

Der deutsche Mittelstand hat die Testphase hinter sich. Der KI-Index Mittelstand 2026, den Salesforce gemeinsam mit dem Deutschen Mittelstands-Bund erhoben hat, kommt auf 51,2 Prozent der befragten Unternehmen, die KI nutzen oder testen, ein Plus von 54 Prozent gegenüber dem Vorjahr. Der interessantere Wert steht daneben: 16,6 Prozent setzen bereits KI-Agenten ein, nach 8,7 Prozent im Jahr davor. Und weniger als fünf Prozent der Unternehmen haben ein KI-Projekt wieder eingestellt. Die Technologie ist also angekommen, die Ernüchterung folgt an anderer Stelle.

Sie folgt dort, wo aus einem Pilot ein Betrieb wird. Eine Studie von T-Systems, im September 2026 veröffentlicht, zeigt die Richtung: 91 Prozent der untersuchten Vorreiter nutzen Wissensassistenten, 83 Prozent automatisierte Dokumentenerstellung. Das sind eng umrissene Aufgaben mit klaren Eingaben und prüfbaren Ausgaben. Sven Giesselbach, CTO AI and Data bei T-Systems International, bringt den Maßstab auf den Punkt: Nicht das technisch Machbare entscheide, sondern der konkrete Nutzen bei beherrschbarem Risiko. Ein überladener Agent ist das Gegenteil davon, weil sein Risiko mit jeder Fähigkeit wächst, ohne dass der Nutzen im gleichen Tempo mitwächst.

Technisch gibt es dafür drei Ursachen, die immer zusammen auftreten.

Die Werkzeugauswahl wird zum Ratespiel. Ein Agent mit 34 Werkzeugen muss bei jeder Anfrage entscheiden, welches davon passt. Jede zusätzliche Option erhöht die Wahrscheinlichkeit einer falschen Wahl, und die Fehler häufen sich, weil ein einmal falsch gewähltes Werkzeug den weiteren Verlauf bestimmt.

Der Kontext wird zum Sammelbecken. Wenn ERP-Daten, Kundenhistorie, Preislisten und Schreibanweisungen im selben Prompt liegen, konkurrieren sie um dieselbe Aufmerksamkeit. Wichtige Regeln, etwa “keine Rabatte unter 12 Prozent ohne Freigabe”, gehen zwischen Lieferzeiten und Tonalitätsvorgaben unter. Das ist kein Modellfehler, sondern eine Folge davon, dass niemand mehr sagen kann, welche Information in einer konkreten Situation wirklich zählt.

Jede Änderung wirkt auf alles. Willst du die Angebotstexte anders haben, änderst du den Prompt, und plötzlich rechnet der Agent anders. Diese Kopplung ist der eigentliche Kostentreiber im Betrieb, weil jede kleine Anpassung ein vollständiger Regressionstest über alle Fähigkeiten ist.

Dazu kommt der Kostenhebel. Ein Alleskönner-Agent läuft fast immer auf dem größten verfügbaren Modell, weil er für die schwierigste seiner Aufgaben gerüstet sein muss. Dass 80 Prozent seiner Aufrufe triviale Klassifikationen sind, zahlt niemand mit.

Das Muster: ein Koordinator, mehrere Spezialisten

Die Gegenarchitektur heißt Orchestrierung, und sie ist nicht neu, sondern nur selten sauber umgesetzt. Statt eines Agenten mit vielen Werkzeugen gibt es einen Agenten mit wenigen Werkzeugen, von denen jedes ein anderer Agent ist.

Der Koordinator hat genau eine Aufgabe: die Anfrage zu verstehen und an den richtigen Spezialisten zu übergeben. Er hat drei bis fünf Werkzeuge, jedes davon ein kompletter Sub-Workflow. Er recherchiert nicht, er rechnet nicht, er schreibt keine Texte. Seine Ausgabe ist eine Entscheidung, kein Inhalt.

Die Spezialisten haben je eine Aufgabe, einen kleinen Prompt und nur die Werkzeuge, die sie dafür brauchen. Der Recherche-Agent liest Mailanhänge und Stammdaten. Der Kalkulations-Agent rechnet mit einer festen Formel und liest die Preisliste. Der Text-Agent formuliert aus einem strukturierten Auftrag. Keiner von ihnen kennt den Prompt des anderen.

Zwischen den Agenten liegt eine Übergabe in festem Format. Das ist der Punkt, an dem die meisten Umsetzungen scheitern: Sie lassen die Agenten in Freitext miteinander reden. Ein Koordinator, der “schick das mal an die Kalkulation” schreibt, hat nichts gewonnen, weil der Empfänger wieder interpretieren muss. Die Übergabe muss ein Objekt mit festen Feldern sein, das validiert wird, bevor der nächste Agent startet.

Und es braucht einen Rückweg mit Abbruchbedingung. Jeder Spezialist kann sagen “kann ich nicht”, zum Beispiel wenn ein Pflichtfeld fehlt. Diese Rückmeldung geht an den Koordinator, der dann entweder nachfragt oder an den Menschen übergibt. Ohne diesen Rückweg entsteht der schlimmste Zustand: ein Agent, der eine fehlende Information erfindet, um die Aufgabe abzuschließen.

Die Wirkung ist nicht nur Qualität, sondern auch Nachvollziehbarkeit. Wenn morgen ein Angebot falsch ist, kannst du die Kette lesen: Was hat der Koordinator erkannt, was hat der Recherche-Agent geliefert, was hat der Kalkulations-Agent gerechnet, was hat der Text-Agent formuliert. Bei einem Monolithen hast du nur einen Prompt und ein Ergebnis. Wie du Freigaben und Grenzen in so einer Kette sauber ziehst, steht ausführlich in KI-Agenten richtig freigeben: Rechte und Grenzen.

Praxis: drei Agenten in n8n verdrahten

Das Beispiel ist bewusst alltäglich: ein Angebot aus einer Kundenanfrage. Bisher macht das ein Alleskönner-Agent, jetzt übernehmen drei Spezialisten.

Der Aufbau in n8n. Das Haupt-Workflow enthält den AI Agent Node mit Agent-Typ “Tools Agent” und dem kleinsten Modell, das zuverlässig klassifizieren kann. Als Werkzeuge hängen drei “Call n8n Workflow Tool”-Nodes daran, die auf drei separate Workflows zeigen: agent_recherche, agent_kalkulation, agent_text. Jeder dieser Workflows ist ein eigenes, testbares Ding mit eigenem Prompt, eigenen Credentials und eigener Fehlerbehandlung.

Die Übergabe als Vertrag. Der Koordinator gibt kein Fließtext-Objekt zurück, sondern ein strukturiertes. In n8n geht das über den Structured Output Parser mit einem JSON-Schema oder über einen Code-Node, der die Ausgabe prüft und bei Abweichung abbricht. Der Code-Node ist der robustere Weg, weil er die Prüfung selbst dokumentiert:

// Code-Node "Uebergabe pruefen"
const d = $json;

const pflicht = ['kunde', 'leistung', 'menge', 'quelle'];
const fehlend = pflicht.filter(f => d[f] === undefined || d[f] === null || d[f] === '');

if (fehlend.length > 0) {
  return [{ json: {
    status: 'rueckfrage',
    fehlende_felder: fehlend,
    grund: 'Anfrage unvollstaendig, keine Kalkulation gestartet'
  }}];
}

if (typeof d.menge !== 'number' || d.menge <= 0) {
  return [{ json: {
    status: 'rueckfrage',
    fehlende_felder: ['menge'],
    grund: 'Menge ist keine positive Zahl'
  }}];
}

return [{ json: {
  status: 'ok',
  auftrag: {
    kunde: d.kunde,
    leistung: d.leistung,
    menge: d.menge,
    quelle: d.quelle,
    eingegangen: d.eingegangen ?? new Date().toISOString()
  }
}}];

Der nachfolgende IF-Node prüft status. Bei rueckfrage geht es in einen Zweig, der eine Mail an den Vertrieb schickt und den Lauf beendet, ohne dass irgendetwas gerechnet wird. Bei ok startet der Kalkulations-Workflow. Diese drei Zeilen sparen in der Praxis mehr Ärger als jede Prompt-Verbesserung, weil sie den häufigsten Fehlerfall abfangen: eine Anfrage, die formal ankommt und inhaltlich unbrauchbar ist.

Der Kalkulations-Agent rechnet nicht mit dem Modell. Das ist der wichtigste Teil und der, der am häufigsten falsch gemacht wird. Preise, Rabattstufen und Deckungsbeiträge gehören in einen Code-Node oder eine Formel, nicht in einen Prompt. Das Modell entscheidet, welche Position aus der Preisliste passt, und übergibt die Positions-ID. Gerechnet wird mit JavaScript. Dieselbe Eingabe führt damit immer zum selben Preis, und du kannst jeden Betrag nachprüfen, ohne ein Modell zu befragen.

Der Text-Agent bekommt nur den fertigen Auftrag. Er sieht Kunde, Leistung, Menge, Preis und einen Tonfall-Hinweis. Er sieht keine Preisliste und keine Kalkulationsregeln. Damit kann er keine Preise verändern, selbst wenn er wollte. Das ist der Grund, warum die Kette stabil bleibt: Jeder Agent hat nur die Informationen, die er für seine Aufgabe braucht.

Freigabe bleibt beim Menschen. Der Text-Agent liefert einen Entwurf, der in einer Pipeline liegt. Versendet wird nach Freigabe. Wie du dabei Fehler behandelst, die niemand bemerkt, steht in Produktivbetrieb: stille Ausfälle erkennen.

Praxistipp: Baue zuerst den Koordinator mit einem einzigen Werkzeug und teste ihn zwei Wochen lang mit echten Anfragen. Wenn die Zuordnung stimmt, also in mindestens neun von zehn Fällen der richtige Spezialist angesprochen wird, kommen die weiteren dazu. Wer mit drei Spezialisten gleichzeitig startet, kann bei Problemen nicht unterscheiden, ob der Koordinator oder ein Spezialist die Ursache ist.

Kosten, Modelle und Messgrößen

Orchestrierung ist auch ein Kostenargument, und zwar ein deutliches. Eine Rechnung aus der n8n-Community, im Juni 2026 veröffentlicht, vergleicht einen Monolithen auf dem großen Modell mit einem Koordinator, der Klassifikation und einfache Schritte an ein kleines Modell routet: aus 26,40 US-Dollar pro 1.000 Läufen werden 8,80 US-Dollar. Das ist ein Richtwert aus einem fremden Setup, keine eigene Messung, und die Zahlen verschieben sich mit Preisen und Prompt-Länge. Die Richtung ist trotzdem stabil, weil der Mechanismus offensichtlich ist: Bei einem Monolithen laufen alle Aufrufe auf dem teuren Modell, bei einer Kette nur die, die es brauchen.

Drei Regeln reichen für die Kostensteuerung.

Das kleinste Modell an den Anfang. Klassifikation, also “worum geht es hier”, ist die billigste Aufgabe in der Kette und braucht kein Spitzenmodell. Sie entscheidet aber über den größten Teil der Kosten, weil sie bei jedem Lauf anfällt.

Das große Modell nur für Sprache. Textformulierung ist die Aufgabe, bei der Qualitätsunterschiede zwischen Modellen für Kunden sichtbar werden. Alles andere, Rechnen, Prüfen, Zuordnen, ist deterministisch lösbar und damit modellunabhängig.

Token pro Lauf als Kennzahl. Notiere für jeden Agenten die durchschnittlichen Tokens pro Lauf und die Zahl der Läufe pro Woche. Diese zwei Zahlen reichen, um zu sehen, ob ein Agent still teurer wird. In fast jedem Fall wächst der Kontext, nicht die Arbeitsmenge.

Dazu kommen drei technische Grenzen, die du setzen musst, bevor der erste Lauf in Produktion geht. maxIterations pro Agent begrenzt die Schleifen, in denen ein Agent sein eigenes Ergebnis nachbessert, bis es passt. Ein Timeout pro Sub-Workflow verhindert, dass ein hängender Spezialist die ganze Kette blockiert. Und ein Fallback-Zweig pro Spezialist legt fest, was passiert, wenn er zweimal hintereinander scheitert: Rückfrage an den Menschen, nicht dritter Versuch.

In fünf Tagen zum Agenten-Team

Tag 1: Zerlegen. Schreibe für deinen überladenen Agenten jede Aufgabe auf eine Karte: Was tut er wirklich? Sortiere die Karten in zwei Stapel, “versteht und entscheidet” und “führt aus”. Der erste Stapel wird der Koordinator, der zweite die Spezialisten. In den meisten Fällen bleiben drei bis vier Karten übrig, die zusammen eine Aufgabe sind. Diese kommen in einen Agenten, nicht in drei.

Tag 2: Den Koordinator bauen. Ein Agent, ein Modell, höchstens fünf Werkzeuge, jedes Werkzeug ein Sub-Workflow. Prüfe die Übergabe mit einem Code-Node wie oben. Teste mit zehn echten Anfragen aus dem Postfach und notiere, wie oft der richtige Zweig gewählt wurde. Unter neun von zehn: Prompt des Koordinators nachschärfen, nicht die Spezialisten anfassen.

Tag 3: Den ersten Spezialisten produktiv setzen. Nimm den mit dem klarsten Ergebnis, meistens die Kalkulation, weil dort Rechnen und Prüfen getrennt werden können. Alle Zahlen in Code, das Modell wählt nur Positionen. Vergleiche zwanzig Ergebnisse von Hand mit dem alten Weg. Abweichungen sind hier keine Rundungsfehler, sondern Fehler in deiner Zerlegung.

Tag 4: Den zweiten und dritten Spezialisten anbinden. Jetzt erst, mit funktionierendem Koordinator und validierter Übergabe. Setze pro Spezialist maxIterations, Timeout und Fallback-Zweig. Ein Agent, der nicht antwortet, muss die Kette sauber beenden, nicht hängen lassen.

Tag 5: Messen statt hoffen. Lege drei Zahlen fest, die du wöchentlich ansiehst: Trefferquote der Zuordnung, Anteil der Läufe mit menschlicher Korrektur, Tokens pro Lauf. Dazu die Kosten pro erledigtem Vorgang, nicht pro Lauf, denn das ist die Zahl, die im Angebot am Ende zählt. Wenn diese vier Werte zwei Wochen stabil sind, hast du einen Betrieb und keinen Versuch.

Der dauerhafte Teil: Ein neuer Spezialist ist eine Erweiterung, kein Umbau. Genau darin liegt der eigentliche Gewinn. Du kannst den Recherche-Agenten gegen einen besseren austauschen, ohne den Text-Agenten anzufassen, und du kannst einen neuen Spezialisten für eine weitere Aufgabe dazunehmen, ohne den Prompt des Koordinators neu zu schreiben. Ein Monolith lässt das nicht zu, weil dort jede Änderung eine Änderung an allem ist. Wie sich diese Frage bei mehreren Agenten und mehreren Abteilungen entwickelt, steht in KI-Agenten für Unternehmen: was 2026 wirklich funktioniert.

Fazit

Der Alleskönner-Agent ist keine schlechte Idee, sondern eine Zwischenstufe. Am Anfang ist er der schnellste Weg zu einem Ergebnis, und das ist richtig so. Ab dem Moment, in dem er in den Betrieb geht, wird er zum Problem, weil Fähigkeiten, Kontext und Kosten in einem einzigen Prompt miteinander verrechnet werden, ohne dass jemand die Rechnung noch lesen kann.

Ein Koordinator mit drei Spezialisten löst das nicht, weil er moderner ist, sondern weil er die Dinge trennt, die getrennt gehört werden: Entscheiden, Rechnen, Formulieren. Jeder Teil ist einzeln prüfbar, einzeln änderbar und einzeln abschaltbar. Der Preis dafür ist ein Mehraufwand am Anfang, ungefähr ein Tag mehr als der Monolith gebraucht hat.

Wenn du wissen willst, wie weit dein aktueller Agent von diesem Aufbau entfernt ist: Wir sehen uns deine Agentenlandschaft mit dir an, zerlegen sie entlang dieser Linien und bauen die Kette so, dass sie auch in zwölf Monaten noch lesbar ist. Unser eigener Ansatz dafür steht unter B.R.A.I.N. KI-System, und wenn du die Umsetzung als Projekt brauchst, ist n8n-Agentur der nächste Schritt.

Über MadeByBrain: Wir bauen KI-Automatisierung für den Mittelstand, eigene AI-Agenten, n8n-Workflows und GEO-Strategien, live im Einsatz. Von der ersten Idee bis zur produktiven Automatisierung.

Jetzt kostenloses Strategiegespräch vereinbaren