Warum ein Agent selten reicht: Multi-Agent-Systeme richtig bauen

Ein Agent, der alles kann — und genau daran scheitert

Wenn man zum ersten Mal einen KI-Agenten baut, ist der Reflex immer derselbe: Man macht ihn fähiger. Noch ein Tool, damit er auch Dateien schreiben kann. Noch ein Abschnitt im System-Prompt, der den Sonderfall von letzter Woche abfängt. Noch ein Satz Instruktionen, weil er in einem Randfall danebenlag. Der Agent wird größer, klüger, universeller — und eine Weile funktioniert das auch erstaunlich gut.

Dann kippt es. Ab einem bestimmten Punkt macht mehr den Agenten nicht besser, sondern schlechter. Er verliert mitten in der Aufgabe den Faden, was er eigentlich sollte. Er greift zum falschen von seinen dreißig Tools. Er dreht Schleifen, ruft dieselbe Suche dreimal auf, widerspricht sich zwischen zwei Schritten. Der naheliegende Reflex ist, noch mehr Instruktionen nachzulegen — und genau das verschlimmert das Problem, statt es zu lösen.

Die Antwort ist nicht ein klügerer Einzelagent. Sie ist ein System aus mehreren. Nicht, weil viele Agenten intrinsisch besser wären als einer — das sind sie nicht, dazu später —, sondern weil ein einzelner Kontext und ein einzelner Prompt eine reale, physikalische Decke haben. Wer diese Decke kennt, versteht, warum Orchestrierung kein Buzzword ist, sondern eine Architekturentscheidung.

Warum ein einzelner Agent an eine Decke stößt

Die Decke hat drei Ursachen, und alle drei liegen im Kontextfenster — dem Arbeitsspeicher, in dem der Agent seine gesamte Aufgabe, seine Tools und seine bisherige Historie mit sich trägt.

Erstens: Das Kontextfenster füllt sich mit Ballast. Jedes Tool, das ein Agent kennt, kostet Platz — nicht nur beim Aufruf, sondern permanent. Die vollständige Definition jedes Tools, mit Parametern, Beschreibungen und Beispielen, steht bei jedem einzelnen Denkschritt im Kontext, ob das Tool gerade gebraucht wird oder nicht. Ein Agent mit fünf Tools trägt eine schlanke Werkzeugkiste. Ein Agent mit dreißig Tools trägt einen Baumarkt mit sich herum, und in neun von zehn Schritten sind neunundzwanzig davon irrelevant. Dieser Ballast konkurriert mit der eigentlichen Aufgabe um Aufmerksamkeit — und das Modell muss bei jedem Schritt aus dreißig plausiblen Optionen die eine richtige herausfischen. Die Fehlerrate steigt genau dort, wo die Auswahl am größten ist.

Zweitens: Reasoning degradiert mit wachsender Historie. Ein Modell denkt nicht gleich gut über einen Kontext von 5.000 Tokens wie über einen von 150.000. Je länger die Historie — jeder frühere Tool-Aufruf, jede Zwischenausgabe, jeder Fehlversuch —, desto mehr Rauschen liegt zwischen der aktuellen Frage und den Informationen, die sie beantworten. Das Modell verliert frühe Anweisungen aus dem Blick, überschreibt eigene Schlussfolgerungen, verheddert sich in Widersprüchen zwischen Schritt drei und Schritt siebzehn. Für dieses Phänomen hat sich ein treffender Begriff eingebürgert: „context rot" — der langsame Verfall der Antwortqualität, während der Kontext voller und unübersichtlicher wird.

Drittens: Ein Prompt versucht, alles zu sein. Ein Alleskönner-Agent braucht einen System-Prompt, der recherchieren und Code schreiben und Datenbanken abfragen und mit dem Nutzer verhandeln kann. Jede dieser Rollen zieht den Prompt in eine andere Richtung. Die Instruktionen für sauberes Recherchieren stehen neben denen für vorsichtiges Schreiben, und das Modell muss in jedem Moment selbst entscheiden, welcher Hut gerade gilt. Das Ergebnis ist ein Prompt, der alles halb kann und nichts ganz — der Generalist, der überall passabel und nirgends exzellent ist.

