Vom Einzelagenten zum Orchestrator

Subagenten, Agentenschwärme und koordinierte Arbeit.

Ein einzelner KI-Agent kann planen, recherchieren, schreiben, prüfen und Werkzeuge bedienen. Sobald mehrere Agenten gleichzeitig ins Spiel kommen, entsteht jedoch eine neue Klasse von Problemen. Die Frage lautet dann nicht mehr nur: Kann der Agent diese Aufgabe erledigen? Sie lautet: Wie teilen mehrere autonome Arbeitsinstanzen Verantwortung, Kontext, Zeit, Kosten und Entscheidungen so auf, dass aus Parallelität kein Chaos wird?

Genau hier beginnt Orchestrierung.

Multi-Agent-Systeme wirken auf den ersten Blick wie eine natürliche Steigerung: Wenn ein Agent hilfreich ist, müssten zehn Agenten zehnmal hilfreicher sein. In der Praxis ist das falsch. Mehr Agenten erhöhen zunächst nicht die Qualität, sondern die Zahl der möglichen Wechselwirkungen. Sie können dieselbe Recherche doppelt machen, unterschiedliche Versionen eines Dokuments verwenden, sich gegenseitig widersprechen, aufeinander warten, Kosten vervielfachen oder Fehler über mehrere Arbeitsschritte fortpflanzen.

Ein professionelles Multi-Agent-System braucht deshalb mehr als gute Einzelrollen. Es braucht eine Koordinationsarchitektur: Wer zerlegt die Aufgabe? Wer startet wen? Welcher Agent kennt welchen Kontext? Welche Arbeiten dürfen parallel laufen? Wo müssen Ergebnisse wieder zusammengeführt werden? Wie wird entschieden, welcher Befund gilt? Was passiert, wenn ein Teilagent scheitert, zu spät kommt oder eine unerwartete Richtung einschlägt? Und wann ist ein einzelner Agent schlicht die bessere Wahl?

Die zentrale These dieses Artikels lautet daher:

Der eigentliche Leistungssprung entsteht nicht durch mehr Agenten, sondern durch bessere Orchestrierung.

Mehr Agenten sind kein Qualitätsbeweis

Die intuitive Gleichung „mehr Agenten = mehr Intelligenz" verführt zu Überarchitektur. Ein System kann technisch beeindruckend aussehen und trotzdem schlechter funktionieren als ein sauber geführter Einzelagent.

Der Grund ist einfach: Jede zusätzliche Instanz erzeugt neue Koordinationskosten. Ein weiterer Agent benötigt einen Auftrag, Kontext, Rechte, ein Ausgabeformat, einen Rückgabekanal und eine Regel dafür, wie sein Ergebnis in den Gesamtzustand einfließt. Werden fünf Agenten parallel gestartet, entstehen nicht nur fünf Arbeitsstränge, sondern auch fünf mögliche Verzögerungen, fünf Fehlerquellen und mehrere mögliche Konflikte zwischen Ergebnissen.

Die entscheidende Frage ist deshalb nicht, wie viele Agenten verfügbar sind. Sie lautet:

Welche Teile der Aufgabe sind tatsächlich unabhängig genug, um getrennt bearbeitet zu werden, und wie werden ihre Ergebnisse anschließend zuverlässig wieder verbunden?

Das ist der Punkt, an dem Multi-Agent-Design von bloßem Agenten-Spawning getrennt werden muss.

Der Sprung von der Rolle zur Orchestrierung

Im vorherigen Artikel stand die einzelne Rolle im Mittelpunkt: Orchestrator, Spezialist, Reviewer, Dokumentation und menschliche Entscheidungshoheit. Diese Ebene beantwortet, wofür eine Instanz zuständig ist.

Orchestrierung beantwortet eine andere Frage: Wie bewegen sich Arbeit, Kontext und Kontrolle zwischen diesen Instanzen?

Eine Rolle kann hervorragend definiert sein und trotzdem in einem schlechten Multi-Agent-System landen. Ein Rechercheagent kann beispielsweise einen perfekten Rollenvertrag besitzen. Wenn er aber denselben Auftrag wie drei andere Agenten bekommt, mit einer veralteten Projektversion arbeitet oder sein Ergebnis nie in die finale Synthese gelangt, bleibt die Gesamtarchitektur schwach.

Multi-Agent-Orchestrierung ist deshalb keine Sammlung guter Prompts. Sie ist die Gestaltung eines Arbeitsflusses zwischen autonomen oder teilautonomen Komponenten.

Dabei werden mindestens fünf Dinge koordiniert:

Aufgabenfluss – welche Arbeit wandert wohin?

Kontextfluss – welche Informationen werden mitgegeben?

Kontrollfluss – wer entscheidet über den nächsten Schritt?

Zustandsfluss – welche Version gilt aktuell?

Evidenzfluss – wie werden Befunde, Quellen und Prüfungen weitergereicht?

Wer diese fünf Ströme nicht sichtbar macht, baut kein Multi-Agent-System, sondern mehrere gleichzeitig arbeitende Blackboxes.

