Multi-Agent oder Single-Agent: Wann sich mehrere KI-Agenten wirklich lohnen

Sobald ein einzelner KI-Agent erste Erfolge zeigt, taucht dieselbe Idee auf: mehrere Agenten, die zusammenarbeiten. Ein Planer, ein Rechercheur, ein Kritiker, vielleicht noch ein Koordinator darüber. Das Bild ist verführerisch, weil es aussieht wie ein eingespieltes Team. Die Frage, die dabei zu selten gestellt wird, lautet: Löst das Setup ein Problem, das der einzelne Agent tatsächlich hat.

Die Entscheidung Multi-Agent oder Single-Agent ist eine der teuersten frühen Weichenstellungen in einem Agentenprojekt, denn sie bestimmt Kostenprofil, Fehlerbild und Debugging-Aufwand für die gesamte Lebensdauer des Systems. Die ehrliche Ausgangsbasis: Ein einzelner Agent mit guten Tools und einem präzisen Prompt löst mehr Aufgaben, als die Architekturdiskussion vermuten lässt. Wer trotzdem teilt, sollte wissen, wofür er bezahlt.

Fehlerfortpflanzung: Ketten multiplizieren Schwächen

Jeder Agentenschritt kann schiefgehen: eine falsch verstandene Aufgabe, ein schlecht interpretiertes Tool-Ergebnis, eine zu selbstbewusste Zusammenfassung. In einer Kette von Agenten müssen alle Glieder gelingen, damit das Ergebnis stimmt. Kleine Schwächen einzelner Schritte summieren sich über die Kette, und zwar schneller, als das Organigramm der Agenten suggeriert.

Dazu kommt ein strukturelles Problem: Agenten übergeben einander komprimierte Zwischenstände. Der zweite Agent sieht nicht, was der erste gesehen hat, sondern nur dessen Zusammenfassung. Ein Missverständnis an einer Übergabestelle lässt sich später kaum noch korrigieren, weil der ursprüngliche Kontext fehlt. Ein einzelner Agent kann bei Zweifel zurückblättern. Eine Agentenkette kann das nicht.

Kosten: jede Übergabe kostet doppelt

Mehr Agenten heißen mehr Modellaufrufe, aber der eigentliche Kostentreiber ist subtiler: Kontext wird mehrfach transportiert. Jeder Agent braucht die Aufgabenbeschreibung, die relevanten Zwischenergebnisse und seine eigenen Instruktionen. Dieselbe Information läuft also mehrfach durch das Modell und wird mehrfach als Tokens bezahlt. Auch die Latenz addiert sich, denn die Agenten arbeiten in weiten Teilen nacheinander, nicht parallel.

Und die Orchestrierung selbst ist nicht gratis: Ein Koordinator-Agent, der Aufgaben verteilt und Ergebnisse einsammelt, verbraucht eigene Aufrufe, kann eigene Fehler machen und muss selbst überwacht werden. Wer die Kosten eines Mehr-Agenten-Setups schätzt, sollte den Overhead der Koordination mitrechnen, nicht nur die Facharbeit.

Kontextisolation: das eine wirklich starke Argument

Es gibt einen Fall, in dem die Trennung klar gewinnt: wenn eine Teilaufgabe viel Kontext verbraucht, der für den Rest des Laufs irrelevant ist. Eine Recherche über dutzende Dokumente füllt das Kontextfenster mit Material, von dem am Ende drei Absätze zählen. Erledigt ein Subagent diese Arbeit und liefert nur das Kondensat zurück, bleibt der Hauptagent fokussiert und sein Kontext sauber. Das ist Kontextisolation, und sie ist der belastbarste Grund für ein Mehr-Agenten-Setup.

Daneben gibt es einen zweiten legitimen Grund: unterschiedliche Berechtigungen. Ein Agent, der nur liest und analysiert, und ein getrennter Agent, der schreiben oder ausführen darf, bilden eine Sicherheitsgrenze ab, die sich in einem einzelnen Agenten nur schwer erzwingen lässt. Beide Gründe haben gemeinsam: Sie ergeben sich aus der Aufgabe, nicht aus der Vorstellung, dass Agenten wie menschliche Teams organisiert sein sollten.

Debugging: der unterschätzte Preis

Ein einzelner Agent erzeugt einen Trace, den man von oben nach unten lesen kann. Mehrere Agenten erzeugen ein verteiltes System aus nichtdeterministischen Komponenten. Wenn das Endergebnis falsch ist, beginnt die Suche: Welcher Agent hat den Fehler gemacht, war die Übergabe unvollständig, oder hat der Koordinator die Teilergebnisse falsch zusammengesetzt. Jede dieser Fragen erfordert Einblick in mehrere Läufe gleichzeitig.

Die praktische Konsequenz: Die Anforderungen an Observability steigen mit jedem zusätzlichen Agenten deutlich, und die Zeit pro Fehleranalyse wächst mit. Wer schon Mühe hat, das Verhalten eines einzelnen Agenten zu erklären, wird mit fünf Agenten nicht schneller, sondern langsamer. Das ist kein Argument gegen Multi-Agent-Systeme an sich, aber ein Kostenfaktor, der in Architekturdiskussionen fast immer fehlt.

Heuristiken für die Entscheidung vor dem ersten Commit

Aus der Praxis lassen sich einfache Regeln ableiten:

• Mit einem Agenten beginnen. Geteilt wird erst, wenn ein konkretes, benennbares Problem es verlangt, nicht vorsorglich.
• Entlang von Kontext teilen, nicht entlang von Rollen. Wenn die Begründung für einen Agenten wie eine Stellenbeschreibung klingt, ist das ein Warnsignal. Wenn sie lautet, dass eine Teilaufgabe das Kontextfenster flutet, ist sie tragfähig.
• Deterministisches wird Tool, nicht Agent. Was sich mit gewöhnlichem Code lösen lässt, braucht kein Modell und keine eigene Agentenrolle.
• Den Vorteil messen. Ein Mehr-Agenten-Setup muss sich in Evals gegen die Single-Agent-Variante beweisen: bessere Ergebnisse oder niedrigere Kosten. Zeigt sich beides nicht, wird zurückgebaut.

Fazit

Multi-Agent-Systeme sind weder Fortschritt an sich noch Unsinn an sich. Sie sind ein Tausch: Kontextisolation und Berechtigungsgrenzen gegen Fehlerfortpflanzung, höhere Kosten und deutlich schwierigeres Debugging. Für die meisten Aufgaben ist ein einzelner Agent mit guten Tools der bessere Startpunkt, und die Teilung folgt später einem konkreten Engpass statt einer Teammetapher. Wer die Entscheidung so trifft, vor dem ersten Commit und anhand messbarer Kriterien, erspart sich die teuerste Form von Architektur: die, die niemand mehr zurückbauen will.