Diese drei Effekte verstärken sich gegenseitig. Mehr Tools heißt mehr Kontext, heißt schnelleres Rot, heißt schlechtere Entscheidungen, heißt mehr Fehlversuche, heißt noch mehr Kontext. Man kann sich aus diesem Kreis nicht heraus-prompten. Man muss ihn zerschneiden.

Muster, die funktionieren

Der Ausweg ist immer dieselbe Grundidee: Zerlege die Aufgabe, und gib jedem Teil einen eigenen, frischen, engen Kontext. Wie man das konkret tut, folgt einigen bewährten Mustern.

Orchestrator und Worker. Ein zentraler Agent — der Orchestrator — hält den Überblick über das Ziel und die Strategie, führt aber selbst kaum Detailarbeit aus. Er zerlegt die Aufgabe und delegiert die Teile an Worker-Agenten, von denen jeder genau einen Auftrag bekommt, ihn in seinem eigenen Kontext erledigt und nur das Ergebnis zurückmeldet. Der Orchestrator sieht nie die 40.000 Tokens, die der Worker beim Durchsuchen von zwölf Dateien produziert hat — er bekommt die drei Sätze Schlussfolgerung. Genau so funktionieren die Sub-Agenten von Claude Code: Über das Task-Tool startet der Hauptagent einen Unteragenten, der eine abgegrenzte Recherche in einem isolierten Kontext durchführt und nur die Essenz zurückgibt. Der Hauptkontext bleibt sauber, egal wie viel der Unteragent wühlen musste.

Planer, Ausführer, Prüfer. Statt einen Agenten planen und handeln und kontrollieren zu lassen, trennt man die drei Phasen in drei Rollen. Ein Planer-Agent überlegt, was zu tun ist, und schreibt einen expliziten Plan. Ein Ausführer-Agent bekommt diesen Plan und setzt ihn Schritt für Schritt um, ohne die Strategie ständig neu zu verhandeln. Ein Prüfer-Agent nimmt das Ergebnis und fragt: Stimmt das? Der Vorteil ist nicht nur sauberer Kontext, sondern dass jede Rolle einen anderen Denkmodus verkörpert — divergent beim Planen, fokussiert beim Ausführen, skeptisch beim Prüfen. Ein einzelner Agent müsste zwischen diesen Modi in derselben Kopfhaltung springen, und das gelingt selten.

Spezialagenten mit engem Tool-Set. Ein Agent, der nur die Datenbank abfragt, braucht drei Tools, nicht dreißig. Sein Prompt kann sich ganz dem sauberen Umgang mit SQL widmen. Ein Agent, der nur Pull Requests reviewt, braucht kein Deployment-Tool. Je enger die Rolle, desto kürzer der Prompt, desto kleiner die Werkzeugkiste, desto treffsicherer die Auswahl. Man tauscht Vielseitigkeit gegen Verlässlichkeit — und für die meisten Teilaufgaben ist das ein guter Tausch.

Isolierte Sub-Kontexte als Map-Reduce. Das vielleicht stärkste Muster: Wenn eine Aufgabe über eine große Menge gleichartiger Dinge läuft — durchsuche diese Codebasis, prüfe diese zweihundert Dokumente, analysiere diese fünfzig Endpunkte —, verteilt man sie auf viele parallele Unteragenten, von denen jeder ein Stück bearbeitet und nur seine Schlussfolgerung zurückgibt. Kein einzelner Kontext sieht je die gesamte Codebasis; er sieht nur die verdichteten Befunde. Genau dieses Muster beschreibt Anthropic in seinen Berichten zum Multi-Agent-Research-System: Ein Lead-Agent zerlegt eine offene Recherchefrage und startet mehrere Subagenten, die parallel unterschiedliche Stränge verfolgen. Jeder Subagent hat sein eigenes Kontextfenster und komprimiert seine Funde, bevor er sie zurückgibt. Der Lead-Agent synthetisiert aus den Verdichtungen die Antwort — und musste nie die Rohmenge aller durchsuchten Quellen gleichzeitig im Kopf halten.

Allen Mustern gemeinsam ist ein Prinzip: Kontext-Isolation ist das eigentliche Produkt. Nicht die Zahl der Agenten macht das System besser, sondern dass jeder Agent nur das sieht, was er für seinen engen Job braucht.

Das Übergabe-Problem