Fünf Fragen vor jedem Multi-Agent-System

Bevor eine Architektur mehr als einen Agenten verwendet, sollte sie fünf Prüfungen bestehen.

Wenn mehrere dieser Fragen mit „nein" beantwortet werden, ist ein einzelner Agent mit guten Werkzeugen häufig überlegen.

Das ist kein Rückschritt. Es ist Architekturdisziplin.

Die Architekturkarte: Agenten als Graph

Eine nützliche Denkweise besteht darin, ein Multi-Agent-System als Graph zu betrachten. Die Agenten sind nicht einfach „Kollegen", sondern Knoten in einem Arbeitsnetz. Zwischen ihnen verlaufen Kanten, über die Aufgaben, Daten, Kontrolle oder Ergebnisse übertragen werden.

Knoten

Ein Knoten kann ein Agent, ein deterministischer Dienst, ein Reviewer, ein Datenzugriff oder ein menschlicher Entscheidungspunkt sein. Wichtig ist nicht die Bezeichnung, sondern die Funktion.

Kanten

Eine Kante beschreibt einen Übergang. Sie sollte mindestens klären, was übertragen wird, in welchem Format, welche Version gilt, wer den Übergang auslösen darf und was bei Fehlern passiert.

Zustand

Der Graph braucht zusätzlich einen nachvollziehbaren Projektzustand. Sonst können zwei Agenten gleichzeitig an unterschiedlichen Wahrheiten arbeiten. Ein System benötigt deshalb explizite Zustandsinformationen: Welche Aufgabe ist offen? Welche Version ist freigegeben? Welche Ergebnisse sind nur Entwurf? Welche Abhängigkeiten blockieren weitere Arbeit?

Diese Graphsicht macht einen entscheidenden Unterschied sichtbar: Multi-Agent-Orchestrierung ist nicht primär ein Modellproblem. Sie ist ein Zustands-, Schnittstellen- und Koordinationsproblem.

Muster 1: Manager und Subagenten

Das Manager-/Subagent-Muster ist eine der intuitivsten Architekturen. Eine zentrale Instanz behält den Gesamtauftrag, zerlegt ihn in Teilaufgaben, ruft spezialisierte Subagenten auf und synthetisiert deren Ergebnisse.

Der Manager ist dabei nicht zwangsläufig der fachlich beste Agent. Seine Aufgabe ist Koordination: Ziel und Gesamtzustand halten, Arbeit sinnvoll zerlegen, Aufgaben ohne unnötige Überschneidung vergeben, Ergebnisse zurücknehmen, Lücken und Konflikte erkennen, bei Bedarf neue Teilaufträge erzeugen und den finalen Output verantworten.

Dieses Muster ist besonders stark, wenn ein Gesamtprodukt eine einheitliche Stimme oder eine zentrale Ergebnisverantwortung braucht. Ein Fachbericht kann beispielsweise parallel durch Markt-, Technik-, Rechts- und Risikoagenten vorbereitet werden, während der Manager die Fragestellung und finale Synthese kontrolliert.

Die Schwäche liegt im Flaschenhals. Wenn jede Entscheidung, jeder Subagent und jedes Ergebnis über eine zentrale Instanz laufen muss, kann der Manager zum Engpass werden. Gleichzeitig entsteht ein Single Point of Failure: Versteht die zentrale Instanz das Ziel falsch, verteilt sie möglicherweise sehr effizient die falsche Arbeit.

Der Manager braucht deshalb nicht maximalen Kontext, sondern einen klaren Gesamtzustand plus gute Delegationsregeln.

Muster 2: Handoffs zwischen Spezialisten

Beim Handoff übergibt eine Instanz die aktive Verantwortung an eine andere. Das ist etwas anderes als ein Manager, der einen Spezialisten kurz als Werkzeug aufruft.

Ein typisches Beispiel:

Triage → Fachanalyse → Review → Abschluss

Die Triage erkennt den Fall und übergibt an den passenden Spezialisten. Dieser übernimmt die nächste Arbeitsphase und kann später an einen Reviewer oder eine andere Rolle weitergeben.

Handoffs sind besonders sinnvoll, wenn jede Phase einen eigenen Arbeitskontext und eigene Instruktionen benötigt. Sie reduzieren die Belastung einer zentralen Instanz und ermöglichen fokussierte Spezialagenten.

Doch Handoffs bergen ein klassisches Organisationsproblem: Verantwortungsverlust an der Übergabegrenze. Wenn nicht klar ist, was übergeben wurde, welche Annahmen gelten und welche offenen Punkte verbleiben, beginnt der nächste Agent mit einer unvollständigen Realität.

Darum darf ein Handoff nicht nur aus „Mach du weiter" bestehen. Er braucht einen strukturierten Übergabevertrag.

Muster 3: Sequentielle Kette

Nicht jede Multi-Agent-Architektur muss dynamisch sein. Eine einfache Kette kann sehr robust sein:

Recherche → Entwurf → Review → Revision → Dokumentation

