Multi-Agenten-Systeme: Wann ein Agent nicht reicht

Der ehrliche Normalfall ist ein Agent

Gehen Sie von Misstrauen aus: Die meisten Probleme, die als Multi-Agenten-System gebaut werden, sollten ein einzelner Agent mit einem guten Werkzeugkasten sein. Die Multi-Agenten-Variante gewinnt meist das Architekturdiagramm — sie sieht organisiert aus, sie bildet ab, wie ein menschliches Team die Arbeit aufteilen würde — und verliert dann in der Produktion, wo sie langsamer, teurer und deutlich schwerer zu debuggen ist als der einzelne Agent, den sie ersetzt hat.

Das ist kein Argument dagegen, überhaupt je aufzuteilen. Es ist ein Argument dafür, dass sich die Aufteilung ihren Platz verdienen muss. Ein zweiter Agent ist kein kostenloses Upgrade; er ist ein verteiltes System, mit dem gesamten Koordinationsaufwand, den dieser Begriff mit sich bringt. Wenn Ihnen die Bausteine noch neu sind — die Wahrnehmen-Entscheiden-Handeln-Schleife, Werkzeuge, Gedächtnis —, ist die Einführung zum einzelnen Agenten der bessere Startpunkt, denn alles hier setzt voraus, dass Sie bereits einen funktionierenden Agenten bauen können.

Warum ein zweiter Agent meist mehr kostet als bringt

Die Intuition, dass mehr Agenten mehr Leistungsfähigkeit bedeuten, ist aus zwei konkreten, messbaren Gründen verkehrt herum. Keiner davon dreht sich um Rechenkosten — es geht um Information und um Verlässlichkeit.

Die Grenze zwischen Agenten ist ein verlustbehafteter Kanal

Innerhalb eines Agenten liegt alles, was das Modell gesehen hat — die ursprüngliche Anfrage, die Werkzeug-Ergebnisse, der halbfertige Plan —, in einem gemeinsamen Kontext. Sobald Sie in zwei Agenten aufteilen, muss dieser gemeinsame Zustand durch eine Nachricht gepresst werden: Der eine Agent serialisiert das, was der nächste seiner Meinung nach braucht, in einen Absatz Text, und der empfangende Agent arbeitet mit diesem Absatz, nicht mit dem, was tatsächlich passiert ist. Jede Übergabe verliert Information — und schlimmer noch, sie verliert sie stillschweigend: Der zweite Agent hat keine Möglichkeit zu wissen, was weggelassen wurde. Ein Support-Agent, der „Kunde ist unzufrieden mit der Lieferung“ an einen Bearbeitungs-Agenten weitergibt, hat die Auftragsnummer, den Ton und die drei früheren Tickets weggeworfen, die die Antwort verändert hätten. Zwei Agenten, die ständig den vollen Kontext des jeweils anderen brauchen, sind ein einziger Agent in Verkleidung.

Fehler multiplizieren sich entlang der Kette

Verlässlichkeit multipliziert sich, und die Multiplikation von Zahlen unter eins kennt nur eine Richtung. Ist jeder Agent in einer linearen Pipeline solide zu 90 % verlässlich, liegt eine fünfstufige Kette bei 0,9⁵ ≈ 59 % — Sie haben aus lauter einzeln guten Teilen ein System gebaut, das in vier von zehn Fällen falsch liegt. Eine Stufe hinzuzufügen, um „die Qualität zu verbessern“, macht das schlimmer, nicht besser, es sei denn, diese Stufe entfernt Fehler, statt eine weitere Stelle zu sein, an der welche entstehen. Diese eine Tatsache erledigt leise die meisten „Fließband aus Agenten“-Entwürfe: Das Fließband ist nur so vertrauenswürdig wie das Produkt seiner Schritte — und Schritte sind billig hinzuzufügen und teuer zu prüfen.

Die drei Fälle, in denen Multi-Agenten wirklich gewinnen