Sobald man Arbeit auf mehrere Agenten verteilt, entsteht ein neues Problem, das es beim Einzelagenten gar nicht gab: die Übergabe. Was genau reicht ein Agent an den nächsten weiter — und in welcher Form?

Der bequeme, aber gefährliche Weg ist Freitext. Agent A schreibt in Prosa auf, was er herausgefunden hat, Agent B liest es und macht weiter. Das funktioniert in einfachen Fällen und versagt in genau dem Moment, in dem es darauf ankommt. Denn Freitext ist mehrdeutig. Wenn Agent A schreibt „die Zahlung war erfolgreich, bis auf einen Fall", muss Agent B raten, welcher Fall, ob er relevant ist, was „erfolgreich" hier heißt. Über mehrere Übergaben hinweg wird aus dieser Mehrdeutigkeit ein „Stille Post"-Versagen: Jeder Agent interpretiert die leicht unscharfe Ausgabe des vorigen ein bisschen um, und nach vier Stationen bearbeitet der letzte Agent eine Aufgabe, die mit der ursprünglichen nur noch entfernt verwandt ist. Niemand hat gelogen; jeder hat nur minimal umgedeutet. Das Ergebnis ist trotzdem falsch.

Die Gegenmaßnahme ist unspektakulär und wirksam: strukturierte Ausgaben statt Freitext. Man definiert ein Schema — welche Felder eine Übergabe enthalten muss, in welchem Format, mit welchen erlaubten Werten — und zwingt jeden Agenten, seine Ergebnisse genau in dieser Form zu liefern. Statt „die Zahlung war meistens erfolgreich" gibt der Agent { "status": "partial", "erfolgreich": 199, "fehlgeschlagen": 1, "fehler_id": "txn_88231" } zurück. Der nächste Agent muss nichts interpretieren; er liest Felder. Ein Schema erzwingt außerdem Vollständigkeit: Fehlt ein Pflichtfeld, fällt das sofort auf, statt sich als stille Lücke durch die Kette zu fressen. Die Übergabe wird von einer Erzählung zu einem Vertrag — und Verträge sind das, worauf man ein System bauen kann.

Verifikation als eigener Agent

Es gibt eine Rolle, die fast jedes ernsthafte Multi-Agent-System braucht und die trotzdem oft vergessen wird: den Prüfer. Nicht als Höflichkeit, sondern als eigenständiger, adversarialer Agent, dessen einziger Job es ist, die Arbeit der anderen zu widerlegen.

Der Grund ist strukturell. Ein Agent, der eine Lösung produziert hat, ist der schlechteste Prüfer dieser Lösung — er teilt jede Annahme, die ihn in den Fehler geführt hat, und er ist darauf konditioniert, die eigene Ausgabe für plausibel zu halten. Bittet man denselben Agenten „prüf das nochmal", nickt er meist seine eigene Arbeit ab. Ein separater Prüfer-Agent mit einem gegensätzlichen Auftrag — „finde den Fehler, nimm an, dass hier einer ist" — geht mit anderer Voreinstellung heran. Er sucht die leere Liste, den nicht behandelten Fehlerpfad, die Annahme, die nicht hält. Er bekommt die Aufgabe und das Ergebnis und darf beides anzweifeln.

Das ist keine Garantie — ein KI-Prüfer teilt einige blinde Flecken mit dem KI-Produzenten, und zwei grüne Häkchen sind nicht doppelt so sicher wie eines. Aber ein Agent mit adversarialem Auftrag und frischem Kontext fängt eine ganze Klasse von Fehlern, die der Produzent strukturell nicht sehen kann. Die Trennung von Erzeugen und Prüfen in zwei Rollen ist einer der billigsten Qualitätsgewinne, die ein Multi-Agent-Design zu bieten hat.

Die andere Seite: Multi-Agent ist nicht gratis

Jetzt die ehrliche Gegenrechnung, denn ohne sie zieht man die Lehre viel zu weit. Multi-Agent-Systeme lösen die Decke des Einzelagenten — aber sie tun das nicht umsonst, und in vielen Fällen ist der Preis höher als der Gewinn.