Jede Instanz verarbeitet den Output der vorherigen und erzeugt einen klar definierten nächsten Zustand.

Die Vorteile sind hohe Nachvollziehbarkeit und geringe Koordinationskomplexität. Der Nachteil ist Latenz: Alles wartet auf den vorherigen Schritt. Außerdem kann ein früher Fehler durch die gesamte Kette getragen werden.

Sequentielle Ketten eignen sich deshalb besonders für Aufgaben mit klarer Abhängigkeit. Wenn der Reviewer den Entwurf benötigt, bevor er sinnvoll arbeiten kann, ist Parallelisierung künstlich.

Der wichtige Punkt lautet: Parallelität ist kein Qualitätsmerkmal. Wenn die fachliche Abhängigkeit sequenziell ist, sollte die Architektur das respektieren.

Muster 4: Parallelisierung mit Fan-out/Fan-in

Parallelisierung lohnt sich, wenn mehrere Teilaufgaben unabhängig voneinander bearbeitet werden können.

Beim Fan-out wird ein Gesamtproblem in mehrere parallele Stränge aufgeteilt. Beim Fan-in werden die Ergebnisse wieder gesammelt und zusammengeführt.

Beispiel einer Marktanalyse:

Agent A untersucht Kundensegmente, Agent B analysiert Wettbewerber, Agent C prüft regulatorische Rahmenbedingungen und Agent D untersucht technische Machbarkeit.

Alle vier können gleichzeitig arbeiten, sofern sie dieselbe Baseline kennen und nicht gegenseitig voneinander abhängig sind. Anschließend führt eine Syntheseinstanz die Resultate zusammen.

Der eigentliche Designaufwand steckt nicht im Fan-out, sondern im Fan-in. Dort müssen Widersprüche, unterschiedliche Detailgrade und konkurrierende Schlussfolgerungen behandelt werden.

Eine gute Parallelarchitektur definiert deshalb vor dem Start, wie Resultate später zusammengeführt werden.

Fan-in vor Fan-out planen

Viele Multi-Agent-Systeme werden vom sichtbaren Teil her entworfen: Zuerst entscheidet man, wie viele Agenten parallel arbeiten sollen. Erst später stellt sich die Frage, wie deren Ergebnisse wieder zu einem belastbaren Gesamtzustand werden. Genau diese Reihenfolge erzeugt Integrationsprobleme.

Professioneller ist die umgekehrte Denkweise: Fan-in vor Fan-out. Bevor ein paralleler Strang gestartet wird, muss feststehen, welche Art von Ergebnis er liefern soll und wie dieses Ergebnis später verglichen, kombiniert oder verworfen wird.

Dazu gehören vier Entscheidungen:

1. Gemeinsames Schema: Alle parallelen Agenten liefern Ergebnisse in kompatibler Struktur.

2. Gemeinsame Referenz: Sie arbeiten auf derselben freigegebenen Baseline und benennen Abweichungen ausdrücklich.

3. Integrationsregel: Schon vor dem Start ist klar, ob Resultate gemergt, gewichtet, gegengeprüft oder eskaliert werden.

4. Unvollständigkeitsregel: Ein fehlender oder verspäteter Strang darf nicht stillschweigend als „kein Befund" interpretiert werden.

Das ist besonders wichtig bei Recherche. Wenn vier Agenten jeweils freie Prosa liefern, muss der Syntheseagent zunächst die Struktur rekonstruieren. Wenn alle vier dagegen Behauptung, Evidenz, Unsicherheit, Quelle und Konsequenz getrennt ausgeben, wird die Synthese erheblich robuster.

Der scheinbar kleine Unterschied ist architektonisch groß: Der Fan-out produziert dann nicht einfach Texte, sondern komponierbare Arbeitsergebnisse.

Muster 5: Evaluator-Optimizer und Gegenprüfung

Ein starkes Muster besteht darin, Produktion und Bewertung absichtlich voneinander zu trennen.

Ein Agent erzeugt ein Ergebnis. Ein zweiter bewertet es gegen explizite Kriterien. Bei Abweichungen geht das Ergebnis zurück in eine Revisionsrunde. Dieser Zyklus läuft, bis die Kriterien erfüllt sind oder eine Stopbedingung erreicht wird.

Die gleiche Logik kann auf mehrere Systeme verteilt werden: Ein Modell erzeugt den Plan, ein anderes kritisiert die Struktur, ein drittes sucht Blindspots, anschließend konsolidiert eine Instanz die Befunde.

Der Mehrwert entsteht nicht automatisch durch verschiedene Modellnamen. Er entsteht durch unterschiedliche Prüffunktionen und möglichst unabhängige Perspektiven.

Wenn alle Agenten denselben Prompt, denselben Kontext und dieselben impliziten Annahmen erhalten, kann ein „KI-Deathmatch" spektakulär aussehen und trotzdem denselben Fehler vervielfachen.

Muster 6: Dynamischer Schwarm

Ein Schwarm geht über eine statisch definierte Agentenliste hinaus. Eine Instanz kann je nach Aufgabe weitere Agenten erzeugen, parallele Teilprobleme eröffnen und die Zahl der Arbeitsstränge dynamisch anpassen.