Es gibt echte Gründe, zu mehr als einem Agenten zu greifen — aber es sind nur ungefähr drei, und sie sind strukturell, nicht organisatorisch. Keiner davon lautet „weil die Aufgabe mehrere Teile hat“. Ein einzelner Agent bewältigt mehrere Teile problemlos; dafür sind Werkzeuge da. Sie teilen auf, wenn die Struktur der Arbeit es verlangt.

Isolation: getrennter Kontext, getrennte Rechte

Der stärkste Grund zum Aufteilen ist eine Grenze, die ohnehin bestehen sollte. Angenommen, der Assistent eines Maschinenbauers beantwortet technische Fragen aus den Handbüchern und kann Garantiefälle ins ERP einbuchen. Diese beiden Aufgaben wollen Unterschiedliches: Die Frage-Antwort-Seite soll einen breiten Ausschnitt der Dokumentation sehen und nichts anfassen; die Garantieseite braucht Schreibrechte auf Finanzdaten und eine menschliche Freigabe. Beide in einem Agenten zu halten, bedeutet einen einzigen Wirkradius — ein per Prompt-Injection manipuliertes Handbuch könnte das ERP erreichen. Die Aufteilung zieht eine echte Wand zwischen eine schreibgeschützte Oberfläche mit geringem Vertrauen und eine hoch privilegierte, menschlich freigegebene Aktion. Hier geht es beim zweiten Agenten nicht um Leistungsfähigkeit, sondern um eine Sicherheitsgrenze — und die ist den Koordinationsaufwand wert.

Prüfung: ein Prüfer, der die Arbeit nicht gemacht hat

Die eine Aufteilung, die die Qualität verlässlich erhöht, ist ein Prüfer: ein zweiter Agent, dessen einzige Aufgabe es ist, die Ausgabe des ersten gegen die Quelle, das Schema oder die Regeln zu prüfen — und sie zurückzuschicken, wenn sie durchfällt. Das funktioniert, weil Modelle eine fertige Antwort deutlich besser beurteilen als erzeugen, und weil ein unabhängiger Prüfer den blinden Fleck des Erzeugers nicht teilt. Der Haken steckt im Wort „unabhängig“: Sieht der Prüfer denselben Kontext und teilt er denselben Fehlermechanismus, winkt er denselben Fehler bereitwillig durch. Und er hilft nur, wenn er tatsächlich ablehnen kann — ein Prüfer, der kommentiert, aber keine Neubearbeitung erzwingen kann, ist Dekoration. Das ist der nahe Verwandte dessen, wie Sie das System ohnehin offline evaluieren sollten; ein Prüf-Agent ist diese Disziplin, verlegt in die laufende Schleife.

Parallelität: wirklich unabhängige Arbeit zugleich

Besteht die Arbeit aus einer Menge Fälle, die nicht voneinander abhängen — 200 Verträge zusammenfassen, 50 Lieferanten gegen eine Liste prüfen —, ist es ein klarer Gewinn bei der Laufzeit, viele identische Agenten parallel laufen zu lassen. Das ist das sicherste Multi-Agenten-Muster, gerade weil es keine Übergabe gibt: Die Agenten reden nie miteinander, also gibt es keinen verlustbehafteten Kanal und keine sich multiplizierende Kette, nur ein Auffächern und ein Einsammeln. Beachten Sie: Das ist horizontal (dieselbe Aufgabe viele Male), nicht das vertikale „Team von Spezialisten“, das man sich üblicherweise vorstellt.

Die Muster, kurz

Ist eine Aufteilung gerechtfertigt, decken drei Koordinationsformen fast alles ab, und es lohnt sich, sie zu benennen, damit Sie bewusst wählen statt aus Gewohnheit.