Die Token-Kosten vervielfachen sich. Jeder Agent hat seinen eigenen System-Prompt, seine eigene Toolliste, seine eigene Historie — und all das wird bei jedem Schritt erneut verarbeitet. In Anthropics eigenen Messungen verbraucht ein Agenten-Lauf rund das Vierfache an Tokens einer normalen Chat-Interaktion, und ein Multi-Agent-System rund das Fünfzehnfache. Was als Chat-Anfrage 2 € kostet, kostet als orchestrierter Multi-Agent-Lauf schnell 30 €. Für Aufgaben mit echtem Wert ist das gut investiert. Für eine simple Umformatierung ist es Verbrennung.

Koordination kostet Overhead — und geht schief. Agenten, die zusammenarbeiten sollen, verheddern sich auf Weisen, die ein Einzelagent gar nicht kann. Zwei Worker bearbeiten dieselbe Teilaufgabe, weil der Orchestrator sie doppelt vergeben hat. Ein Agent wartet auf ein Ergebnis, das nie kommt. Zwei Agenten geraten in eine Schleife, in der jeder auf die Korrektur des anderen reagiert. Diese Fehlermodi entstehen erst durch die Verteilung — der Einzelagent hat sie schlicht nicht.

Latenz und Debugging werden schlechter. Ein Multi-Agent-Lauf ist so langsam wie seine langsamste Kette, und wenn am Ende etwas Falsches herauskommt, ist die Ursachensuche ungleich härter: War es der Planer, ein Worker, die Übergabe dazwischen? Der Nicht-Determinismus verschärft das — derselbe Input führt über mehrere probabilistische Agenten hinweg zu unterschiedlichen Läufen, und ein Fehler, der nur bei jedem fünften Durchlauf auftritt, ist die Hölle zu reproduzieren.

Die nüchterne Konsequenz: „Mehr Agenten" ist nicht „besser". Die meisten Aufgaben erledigt ein einziger, gut zugeschnittener Agent schneller, billiger und verlässlicher. Multi-Agent lohnt sich nur, wenn die Aufgabe sich echt zerlegen lässt und die Teilaufgaben unabhängig sind — parallele Recherche über viele Quellen, Map-Reduce über eine große Codebasis, klar getrennte Phasen mit sauberer Übergabe dazwischen. Lässt sich eine Aufgabe nicht sinnvoll aufteilen, fügt jeder zusätzliche Agent nur Koordinationskosten hinzu, ohne die Decke zu heben, an der es eigentlich klemmt. Die Kunst ist nicht, möglichst viele Agenten zu bauen, sondern zu erkennen, wann einer die richtige Antwort ist.

Fazit

Der Reflex, einen Agenten immer fähiger zu machen, ist verständlich und bis zu einem Punkt richtig. Jenseits dieses Punktes kehrt er sich um: Mehr Tools, mehr Instruktionen, mehr Kontext machen den Agenten nicht klüger, sondern zerstreuter. Die Decke des Einzelagenten ist keine Frage besserer Prompts, sondern eine strukturelle Grenze — und man überwindet sie nicht mit einem genialeren Prompt, sondern mit einem durchdachten System: spezialisierte Agenten mit engen Rollen, isolierte Kontexte, strukturierte Übergaben, ein eigener Prüfer.

Aber der Bau eines solchen Systems ist eine Entwurfsaufgabe, keine Zauberformel. Wer Multi-Agent als Selbstzweck betreibt, kauft sich Token-Kosten, Latenz und Nicht-Determinismus ein, ohne den Gewinn dafür zu bekommen. Die schwierige, wertvolle Arbeit liegt nicht im Bauen vieler Agenten, sondern in der Entscheidung, wo die Zerlegung echt trägt und wo ein einzelner Agent die ehrlichere Antwort ist.

Genau hier liegt unser Anspruch bei NH Labs. Wir bauen Agenten-Systeme, in denen jeder Agent einen engen, klar umrissenen Job hat — und in denen ein Mensch das Orchestrierungs-Design verantwortet: Er entscheidet, was zerlegt wird und was nicht, wie die Übergaben aussehen und wo ein Prüfer nötig ist. Nicht möglichst viele Agenten, sondern die richtigen, sauber verschaltet. Deshalb funktionieren unsere Systeme nicht, weil sie komplex sind, sondern weil jeder Teil davon einfach genug ist, um verlässlich zu sein.