Das ist leistungsfähig, weil die Architektur nicht jeden Arbeitsschritt im Voraus kennen muss. Sie kann während der Bearbeitung neue Lücken erkennen und darauf reagieren.

Genau darin liegt aber auch das Risiko. Ohne Grenzen kann dynamisches Spawning aus einer kleinen Aufgabe sehr schnell Dutzende oder Hunderte Teilagenten erzeugen. Jeder davon verbraucht Kontext, Toolaufrufe und Rechenbudget. Außerdem steigt die Menge an Ergebnissen, die später bewertet und integriert werden muss.

Ein Schwarm braucht deshalb zwingend einen Spawn-Haushalt: maximale Zahl gleichzeitig aktiver Agenten, maximale Spawn-Tiefe, maximale Gesamtzahl von Teilaufträgen, Kosten- oder Tokenbudget, Zeitbudget und ein Abbruchkriterium bei sinkendem Grenznutzen.

Ohne diese Grenzen wird Autonomie mit Ressourcenverbrauch verwechselt.

Vertikal oder horizontal orchestrieren?

Eine besonders hilfreiche Unterscheidung ist die zwischen vertikaler und horizontaler Orchestrierung.

Vertikal bedeutet: Ein Hauptagent hält den Gesamtauftrag und ruft darunter kurzlebige Subagenten auf. Die Subagenten erledigen begrenzte Aufgaben und geben ihre Resultate zurück. Sie besitzen keinen dauerhaften eigenen Projektarbeitsraum.

Horizontal bedeutet: Mehrere Agenten oder Sessions arbeiten als eigenständige, länger laufende Arbeitsstränge. Jeder besitzt seinen eigenen Kontext, seine eigene Rolle und einen definierten Verantwortungsbereich. Beispielsweise kann ein Rechercheagent kontinuierlich Quellen pflegen, während ein Risikoagent dauerhaft Risiken bewertet und ein Delivery-Agent den Umsetzungsstand verfolgt.

Vertikale Orchestrierung ist leichter zu kontrollieren. Horizontale Orchestrierung skaliert Spezialisierung und Parallelität stärker, benötigt aber saubere Synchronisation.

Viele Projekte brauchen beides: einen zentralen Arbeitsstrang, der bei Bedarf Subagenten startet, plus einige dauerhaft getrennte Spezialkontexte.

Eine Reifeleiter für Orchestrierung

Nicht jedes Projekt sollte direkt die komplexeste Multi-Agent-Form verwenden. Sinnvoller ist eine Reifeleiter, bei der jede zusätzliche Stufe nur eingeführt wird, wenn die vorherige stabil funktioniert.

Diese Leiter ist keine Rangliste der Intelligenz. Stufe 1 kann für eine stark gekoppelte Aufgabe die professionellere Wahl sein als Stufe 5. Reife bedeutet daher nicht, möglichst viele Agenten einzusetzen, sondern die niedrigste Architekturkomplexität zu wählen, die den benötigten Arbeitsmodus zuverlässig trägt.

Das schützt auch vor einem häufigen Fehlanreiz: Teams bauen eine spektakuläre Agentenarchitektur, weil die Plattform sie technisch ermöglicht. Die eigentliche Aufgabe hätte jedoch mit einem Agenten, zwei Tools und einem Reviewer weniger fehleranfällig funktioniert.

Der Handoff-Vertrag

Sobald Arbeit zwischen Agenten wandert, braucht der Übergang ein festes Format. Ein minimaler Handoff kann so aussehen:

Dieser Vertrag verhindert zwei häufige Fehler: Context Dumping und Context Starvation.

Beim Context Dumping erhält der nächste Agent den gesamten Projektordner, obwohl nur fünf Prozent davon relevant sind. Beim Context Starvation bekommt er zu wenig und muss Annahmen erfinden.

Gute Handoffs transportieren daher nicht möglichst viel Kontext, sondern den kleinsten ausreichenden Kontext plus Hinweise darauf, wo weitere Informationen gefunden werden können.

Kontext ist kein gemeinsamer Datenmüll

Multi-Agent-Systeme benötigen eine bewusste Kontext-Topologie. Drei Grundformen sind besonders wichtig.

Gemeinsamer Zustand

Alle relevanten Agenten greifen auf einen kontrollierten gemeinsamen Projektzustand zu. Das ist sinnvoll für Baselines, freigegebene Entscheidungen und Versionen.

Isolierter Arbeitskontext

Ein Agent erhält nur den Ausschnitt, den er für seine Aufgabe braucht. Das reduziert Ablenkung und verhindert, dass vertrauliche oder irrelevante Daten unnötig verteilt werden.

Selektive Replikation

Bestimmte Informationen werden bewusst in mehrere Kontexte kopiert: Zieldefinition, Qualitätskriterien oder eine verbindliche Terminologie. Die Quelle und Version müssen dabei erkennbar bleiben.

Die falsche Architektur lautet: Alle sehen alles, jederzeit.

