Multi-Agent klingt besser, als es rechnet
Plus 90,2 Prozent Leistung, aber 15-fache Tokenmenge: wann sich mehrere KI-Agenten für ein KMU rechnen und wann ein einzelner die bessere Wahl ist.
Von Julian Ott, Managing Partner Technology bei Alpinity AI · Aktualisiert am 29. August 2026
Kurz gesagt: Mehrere zusammenarbeitende KI-Agenten können deutlich bessere Ergebnisse liefern als ein einzelner, kosten in derselben Messung aber rund fünfzehnmal so viele Tokens wie ein Chat. Für die meisten KMU-Aufgaben ist ein gut gebauter einzelner Agent die wirtschaftlichere Wahl. Multi-Agent lohnt sich dort, wo breit parallel gesucht wird.
Eine Zahl kursiert seit 2025 in fast jeder Präsentation zu KI-Agenten: plus 90,2 Prozent. So viel besser sei ein Multi-Agent-System gegenüber einem einzelnen Agenten.
Die Zahl stimmt. Sie stammt aus einem Bericht von Anthropic über das eigene Recherchesystem, und sie ist sauber dokumentiert.
Im selben Absatzbereich steht eine zweite Zahl. Die wird fast nie mitzitiert, und sie entscheidet, ob sich das Ganze für Ihr Unternehmen rechnet.
Die zweite Zahl aus derselben Quelle
Anthropic beschreibt den Aufbau offen: ein führender Agent auf Basis von Claude Opus 4, dazu Unteragenten auf Basis von Claude Sonnet 4. Dieses System übertraf einen einzelnen Claude-Opus-4-Agenten um 90,2 Prozent.
Und dann folgt die Einordnung: Agenten verbrauchen typischerweise etwa viermal so viele Tokens wie eine Chat-Interaktion, Multi-Agent-Systeme etwa fünfzehnmal so viele (Anthropic Engineering, 13. Juni 2025, Industriebericht).
Fünfzehnfache Tokenmenge bedeutet in erster Näherung fünfzehnfache Kosten pro Vorgang. Wer die 90,2 Prozent zitiert und die 15 weglässt, verkauft eine halbe Wahrheit.
Worauf sich die 90,2 Prozent überhaupt beziehen
Bevor Sie die Zahl auf Ihren Anwendungsfall übertragen, lohnt der Blick darauf, was gemessen wurde. Es ging um ein Recherchesystem, also um Aufgaben, bei denen viele Quellen gleichzeitig durchsucht und die Ergebnisse anschliessend zusammengeführt werden. Die Kennzahl für den Tokenanteil stammt aus einer Bewertung, die genau das misst: die Leistung eines browsenden Agenten.
Das ist der Idealfall für Parallelität. Zehn Unteragenten können zehn Quellen gleichzeitig lesen, und die Teilergebnisse stören sich nicht.
Die typische KMU-Automatisierung sieht anders aus. Eine Rechnung prüfen, einen Termin buchen, eine Offerte vorbereiten: Das sind Abläufe, bei denen Schritt zwei auf dem Ergebnis von Schritt eins aufbaut. Genau dort bringt Parallelität wenig und kostet trotzdem. Die 90,2 Prozent gelten für eine Aufgabenart, die den meisten KMU-Prozessen nicht ähnelt.
Der Gewinn kommt zu einem grossen Teil aus dem Budget, nicht aus der Cleverness
Noch aufschlussreicher ist ein dritter Satz aus demselben Bericht. In der verwendeten Bewertung erklärt allein der Tokenverbrauch 80 Prozent der Leistungsunterschiede.
Das relativiert die Architekturfrage erheblich. Ein grosser Teil dessen, was wie die Überlegenheit einer cleveren Mehr-Agenten-Struktur aussieht, ist schlicht die Wirkung eines grösseren Rechenbudgets. Mehrere Agenten sind eine bequeme Art, viel Budget auszugeben, aber sie sind nicht die einzige.
Die ehrliche Formulierung der Frage lautet deshalb nicht „ein Agent oder mehrere", sondern: Wie viel Budget ist diese Aufgabe wert, und wie gebe ich es am wirksamsten aus?
Wo lange Aufgabenketten wirklich brechen
Wer Agenten in Produktion betreibt, kennt das Muster: Bei drei Schritten läuft alles, bei fünfzehn wird es unzuverlässig. Eine Arbeit für die ICLR 2026 hat genau das isoliert und kommt zu einem präziseren Befund, als die verbreitete Erklärung nahelegt.
Nicht das Denken ist der Engpass, sondern das Ausführen. Kleinere Modelle erreichen bei einzelnen Schritten nahezu perfekte Genauigkeit und scheitern trotzdem, sobald dieselbe einfache Aufgabe verlängert wird. Dazu kommt ein Effekt, den die Autoren Selbstkonditionierung nennen: Modelle machen eher Fehler, wenn im Kontext bereits eigene Fehler aus früheren Schritten stehen (Sinha, Arun, Goel, Staab und Geiping, ICLR 2026, begutachtet).
Die gute Nachricht aus derselben Arbeit: Kleine Verbesserungen der Genauigkeit pro Schritt schlagen sich überproportional in der Länge der Aufgaben nieder, die ein Modell noch schafft. Kurze Vergleichstests verbergen diesen Fortschritt.
Für die Praxis folgt daraus eine unbequeme Konsequenz. Wenn ein Fehler im Kontext die Wahrscheinlichkeit weiterer Fehler erhöht, dann ist ein Agent, der seine gesamte Historie mitschleppt, schlechter als einer, der nach jedem abgeschlossenen Teilschritt aufräumt.
Wie Multi-Agent-Systeme konkret scheitern
Dass mehr Agenten mehr Fehlerquellen bedeuten, ist keine Vermutung. Eine Forschungsgruppe hat Protokolle aus sieben verbreiteten Multi-Agent-Frameworks ausgewertet und daraus eine Fehlertaxonomie gebaut. Sie umfasst 14 Fehlermuster in drei Kategorien, entstanden aus 150 von Fachleuten annotierten Protokollen und einem Datensatz von über 1’600 annotierten Verläufen, mit einer hohen Übereinstimmung zwischen den Annotierenden (Kappa 0,88) (Cemri et al., 2025, Preprint).
Kategorie | Was schiefgeht | Woran Sie es merken |
|---|---|---|
Design | Rollen unklar | Endlosschleifen |
Abstimmung | Agenten reden aneinander vorbei | Teile passen nicht |
Prüfung | Niemand prüft das Ergebnis | Falsches wirkt sauber |
Die dritte Kategorie ist die teuerste. Ein einzelner Agent, der irrt, produziert eine erkennbar dünne Antwort. Fünf Agenten, die sich gegenseitig bestätigen, produzieren ein gut strukturiertes Dokument mit einer falschen Kernaussage.
Was ein einzelner Agent zuerst ausschöpfen sollte
In den allermeisten Projekten, die als Multi-Agent-Anfrage bei uns starten, liegt das eigentliche Problem eine Ebene tiefer. Vier Hebel bringen fast immer mehr als eine zweite Agentenschicht, und alle vier sind billiger.
Der erste sind die Werkzeuge. Ein Agent, der eine präzise Abfrage gegen Ihr System stellen darf, statt sich eine Antwort aus Text zusammenzureimen, wird sofort zuverlässiger. Der zweite ist der Kontext: weniger, dafür das Richtige, und die entscheidende Stelle nicht in der Mitte.
Der dritte ist der Zuschnitt der Aufgabe. Ein Agent, der drei klar umrissene Dinge tut, schlägt einen, der alles können soll. Und der vierte ist die Prüfung: ein fester Schritt, der das Ergebnis gegen die ursprüngliche Anforderung hält, bevor es jemand zu sehen bekommt.
Erst wenn diese vier ausgereizt sind und die Messliste immer noch zu viele Fehlschläge zeigt, ist Parallelität die richtige Antwort.
Wann sich mehrere Agenten rechnen
Aus den Quellen lässt sich eine brauchbare Faustregel ableiten. Multi-Agent lohnt sich, wenn eine Aufgabe breit statt tief ist.
Die Aufgabe zerfällt in unabhängige Teile. Zwanzig Lieferanten prüfen, zehn Märkte vergleichen, fünfzig Dokumente einzeln auswerten. Solche Teile laufen parallel und stören sich nicht.
Das Ergebnis ist mehr wert als der Aufwand. Bei einer Marktrecherche, die sonst zwei Personentage kostet, ist die fünfzehnfache Tokenmenge nebensächlich. Bei einer Anfrage im Kundenservice ist sie ruinös.
Es gibt eine unabhängige Prüfung. Ohne einen Schritt, der das Gesamtergebnis gegen die ursprüngliche Frage hält, greift genau die dritte Fehlerkategorie.
Die Aufgabe läuft nicht in Echtzeit. Parallele Agenten brauchen Zeit. Für einen Chat, der in zwei Sekunden antworten soll, ist das Muster ungeeignet.
Umgekehrt gilt: Sequenzielle Abläufe mit klaren Regeln, also der Normalfall in einem KMU, laufen mit einem einzelnen, gut abgegrenzten Agenten stabiler und deutlich günstiger.
Der Kostenhebel, den kaum jemand nutzt
Bevor Sie über Architektur nachdenken, lohnt ein Blick auf die Abrechnung. Wiederkehrende Teile eines Prompts, etwa Systemanweisungen, Preislisten oder Handbuchauszüge, lassen sich zwischenspeichern.
Bei Anthropic kostet das Lesen aus dem Cache 0,1 mal den normalen Eingabepreis. Das Schreiben kostet 1,25 mal bei fünf Minuten Haltedauer und 2 mal bei einer Stunde, die Mindestlänge liegt bei Claude Sonnet 5 bei 1’024 Tokens (Anthropic, Entwicklerdokumentation, abgerufen am 29. August 2026).
Ein Rechenbeispiel mit einem wiederkehrenden Kontext von 20’000 Tokens über 1’000 Anfragen pro Tag, in Vielfachen des Eingabepreises für 1’000 Tokens:
Variante | Rechnung | Relative Kosten |
|---|---|---|
Ohne Cache | 1’000 x 20 x 1,0 | 20’000 |
Mit Cache, stündlich neu | 24 x 20 x 2,0 plus 1’000 x 20 x 0,1 | 2’960 |
Das sind rund 85 Prozent weniger, ohne eine einzige Änderung an der Architektur. Wer diesen Hebel nicht gezogen hat, sollte nicht über den Wechsel auf ein Multi-Agent-System diskutieren.
Warum Ihr Gefühl kein guter Massstab ist
Bei all diesen Entscheidungen gibt es eine Fehlerquelle, die selten benannt wird: die eigene Wahrnehmung. Das Forschungsinstitut METR hat sie in einer kontrollierten Studie gemessen.
16 erfahrene Entwickler bearbeiteten 246 echte Aufgaben in ihren eigenen Projekten, ein Teil davon mit KI-Werkzeugen. Vorher rechneten sie mit 24 Prozent Zeitersparnis. Tatsächlich brauchten sie mit den Werkzeugen 19 Prozent länger. Und nachher waren sie weiterhin überzeugt, 20 Prozent schneller gewesen zu sein (METR, 10. Juli 2025).
Das ist kein Argument gegen KI-Werkzeuge, und es lässt sich nicht ungeprüft auf andere Tätigkeiten übertragen. Es ist ein Argument gegen Bauchgefühl als Entscheidungsgrundlage. Wenn erfahrene Fachleute sich um fast 40 Prozentpunkte verschätzen, dann tut es Ihr Team bei der Frage, ob der neue Agentenaufbau etwas gebracht hat, ebenfalls.
So entscheiden wir bei Alpinity AI
Wir starten grundsätzlich mit einem einzelnen Agenten und einer Messliste aus echten Aufgaben. Erst wenn diese Messung zeigt, dass die Grenze erreicht ist, kommt Parallelität ins Spiel, und dann gezielt für den Teil, der sich wirklich aufteilen lässt.
Die Zeile abbruch_bei_schleife ist die praktisch wertvollste. Sie adressiert genau die erste Fehlerkategorie aus der Taxonomie, also Agenten, die ohne Fortschritt weiterlaufen und dabei Budget verbrennen.
Betrieben wird das mit Hosting in der Schweiz oder der EU, auf Wunsch ausschliesslich in der Schweiz, mit vollständiger Protokollierung jedes Werkzeugaufrufs.
Was gilt weiter, wenn die Modelle besser werden
Modelle werden zuverlässiger, und die machbare Aufgabenlänge wird wachsen, gerade weil kleine Genauigkeitsgewinne überproportional wirken. Drei Punkte bleiben davon unberührt.
Erstens bleibt jeder Token ein Kostenfaktor, und Parallelität vervielfacht ihn. Zweitens braucht jedes Ergebnis, das niemand prüft, eine Prüfinstanz, ob durch Menschen oder durch einen eigenen Schritt. Und drittens bleibt eine Messliste die einzige Möglichkeit, eine Verbesserung von einem Eindruck zu unterscheiden.
Die Architektur folgt der Aufgabe, nicht dem Trend. Das gilt auch dann noch, wenn die nächste Modellgeneration die hier genannten Zahlen überholt hat.
Quellen
Jeremy Hadfield, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, Daniel Ford: How we built our multi-agent research system. Anthropic Engineering, 13. Juni 2025, Industriebericht.
Mert Cemri, Melissa Z. Pan, Shuyi Yang et al.: Why Do Multi-Agent LLM Systems Fail? 2025, Preprint.
Akshit Sinha, Arvindh Arun, Shashwat Goel, Steffen Staab, Jonas Geiping: The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs. ICLR 2026, begutachtet.
METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 10. Juli 2025, randomisierte kontrollierte Studie.
Anthropic: Prompt caching. Entwicklerdokumentation, abgerufen am 29. August 2026.
Warum ein einzelner Agent oft schon am Kontext scheitert, bevor Parallelität überhaupt zur Frage wird, zeigt unser Beitrag Warum ein grösseres Kontextfenster Ihr RAG-Problem nicht löst.
Passende Leistung von Alpinity AI: Individuelle Softwareentwicklung
BLOGS