Supervisor (Orchestrator–Worker). Ein Agent besitzt das Ziel und delegiert Teilaufgaben an Worker, während er den Gesamtplan hält. Das ist die flexibelste und zugleich fehleranfälligste Form: Der Supervisor ist eine einzelne Stelle, die falsch routen, in Schleifen geraten oder den Faden verlieren kann. Nutzen Sie sie, wenn die Aufgaben dynamisch sind und Sie die Schritte nicht im Voraus festlegen können.

Pipeline. Eine feste Abfolge — extrahieren, dann transformieren, dann schreiben —, in der jede Stufe eine Aufgabe hat. Vorhersehbar und leicht zu durchdenken, aber denken Sie an die Fehler-Multiplikation: Halten Sie die Kette kurz und setzen Sie ans Ende einen Prüfer, keine vierte Transformation. Die meisten Geschäftsabläufe, die nach Agenten aussehen, wollen eigentlich eine Pipeline — und oft eine schlichte, deterministische Pipeline mit einem Modell an einem Schritt, nicht Agenten an jedem Schritt.

Paralleles Auffächern. Das Muster der unabhängigen Fälle von oben. Am günstigsten zu bauen, am leichtesten zu vertrauen — und das, zu dem man zuletzt greift, weil es nicht raffiniert wirkt.

Der Preis, den Sie später spüren: das Debugging

Es gibt einen Preis, der im Design-Review nie auftaucht und den zweiten Produktionsmonat beherrscht. Bei einem Agenten lesen Sie, wenn etwas schiefgeht, ein Protokoll von oben bis unten und sehen die Überlegung, die den schlechten Schritt erzeugt hat. Bei fünf Agenten betreiben Sie Debugging verteilter Systeme: Der Fehler ist eine emergente Eigenschaft ihres Zusammenspiels, er lässt sich im nächsten Lauf womöglich nicht reproduzieren, und die irreführende Übergabe, die ihn verursacht hat, kann drei Agenten stromaufwärts von der Stelle liegen, an der der Fehler sichtbar wurde. Nichtdeterminismus, der bei einem Agenten bloß lästig ist, wird über mehrere hinweg wirklich schwer. Wenn Sie doch ein Multi-Agenten-System bauen, ist das Protokoll jeder einzelnen Übergabe nicht optional — es ist das Einzige, das Ihnen erlaubt, Ihr eigenes System zu verstehen, wenn es sich danebenbenimmt.

Das ist der wahre Grund, die Zahl klein zu halten. Nicht Reinheit und nicht der Preis pro Token — sondern dass Sie das Ganze nach dem Start betreiben, überwachen und reparieren müssen, und jeder Agent, den Sie hinzufügen, ein weiteres bewegliches Teil ist, das auf eine Weise ausfallen kann, die Sie nicht leicht sehen. Zwei Agenten mit einer klaren Grenze dazwischen sind ein System, das Sie im Kopf behalten können. Sieben verhandelnde Agenten sind es nicht.

Wo Tippel ins Spiel kommt

Der größte Wert in dieser Entscheidung liegt darin, die modische Antwort abzulehnen. Wenn ein Unternehmen uns nach „einem Multi-Agenten-System“ fragt, ist der nützliche erste Schritt meist, den einen Agenten zu finden, der sich in der Anfrage versteckt — die Variante mit guten Werkzeugen, einem engen Rechte-Rahmen und einem einzelnen Prüfer dort, wo er sich wirklich auszahlt — und Multi-Agenten nur dort zu bauen, wo eine echte Grenze es verlangt. Das ist meist günstiger zu bauen, günstiger zu betreiben und um zwei Uhr nachts noch zu debuggen.

Wenn Sie ein Agenten-Projekt abwägen und eine ehrliche Einschätzung möchten, ob es einen Agenten oder mehrere braucht — und wo die Grenzen wirklich verlaufen —, ist das genau die Art Frage, die der KI-Readiness-Check beantworten soll, oder Sie nehmen einfach Kontakt auf. So oder so sehen Sie in Leistungen & Pakete, wie wir über die umgebende Architektur denken.