Das klingt kooperativ, erzeugt aber häufig Kontextüberlastung, Versionsunklarheit und schwer nachvollziehbare Entscheidungen.

Zustandsbesitz und Schreibkonflikte

Je mehr Agenten denselben Projektzustand verändern dürfen, desto wichtiger wird die Frage: Wer besitzt welche Wahrheit?

Ein gemeinsamer Ordner oder eine Datenbank löst das Problem nicht automatisch. Wenn zwei Agenten gleichzeitig dieselbe Spezifikation ändern, kann der zuletzt schreibende Agent die Änderung des ersten überschreiben. Wenn beide unterschiedliche Annahmen in getrennten Dateien festhalten, entsteht dagegen eine stille Verzweigung des Projekts.

Drei Muster helfen:

Single Writer: Für einen kritischen Zustand gibt es genau eine schreibberechtigte Instanz. Andere Agenten liefern Änderungsvorschläge. Das ist langsam, aber sehr robust.

Branch and Merge: Agenten arbeiten auf getrennten Zustandszweigen. Eine definierte Integrationsinstanz führt Änderungen später zusammen. Das erhöht Parallelität, benötigt aber Konfliktregeln.

Event Sourcing: Agenten verändern den Zustand nicht direkt, sondern erzeugen nachvollziehbare Ereignisse oder Änderungsanträge. Der aktuelle Zustand wird aus akzeptierten Ereignissen abgeleitet.

Für viele Wissens- und Projektmanagementsysteme reicht eine einfache Regel: Kritische Baselines sind read-only; Änderungen werden als Vorschlag erzeugt und erst nach Integration zur neuen Baseline. Dadurch wird vermieden, dass Parallelität unbemerkt die gemeinsame Wahrheit zerstört.

Parallelisieren heißt Abhängigkeiten verstehen

Bevor mehrere Agenten gleichzeitig starten, sollte die Aufgabe als Abhängigkeitsgraph betrachtet werden.

Wenn B den Output von A benötigt, können A und B nicht sinnvoll vollständig parallel laufen. Wenn C und D unabhängig sind, können sie parallelisiert werden. Wenn E beide Resultate benötigt, entsteht ein natürlicher Fan-in-Punkt.

Damit wird die zentrale Frage der Parallelisierung sehr konkret:

Welche Kante ist eine echte Abhängigkeit und welche nur Gewohnheit?

Gute Orchestrierung sucht nach unabhängigen Strängen, ohne künstlich Aufgaben zu zerlegen. Schlechte Orchestrierung parallelisiert alles und bezahlt anschließend die Synchronisationskosten.

Der Orchestrator braucht Budgets, nicht nur Ziele

Ein autonomer Manager, der nur ein Ziel erhält, kann theoretisch immer mehr Arbeit erzeugen. Professionelle Systeme geben deshalb nicht nur Zielvorgaben, sondern Ressourcenbudgets.

Budgets sind keine reine Kostensperre. Sie zwingen die Architektur, Prioritäten zu setzen.

Ein System, das innerhalb eines begrenzten Budgets gute Entscheidungen treffen kann, ist oft belastbarer als eines, das unendlich weiterarbeiten darf.

Spawn-Budget: Wie viele Agenten dürfen entstehen?

Die richtige Agentenzahl lässt sich nicht als universeller Wert festlegen. Sie hängt von Aufgabenbreite, Unabhängigkeit, Kontext, Kosten und Integrationsaufwand ab.

Eine brauchbare Heuristik lautet:

Starte mit der kleinsten Zahl von Agenten, die eine echte funktionale Trennung erzeugt. Erweitere erst, wenn ein konkreter Engpass oder eine klar unabhängige Teilaufgabe sichtbar wird.

Dynamisches Spawning sollte deshalb nicht mit „Erzeuge so viele Agenten wie nötig" freigegeben werden. Besser ist eine Regel wie:

Erzeuge einen zusätzlichen Agenten nur, wenn die neue Teilaufgabe ausreichend unabhängig ist, einen klaren Output besitzt, nicht bereits abgedeckt wird und der erwartete Mehrwert das verbleibende Budget rechtfertigt.

Der Schwarm wird damit von einem Spektakel zu einem kontrollierten Ressourcenmechanismus.

Backpressure: Wenn das System mehr Arbeit erzeugt, als es verarbeiten kann

Agentische Systeme können Arbeit schneller erzeugen, als Menschen oder nachgelagerte Agenten sie prüfen können. Das ist ein klassisches Backpressure-Problem: Der Output einer Stufe wächst schneller als die Verarbeitungskapazität der nächsten.

Das zeigt sich beispielsweise, wenn ein Recherchemanager zwanzig Subagenten startet, aber nur eine Syntheseinstanz deren Ergebnisse lesen kann. Die Recherche ist dann technisch schnell abgeschlossen, während der eigentliche Engpass erst danach entsteht. Mehr Parallelität verschiebt den Stau lediglich.

