2. April 2026

Multi-Agent-Orchestrierung: Realitaetscheck

Die Multi-Agent-Welle hat die Developer-Community erreicht. Frameworks wie Gas Town, Claude Flow und diverse Swarm-Tools versprechen, dass mehrere koordinierte Agenten komplexe Softwareprojekte besser bewerkstelligen als ein einzelner Agent. Die Begeisterung ist nachvollziehbar. Die Evidenz ist es weniger.

Die zentrale Fehleinschaetzung

Multi-Agent-Frameworks basieren auf einer verlockenden Intuition: Wenn ein Agent eine Aufgabe nicht schafft, koennten mehrere Agenten das Problem loesen, indem sie es aufteilen und parallel bearbeiten. Das klingt nach Arbeitsteilung, wie man sie aus menschlichen Teams kennt.

Das Problem: LLM-Agenten sind keine Menschen. Faehigkeiten, die das Basismodell nicht hat, lassen sich durch Scaffolding nicht erzwingen. Wenn ein einzelner Agent an einer Reasoning-Aufgabe scheitert, werden fuenf Agenten mit demselben Modell sie auch nicht loesen. Sie machen es nur teurer und unvorhersagbarer.

Scaffolding kann kompensieren -- Kontext bereitstellen, Aufgaben strukturieren, Rueckmeldungen geben. Aber es kann keine neuen Faehigkeiten herbeizaubern. Die Grenzen des Modells sind die Grenzen des Systems, egal wie viele Agenten darauf zugreifen.

Die konkreten Nachteile

Geringere Effizienz: Agent-Management kostet Rechenzeit. Supervisor-Agenten, die Aufgaben verteilen, Fortschritte pruefen und Ergebnisse zusammenfuehren, verbrauchen Tokens fuer Koordination statt fuer produktive Arbeit. Bei Gas Town berichten Nutzer von Supervisor-Agenten, die den Grossteil ihrer Zeit damit verbringen, Worker zu pingen und zu pruefen, ob jemand haengt.

Hoehere Kosten: Mehrere Agenten bedeuten mehrfache API-Kosten. Gas Town verbrennt laut Erfahrungsberichten rund 100 Dollar pro Stunde. Einzelne Nutzer berichten von ueber 200 Dollar monatlich allein fuer Claude-API-Kosten. Das ist kein Effizienzgewinn -- das ist der Tausch von Geld gegen Durchsatz, ohne Garantie fuer bessere Ergebnisse.

Mehr Fehlerquellen: Jeder zusaetzliche Agent ist eine zusaetzliche Fehlerquelle. Agenten koennen sich widersprechen, gegenseitig Aenderungen ueberschreiben oder auf inkonsistenten Zustaenden aufbauen. Gas Town hat Auto-Merge-Probleme dokumentiert, bei denen fehlschlagende Tests trotzdem zusammengefuehrt werden. Das ist nicht Parallelisierung. Das ist organisiertes Chaos.

Koordinationsoverhead: Die Ironie vieler Multi-Agent-Systeme: Sie rekonstruieren exakt die menschlichen Koordinationsprobleme, die sie eliminieren sollen. Sequenzielle Handoffs, Statusabfragen, Kontextverlust zwischen Agenten -- das sind die bekannten Reibungsverluste aus menschlichen Teams, nur schneller und teurer.

Die 19-Agenten-Falle

Ein besonders illustratives Anti-Pattern: Teams, die ihre bekannten Softwareentwicklungsprozesse (SDLC) eins zu eins auf Agenten abbilden. Ein Agent fuer Requirements, einer fuer Design, einer fuer Implementation, einer fuer Testing, einer fuer Review. Das Ergebnis sind 19 Agenten mit Persona-Prompts, die um Kontextfenster konkurrieren und Koordinationsfriktionen erzeugen, die kein Mensch so geplant haette.

Das ist kein intelligentes System-Design. Das ist Cargo-Cult-Engineering mit API-Kosten.

Was fehlt: Ehrliche Einordnung

Gas Town ist zwei Wochen alt. Claude Flow ist experimentell. Die meisten Multi-Agent-Frameworks sind Proof-of-Concepts, keine produktionsreifen Werkzeuge. Das ist voellig in Ordnung fuer Forschungsprojekte. Problematisch wird es, wenn diese Tools als produktionsreif vermarktet oder in aktive Workflows integriert werden.

Die Mehrheit der Engineering-Teams hat keinen Anlass, Agent-Orchestrierung jetzt einzufuehren. Fuer Teams unter zehn Entwicklern frisst der Koordinationsoverhead jeden theoretischen Gewinn auf. Es gibt nicht genug parallelisierbare Arbeit, um die Komplexitaet zu rechtfertigen.

Was stattdessen funktioniert

Wer mit AI-Agents produktiv arbeiten will, ist mit einem gut konfigurierten Einzelagenten besser bedient als mit fuenf schlecht koordinierten. Die Hebel liegen nicht in der Anzahl der Agenten, sondern in der Qualitaet der Architektur -- ein Punkt, den wir im Artikel Architektur statt Code ausfuehrlich beleuchtet haben.

Die praktischen Empfehlungen bleiben dieselben: Klare Constraints, dokumentiertes Wissen, gute Testabdeckung und isolierte Execution-Umgebungen. Ein Agent, der in einer durchdachten Architektur arbeitet, schlaegt ein Rudel Agenten in einem unstrukturierten Projekt.

Die richtige Haltung

Multi-Agent-Orchestrierung ist ein spannendes Forschungsfeld. Gas Town, Claude Flow und vergleichbare Projekte auszuprobieren und daraus zu lernen, ist sinnvoll. Sie in aktive Workflows oder kommerzielle Software zu integrieren, ist es zum jetzigen Zeitpunkt nicht.

Die Richtung stimmt moeglicherweise. Die Ausfuehrung ist noch nicht da. Und die Kosten-Nutzen-Rechnung geht fuer die allermeisten Anwendungsfaelle nicht auf.

Quellen

Nach oben