Wer KI-Agenten in Entwicklungs- oder Geschäftsprozesse einbaut, trifft früh eine Architekturentscheidung: Soll ein Schwarm spezialisierter Subagenten die Arbeit untereinander aufteilen, oder übernimmt ein einzelner Hauptagent die Aufgabe und lädt sich die benötigten Informationen situativ dazu? Anthropic, Anbieter der Claude-Modelle, rät inzwischen zur zweiten Variante.
Die Empfehlung ist deshalb bemerkenswert, weil Multi-Agent-Setups in den vergangenen Monaten als naheliegende Antwort auf komplexe Aufgaben galten. Die Idee dahinter: Jeder Subagent bekommt ein enges Aufgabengebiet, einen eigenen Systemprompt und eigene Werkzeuge, ein übergeordneter Agent verteilt und sammelt ein. In der Praxis entsteht dabei jedoch ein verteiltes System mit allen bekannten Nebenwirkungen.
Was Anthropic empfiehlt
Anthropic rät Unternehmen, Multi-Agent-Architekturen zugunsten eines einzelnen Hauptagenten aufzugeben, der seinen Kontext bedarfsweise lädt. Kontext meint hier alles, was dem Sprachmodell zur Laufzeit mitgegeben wird: Anweisungen, Dokumente, Zwischenergebnisse, Werkzeugbeschreibungen. Statt dieses Wissen vorab auf mehrere spezialisierte Agenten zu verteilen, holt sich der eine Agent gezielt das, was für den aktuellen Arbeitsschritt nötig ist.
In einem von Anthropic beschriebenen Kundenfall habe der Umbau die Geschwindigkeit verdoppelt. Für die Umstellung stellt das Unternehmen ein Migrations-Kit auf der Entwicklungsplattform GitHub bereit, also eine Sammlung von Vorlagen und Hilfsmitteln, mit denen sich bestehende Multi-Agent-Aufbauten in eine Einzelagenten-Struktur überführen lassen.
Warum viele Agenten oft teurer sind als gedacht
Der Reiz von Subagenten liegt in der Arbeitsteilung. Der Preis dafür ist Koordination. Jede Übergabe zwischen Agenten erzeugt zusätzliche Modellaufrufe, zusätzliche Wartezeit und zusätzliche Stellen, an denen Information verloren gehen oder verfälscht werden kann. Was ein Subagent für wichtig hält, muss er dem nächsten in Textform zusammenfassen – und genau dieser Zwischenschritt ist fehleranfällig.
Dazu kommt die Beobachtbarkeit. Wenn ein Ergebnis nicht stimmt, muss nachvollziehbar sein, welcher Schritt dafür verantwortlich war. Bei einer Kette aus mehreren Agenten mit jeweils eigenem Gedächtnis ist diese Spurensuche deutlich aufwendiger als bei einem Ablauf, der in einem einzigen Kontext stattfindet. Für den Betrieb bedeutet das mehr Logging, mehr Tests und mehr Erklärungsbedarf gegenüber den Fachabteilungen.
Wann ein einzelner Agent reicht
Ein Hauptagent mit nachladbarem Kontext passt vor allem dort, wo Aufgaben zwar vielfältig, aber sequenziell sind: Anfragen qualifizieren, Dokumente auswerten, Daten aus mehreren Systemen zusammenführen, Code analysieren und anpassen. Entscheidend ist weniger die Zahl der Agenten als die Qualität der Werkzeuge, die dem Agenten zur Verfügung stehen, und die Präzision, mit der Informationen bereitgestellt werden.
Praktisch heißt das: klar beschriebene Schnittstellen, saubere Suchfunktionen auf den eigenen Datenbeständen und Werkzeuge, die kleine, überprüfbare Ergebnisse liefern. Ein Agent, der gezielt nachfragen kann, braucht keinen zweiten Agenten, der dasselbe Wissen dauerhaft vorhält.
Was das für laufende Projekte heißt
Für Unternehmen, die bereits mit Agenten arbeiten, lohnt eine nüchterne Bestandsaufnahme. Hilfreiche Leitfragen sind:
- Welche Subagenten existieren, und welche Aufgabe erfüllt jeder von ihnen nachweislich allein?
- Wie viele Modellaufrufe entfallen auf reine Koordination statt auf fachliche Arbeit?
- An welchen Übergabepunkten entstehen in der Praxis die meisten Fehler?
- Ließe sich derselbe Ablauf mit einem Agenten und besseren Werkzeugen abbilden?
Wer eine Vereinfachung erwägt, sollte sie wie jede Architekturänderung behandeln: mit einem definierten Vergleichsmaßstab. Ohne Messung von Laufzeit, Kosten pro Vorgang und Ergebnisqualität vor und nach dem Umbau bleibt jede Aussage über Verbesserungen eine Vermutung. Dass ein Anbieter ein Migrations-Kit bereitstellt, erspart Arbeit an der Mechanik, nicht die eigene Bewertung der Ergebnisse.
Einordnung
Die Empfehlung ist auch ein Hinweis darauf, wie jung das Feld noch ist: Muster, die vor Kurzem als Standard galten, werden vom Modellanbieter selbst relativiert. Für Entscheidungen in Unternehmen spricht das dafür, Agentenarchitekturen bewusst austauschbar zu halten und fachliche Logik nicht in der Verdrahtung zwischen Agenten zu vergraben.
Für Web- und Softwareprojekte bedeutet das konkret: Die einfachste Architektur, die den Anwendungsfall trägt, ist meist auch die, die sich betreiben, testen und erklären lässt. Statt Agenten zu vervielfachen, lohnt sich die Investition in gute Schnittstellen, saubere Datenzugriffe und eine nachvollziehbare Protokollierung – diese Bausteine bleiben auch dann nutzbar, wenn sich Modelle und Empfehlungen erneut ändern. Und jede Vereinfachung sollte an messbaren Größen wie Antwortzeit, Kosten pro Vorgang und Fehlerquote überprüft werden, nicht an der Zahl der beteiligten Komponenten.