Ein Orchestrator sollte deshalb nicht nur Spawn-Limits kennen, sondern auch Kapazitätsgrenzen des Fan-ins. Sinnvolle Regeln sind etwa: neue Teilagenten erst starten, wenn genügend Integrationskapazität vorhanden ist, Ergebnisse priorisieren statt alles gleich tief zu prüfen, bei abnehmendem Erkenntnisgewinn weitere Exploration stoppen, Zwischenstände verdichten, bevor neue Stränge eröffnet werden, und bei überfüllten Warteschlangen neue Aufgaben zurückstellen.

Damit entsteht eine wichtige operative Kennzahl: marginaler Erkenntnisgewinn pro zusätzlichem Agenten. Wenn fünf weitere Agenten nur Varianten bereits bekannter Befunde liefern, ist Stoppen professioneller als vollständiges Ausschöpfen des Budgets.

Ergebnisse zusammenführen: Merge, Vote, Adjudication

Nach paralleler Arbeit stellt sich die schwierigste Frage: Wie werden verschiedene Ergebnisse zu einer Entscheidung?

Dafür gibt es mehrere Muster.

Merge: Nicht konkurrierende Informationen werden kombiniert. Gut bei komplementärer Recherche.

Vote: Mehrere Agenten geben eine Entscheidung ab, die Mehrheit gewinnt. Einfach, aber riskant, wenn alle dieselbe falsche Annahme teilen.

Adjudication: Ein unabhängiger Reviewer oder Manager bewertet konkurrierende Ergebnisse gegen Kriterien und Evidenz.

Evidence-weighted synthesis: Aussagen werden nicht nach Stimmen, sondern nach Quellenqualität, Tests und Nachweisstärke gewichtet.

Escalation: Wenn der Konflikt nicht zuverlässig lösbar ist, wird er bewusst als offene Entscheidung weitergegeben.

Je risikoreicher die Entscheidung, desto weniger sollte bloße Mehrheitslogik genügen.

Konsens ist kein Wahrheitsbeweis

Mehrere Agenten können sich einig sein und trotzdem falsch liegen. Das ist besonders wahrscheinlich, wenn sie dasselbe Basismodell, denselben Kontext und dieselben Quellen verwenden.

Multi-Agent-Systeme erzeugen deshalb nicht automatisch unabhängige Evidenz. Echte Gegenprüfung braucht Variation in mindestens einem relevanten Faktor: andere Quellen, andere Prüfkriterien, andere Rolle, anderer Modelltyp, andere Suchstrategie, andere Datenbasis oder einen deterministischen Test.

Die wichtigste Regel lautet:

Agentenpluralität ist nicht dasselbe wie Evidenzpluralität.

Wer zehn Instanzen desselben Fehlers abstimmen lässt, erhält nur sehr selbstbewussten Irrtum.

Straggler, Race Conditions und Kaskadenfehler

Sobald Agenten parallel arbeiten, tauchen Probleme aus verteilten Systemen auf.

Ein Straggler ist ein langsamer Teilagent, auf den der gesamte Fan-in wartet.

Eine Race Condition entsteht, wenn zwei Agenten gleichzeitig denselben Zustand verändern und die Reihenfolge das Ergebnis beeinflusst.

Ein staler Zustand entsteht, wenn ein Agent noch mit einer alten Version arbeitet, während andere bereits weiter sind.

Ein Kaskadenfehler entsteht, wenn ein falsches Zwischenergebnis an mehrere nachgelagerte Agenten verteilt wird und dort weitere Entscheidungen beeinflusst.

Ein zirkulärer Handoff entsteht, wenn Agent A an B übergibt, B an C und C wieder an A, ohne dass ein neuer Zustand erreicht wird.

Diese Fehler zeigen, warum Multi-Agent-Systeme nicht nur Prompt Engineering sind. Sie benötigen Mechanismen, die aus klassischer Software- und Prozessarchitektur bekannt sind: Versionierung, Idempotenz, Locks oder Schreibrechte, Zeitouts, Retries, Dead-Letter-Pfade und explizite Zustandsübergänge.

Fehlerdomänen isolieren

Ein Multi-Agent-System wird robuster, wenn Fehler nicht automatisch den gesamten Run kontaminieren. Dazu müssen Arbeitsstränge als Fehlerdomänen gedacht werden.

Ein Rechercheagent sollte beispielsweise nicht zugleich die finale Baseline überschreiben dürfen. Ein Code-Agent sollte nicht durch einen fehlgeschlagenen Test automatisch alle vorherigen Artefakte löschen. Ein fehlerhafter Spezialagent sollte nur die Ergebnisse ungültig machen, die tatsächlich von ihm abhängen.

Dafür braucht die Architektur drei Eigenschaften:

Begrenzte Schreibrechte: Fehler können nur einen kontrollierten Zustandsbereich verändern.

Abhängigkeitsnachweis: Nachgelagerte Ergebnisse kennen ihre wichtigsten Vorgängerartefakte.

Rollback-Punkte: Freigegebene Zustände können wiederhergestellt werden, ohne den gesamten Lauf neu zu beginnen.

Diese Isolation macht aus Fehlertoleranz mehr als einen Retry. Ein Retry wiederholt nur Arbeit. Eine gute Fehlerdomäne verhindert, dass ein lokaler Fehler zum Systemfehler wird.

Observability: Wer tat was, wann und warum?

Je mehr Agenten beteiligt sind, desto weniger genügt ein einzelner Chatverlauf als Nachweis.

Ein belastbares System sollte mindestens protokollieren: Run-ID und Task-ID, Parent-/Child-Beziehung zwischen Agenten, Agentenrolle und Version, gültigen Kontext- oder Datenstand, verwendete Tools, zentrale Zustandsänderungen, Ergebnisartefakte, Evidenz oder Tests, Kosten und Laufzeit sowie Abbruch- und Eskalationsgründe.

Observability dient nicht nur Debugging. Sie ermöglicht zu erkennen, warum ein System zu einem Ergebnis gekommen ist und an welcher Stelle eine Abweichung entstanden ist.

Bei einem Schwarm ist diese Rückverfolgbarkeit besonders wichtig. Sonst entsteht ein paradoxes System: Es arbeitet schneller als ein Mensch, aber niemand kann erklären, welche Teilinstanz welche Entscheidung beeinflusst hat.

Reproduzierbarkeit und Anpassungsfähigkeit austarieren

Orchestrierung steht in einem produktiven Spannungsverhältnis. Ein vollständig deterministischer Ablauf ist leicht reproduzierbar, kann aber schlecht auf neue Informationen reagieren. Ein vollständig dynamisches System kann sehr anpassungsfähig sein, ist aber schwerer zu testen und nachzuvollziehen.

Deshalb sollten nicht alle Ebenen gleich flexibel sein. Eine belastbare Architektur kann beispielsweise feste Zustands- und Handoff-Schemata verwenden, während die Auswahl eines Spezialagenten dynamisch bleibt. Sie kann harte Budgets definieren, aber innerhalb des Budgets freie Explorationspfade erlauben. Sie kann finale Schreibrechte zentralisieren, obwohl die Analyse dezentral erfolgt.

Das Ziel ist kontrollierte Variabilität: Dort dynamisch sein, wo Anpassung Mehrwert erzeugt, und dort deterministisch bleiben, wo Nachvollziehbarkeit, Sicherheit oder Wiederholbarkeit wichtiger sind.

Diese Trennung verbessert auch Evaluationen. Man kann dann unterscheiden, ob ein Fehler aus der kreativen Arbeitslogik eines Agenten stammt oder aus einer instabilen Koordinationsschnittstelle.

Kosten- und Tokenökonomie

Multi-Agent-Systeme skalieren nicht nur Arbeit, sondern auch Verbrauch.

Jeder zusätzliche Agent besitzt ein eigenes Kontextfenster, erzeugt eigene Tokens und ruft möglicherweise Werkzeuge auf. Parallelisierung kann die reale Laufzeit stark verkürzen und gleichzeitig den Gesamtverbrauch erhöhen.

Das ist kein Widerspruch. Schneller und billiger sind zwei verschiedene Optimierungsziele.

Eine Architektur sollte deshalb mindestens drei Größen getrennt messen:

1. Wall-Clock-Time: Wie lange wartet der Nutzer?

2. Compute-/Tokenkosten: Wie viel Gesamtarbeit wird erzeugt?

3. Qualitätsgewinn: Welche zusätzliche Evidenz, Abdeckung oder Zuverlässigkeit entsteht?

Erst das Verhältnis dieser drei Werte zeigt, ob Multi-Agent-Design wirtschaftlich sinnvoll ist.

Wann ein einzelner Agent besser ist

Ein einzelner Agent ist häufig die bessere Wahl, wenn die Aufgabe stark sequenziell ist, fast alle Schritte denselben Kontext benötigen, die Teilaufgaben eng voneinander abhängen, ein einheitlicher Denk- und Schreibprozess wichtiger ist als Perspektivenvielfalt, der Nutzen zusätzlicher Parallelität klein ist, die Kosten oder Latenz des Koordinierens den Mehrwert übersteigen oder die Evaluierung eines komplexen Systems schwieriger wäre als die Aufgabe selbst.

Die reifste Multi-Agent-Entscheidung kann deshalb lauten: Wir bauen keinen Multi-Agent-Workflow.

Ein Praxisbeispiel: strategischer Fachreport

Angenommen, ein Unternehmen benötigt einen belastbaren Entscheidungsreport zu einer neuen Produktidee.

Eine schlechte Architektur startet sofort zwanzig Agenten mit dem Auftrag „Analysiert alles".

Eine bessere Architektur beginnt mit einem Manager, der das Problem in vier weitgehend unabhängige Stränge zerlegt:

Markt-Agent: Nachfrage, Segmente, Wettbewerber.

Technik-Agent: Machbarkeit, Abhängigkeiten, Integrationsrisiken.

Regel-/Risiko-Agent: relevante Anforderungen, Unsicherheiten, Ausschlusskriterien.

Finanz-Agent: Kostenannahmen, Sensitivitäten, wirtschaftliche Risiken.

Diese vier Agenten erhalten dieselbe freigegebene Baseline, aber unterschiedliche Kontext-Slices und Outputs. Sie arbeiten parallel. Anschließend übernimmt ein Syntheseagent den Fan-in.

Der Syntheseagent darf Widersprüche nicht einfach glätten. Er erstellt eine Konfliktmatrix: Welche Aussagen widersprechen sich? Welche beruhen auf unterschiedlichen Annahmen? Welche benötigen zusätzliche Evidenz?

Bei zwei offenen Punkten werden gezielt neue Subagenten gestartet. Ein Reviewer prüft danach den Gesamtbericht gegen die ursprünglichen Entscheidungskriterien.

Das Ergebnis ist kein „Schwarm um des Schwarms willen", sondern eine adaptiv erweiterte Arbeitsarchitektur.

Das Orchestrierungs-Canvas

Für reale Projekte genügt eine kompakte Architekturkarte.

Ein gutes Canvas macht sichtbar, ob die Architektur wirklich durchdacht ist oder nur aus vielen Agentennamen besteht.

Sieben Stresstests vor dem Produktiveinsatz

Ein Multi-Agent-System sollte nicht nur im Idealfall getestet werden.

1. Duplikationstest: Zwei Agenten beginnen dieselbe Arbeit. Erkennt der Manager die Überschneidung?

2. Straggler-Test: Ein Agent liefert deutlich später. Blockiert der gesamte Run unnötig?

3. Konflikttest: Zwei Agenten liefern widersprüchliche, jeweils plausible Ergebnisse. Gibt es eine belastbare Entscheidungsregel?

4. Stale-State-Test: Ein Agent arbeitet mit einer veralteten Version. Wird das erkannt, bevor sein Ergebnis integriert wird?

5. Spawn-Test: Ein Agent möchte zehn weitere Agenten erzeugen. Greifen Budget- und Bedarfskriterien?

6. Kontextverlust-Test: Eine Übergabe enthält nicht alle notwendigen Informationen. Fragt der Empfänger nach oder halluziniert er die Lücke?

7. Kaskadentest: Ein frühes Zwischenergebnis ist falsch. Lässt sich erkennen, welche nachgelagerten Ergebnisse davon betroffen sind?

Diese Tests prüfen nicht die Eloquenz der Modelle. Sie prüfen die Robustheit der Koordination.

Ein Aufbaupfad in sieben Schritten

Wer Multi-Agent-Orchestrierung praktisch einführen möchte, sollte nicht mit einem Schwarm beginnen.

1. Einzelrollen stabilisieren. Jede Rolle muss Auftrag, Grenzen, Rechte und Output beherrschen.

2. Zwei Rollen sequentiell verbinden. Einen sauberen Handoff testen.

3. Einen Manager ergänzen. Delegation und Rückgabe sichtbar machen.

4. Zwei unabhängige Stränge parallelisieren. Erst wenn sie tatsächlich unabhängig sind.

5. Aggregation und Konfliktlösung definieren. Fan-in vor Fan-out designen.

6. Budgets, Observability und Fehlerpfade ergänzen. Erst jetzt wird die Architektur produktionsfähig.

7. Dynamisches Spawning nur bei nachgewiesenem Bedarf zulassen. Ein Schwarm ist die letzte Ausbaustufe, nicht der Startpunkt.

Dieser Aufbaupfad hält die Komplexität proportional zum Problem.

Fazit: Der eigentliche Agent ist das Koordinationssystem

Multi-Agent-Systeme verschieben den Engpass. Bei einem einzelnen Agenten fragt man, ob das Modell die Aufgabe bewältigen kann. Bei mehreren Agenten wird die entscheidende Frage, ob das System ihre Arbeit sinnvoll koordinieren kann.

Ein guter Manager zerlegt, ohne zu zersplittern. Ein guter Handoff übergibt ausreichend Kontext, ohne alles zu kopieren. Gute Parallelisierung nutzt echte Unabhängigkeit. Ein guter Schwarm wächst nur innerhalb klarer Budgets. Eine gute Synthese zählt nicht Stimmen, sondern Evidenz. Und gute Observability macht sichtbar, wie ein Ergebnis entstanden ist.

Die wichtigste Architekturregel lautet deshalb:

Erzeuge keine zusätzliche Agenteninstanz, wenn du nicht erklären kannst, welchen unabhängigen Wert sie liefert, wie sie eingebunden wird und wie ihr Ergebnis wieder aus dem System herauskommt.

Dann wird aus einer Gruppe von Modellen ein koordiniertes Arbeitssystem.

Im nächsten Schritt lässt sich diese technische Koordination auf eine organisatorische Frage erweitern: Wie verändert sich Zusammenarbeit, wenn Agenten nicht nur unter einem Manager hängen, sondern in stärker verteilten Rollen- und Entscheidungsstrukturen arbeiten? Dort beginnt die nächste Ebene der Serie.

Öffentliche Quellen zur Vertiefung