Mehr Agenten machen noch kein Team

Ein Team entsteht nicht durch zusätzliche Stimmen, sondern durch komplementäre Fähigkeiten, klare Zuständigkeiten und eine überprüfbare Integration.

Die Idee wirkt unmittelbar plausibel: Wenn ein Sprachmodell hilfreich ist, müssten fünf spezialisierte Modelle noch hilfreicher sein. Eines recherchiert, eines plant, eines schreibt, eines prüft und ein weiteres entscheidet, was als Nächstes geschieht. Auf dem Papier erinnert das an eine gut organisierte Fachgruppe. In der Praxis kann daraus ebenso leicht ein Kreisgespräch entstehen, das dieselben Annahmen mehrfach formuliert, Fehler gegenseitig bestätigt und für Koordination mehr Kontext verbraucht als für die eigentliche Aufgabe.

Multi-Agent-Architektur ist deshalb keine Dekoration und kein Reifegradabzeichen. Sie ist eine Antwort auf ein konkretes Strukturproblem. Erst wenn eine Aufgabe sinnvoll zerlegt werden kann, Teilrollen tatsächlich unterschiedliche Fähigkeiten oder Werkzeuge besitzen und Ergebnisse kontrolliert zusammengeführt werden, entsteht ein belastbarer Mehrwert.

Rollenbeschreibungen erzeugen noch keine Spezialisierung

„Du bist Rechercheur", „du bist Kritikerin" und „du bist Projektleiter" klingen nach Arbeitsteilung. Verwenden alle drei jedoch dasselbe Modell, dieselben Quellen, denselben Kontext und dieselbe Bewertungslogik, bleibt die Vielfalt häufig oberflächlich. Die Antworten unterscheiden sich im Ton, aber nicht zwingend in ihren blinden Flecken.

Echte Spezialisierung entsteht durch unterschiedliche Zugänge und Verantwortungen. Der Rechercheagent darf Primärquellen öffnen und Evidenzkarten anlegen. Der Datenagent kann strukturierte Dateien prüfen und Berechnungen reproduzieren. Der Redaktionsagent formuliert, darf aber keine neuen Fakten erfinden. Der Evaluator erhält Testfälle und Abnahmekriterien, verändert jedoch nicht das geprüfte Artefakt. Ein menschlicher Owner entscheidet bei Konflikten mit hoher Auswirkung.

Die Rolle wird damit nicht nur als Persona beschrieben, sondern als Vertrag aus Input, Toolzugriff, Outputschema, Qualitätsgate und Grenze. Wenn zwei Rollen denselben Vertrag besitzen, sollte geprüft werden, ob wirklich zwei Agenten benötigt werden.

Zuerst die Aufgabe, dann das Team

Eine gute Orchestrierung beginnt nicht mit einer Liste fantasievoller Agentennamen. Sie beginnt mit der Abhängigkeitsstruktur der Aufgabe. Manche Arbeitsschritte sind unabhängig: Drei klar abgegrenzte Quellenräume können parallel untersucht werden. Andere sind streng sequenziell: Eine Bewertung kann erst erfolgen, wenn Datenbereinigung und Berechnung abgeschlossen sind. Wieder andere benötigen wiederholte Rückkopplung, etwa Entwurf, Test und Korrektur.

Aus dieser Struktur entsteht ein Aufgabengraph. Jeder Knoten besitzt erwartete Eingaben, ein Ergebnis, einen Owner und ein Abschlusskriterium. Kanten zeigen echte Abhängigkeiten. Erst danach wird entschieden, ob ein Knoten durch Regelcode, einen einzelnen Agenten, mehrere parallele Agenten oder einen Menschen bearbeitet wird.

So verhindert man das häufigste Fehlmuster: Ein triviales lineares Verfahren wird auf mehrere Agenten verteilt und dadurch teurer, langsamer und schwerer prüfbar. Für einen klaren, kurzen Prozess ist ein einzelner Agent mit guten Tools häufig die bessere Architektur.

Der Orchestrator ist kein allwissender Chef

Forschungs- und Referenzsysteme wie Magentic-One zeigen einen Orchestrator, der Aufgaben zerlegt, Spezialisten auswählt, Fortschritt verfolgt und bei Fehlern neu plant. Dieses Muster ist nützlich, darf aber nicht mit unfehlbarer Führung verwechselt werden. Auch der Orchestrator ist ein probabilistisches System. Er kann falsche Aufgaben schneiden, ungeeignete Rollen wählen oder optimistische Statusmeldungen glauben.

Deshalb benötigt er strukturierte Ledgers statt bloßer Gesprächserinnerung. Ein Task Ledger hält Aufgabe, Abhängigkeit, Owner, Status und Akzeptanz fest. Ein Evidence Ledger verbindet Behauptungen mit Quellen und Prüfungen. Ein Decision Ledger protokolliert Richtungsentscheidungen, Alternativen und Begründungen. Der Orchestrator darf diese Register aktualisieren, aber nicht stillschweigend historische Einträge überschreiben.

Seine Leistung wird ebenfalls evaluiert: sinnvolle Zerlegung, korrekte Zuweisung, unnötige Delegationen, Wiederholungen, Integrationsfehler und sicheres Stoppen. Ein Orchestrator, der viel kommuniziert, ist nicht automatisch ein guter Orchestrator.

Gemeinsamer Kontext kann verbinden und vergiften

Ein vollständig geteilter Chat wirkt transparent. Jeder Agent sieht, was die anderen gedacht haben. Gleichzeitig wächst die Gefahr der Konvergenz: Eine frühe, falsche Annahme wird von allen übernommen. Ungeprüfte Zwischenergebnisse erhalten durch Wiederholung den Anschein von Wahrheit. Lange Dialoge verdrängen Primärdaten und klare Aufträge aus dem nutzbaren Kontext.

Vollständige Isolation ist ebenfalls problematisch. Getrennte Agenten wiederholen Arbeit, verwenden inkompatible Begriffe und kennen zentrale Entscheidungen nicht. Die Lösung ist selektive Kommunikation. Spezialisten erhalten nur die für ihre Aufgabe notwendigen Quellen, Regeln und Vorgängerergebnisse. Anstelle kompletter Chatverläufe werden strukturierte Übergaben übertragen: Auftrag, gültige Inputs, Behauptungen mit Evidenz, offene Unsicherheiten und erwartetes Outputschema.

Der gemeinsame Raum enthält den kontrollierten Projektzustand, nicht jedes Gedankengeräusch. Private Arbeitsnotizen können lokal bleiben; entscheidungsrelevante Fakten müssen in das Ledger. Dadurch sinkt die Kontextlast und die Herkunft bleibt sichtbar.

Nachrichten brauchen Protokolle

Freie Agentengespräche sind flexibel, aber schwer zu testen. Ein belastbares System definiert Nachrichtentypen. Eine Delegation enthält Ziel, Scope, Inputs und Deadline. Ein Ergebnis enthält Artefakt, Evidenz, Unsicherheit und erfüllte Kriterien. Eine Rückfrage benennt die blockierende Unklarheit. Eine Eskalation beschreibt Risiko, Optionen und benötigte Entscheidung.

Das verhindert, dass eine höfliche Antwort als erledigte Aufgabe interpretiert wird. „Sieht gut aus" ist kein Prüfresultat. „Testfall 4 fehlgeschlagen; Ursache unbekannt; Veröffentlichung blockiert" ist ein maschinen- und menschenlesbarer Status.

Nachrichten tragen außerdem Identität, Zeit, Task-ID, Artefaktversion und gegebenenfalls einen Hash. So lässt sich später rekonstruieren, welcher Agent welche Information auf welcher Grundlage weitergegeben hat. W3C PROV bietet dafür ein formales Modell; in kleineren Projekten kann ein schlankes Ereignisprotokoll genügen.

Parallelisierung lohnt sich nur bei echter Unabhängigkeit

Parallele Agenten können große Suchräume schneller abdecken. Ein produktiver Recherchebericht kann beispielsweise unabhängige Teilfragen gleichzeitig untersuchen lassen. Der technische Erfahrungsbericht eines produktiven Multi-Agent-Recherchesystems zeigt aber auch, dass Aufgabenzerlegung, Delegation, Ergebnissynthese und Evaluation zentrale Engineering-Probleme bleiben.

Parallelität lohnt sich, wenn Teilaufgaben wenig gemeinsame Zwischenzustände benötigen und Ergebnisse klar vergleichbar oder kombinierbar sind. Sie schadet, wenn jeder Schritt vom vorherigen abhängt, mehrere Agenten dieselbe Datei verändern oder die Synthese komplexer wird als die Einzelarbeit.

Deshalb wird vor dem Start ein Konfliktmodell festgelegt. Welche Artefakte sind exklusiv? Wer darf schreiben? Wie werden doppelte Ergebnisse erkannt? Was geschieht bei widersprüchlichen Befunden? Ohne Besitz- und Merge-Regeln produziert Parallelität vor allem Integrationsarbeit.

Kritik ist kein Beweis

Ein häufiges Muster lässt einen Agenten schreiben und einen zweiten kritisieren. Das kann Schwächen sichtbar machen, doch der Kritiker ist nicht automatisch korrekt. Er kann reale Aussagen fälschlich beanstanden, neue Fehler einführen oder nur stilistische Präferenzen als Qualitätsmängel darstellen.

Ein Evaluator benötigt daher Kriterien und Evidenzzugriff. Fakten werden gegen Primärquellen geprüft, Berechnungen reproduziert, Formate deterministisch validiert und Sicherheitsgrenzen mit Negativtests angegriffen. Subjektive Dimensionen wie Verständlichkeit oder Ton werden mit Rubrics und Beispielen bewertet. Wichtige Entscheidungen erhalten eine Eskalationsschwelle.

Unabhängigkeit entsteht nicht allein durch eine zweite Modellinstanz. Sie wächst durch getrennte Datenpfade, andere Werkzeuge, Blindprüfung, deterministische Tests oder fachliche Verantwortung. Wenn Ersteller und Prüfer dieselbe falsche Quelle verwenden, macht ihr Konsens die Aussage nicht wahr.

Fehler können sich im Team vervielfachen

In einem einzelnen Agenten bleibt ein Fehler zunächst lokal. In einem vernetzten System kann er zur Nachricht, Entscheidung und neuen Eingabe werden. Ein kompromittierter Spezialist kann manipulierte Daten an den Orchestrator liefern; dieser verteilt sie als gültigen Projektzustand. OWASP behandelt deshalb Multi-Agent-Systeme als zusätzliche Angriffsfläche mit Identitäts-, Nachrichten-, Gedächtnis- und Toolrisiken.

Jede Vertrauensgrenze braucht Validierung. Agenten dürfen fremde Inhalte nicht als Systemanweisung übernehmen. Toolergebnisse werden nach Schema und Plausibilität geprüft. Rollen authentisieren sich, Rechte bleiben minimal, sensible Daten werden nur an notwendige Empfänger übertragen. Kritische Nachrichten können signiert oder über kontrollierte Broker geleitet werden.

Ein „vertrauenswürdiger Agent" ist keine dauerhafte Eigenschaft. Vertrauen gilt für eine konkrete Identität, Version, Aufgabe, Quelle und Befugnis. Ändert sich eine dieser Bedingungen, muss die Bewertung neu erfolgen.

Integration ist die eigentliche Teamleistung

Mehrere gute Teilresultate ergeben noch kein gutes Gesamtergebnis. Sie können unterschiedliche Definitionen, Zeitstände und Annahmen verwenden. Die Integrationsschicht prüft deshalb Semantik, nicht nur Dateiformat. Stimmen Begriffe überein? Wurden dieselben Einheiten verwendet? Sind Quellenprioritäten kompatibel? Widersprechen sich Empfehlungen? Ist eine Behauptung doppelt gezählt?

Der Syntheseagent darf Konflikte nicht glatt formulieren. Er markiert sie, fordert Evidenz nach oder eskaliert. Erst nach bestandener Integration wird ein Artefakt zum gültigen Projektstand. Vorversionen und Herkunft bleiben erhalten.

Die entscheidende Metrik ist nicht die Zahl erzeugter Nachrichten, sondern der Anteil korrekt integrierter, überprüfbarer Ergebnisse. Dazu kommen Kosten, Latenz, menschlicher Prüfaufwand, Wiederholungen und sichere Fehlerbehandlung.

Wann ein einzelner Agent besser ist

Ein Multi-Agent-System sollte nicht eingesetzt werden, wenn die Aufgabe kurz, eindeutig und mit einem Toolaufruf lösbar ist; wenn der Output deterministisch erzeugt werden kann; wenn Teilaufgaben stark sequenziell sind; wenn Rollen keine realen Fähigkeitsunterschiede besitzen; oder wenn das zusätzliche Risiko und die Beobachtbarkeit nicht beherrscht werden können.

Eine robuste Architektur wächst stufenweise. Zuerst wird der einfachste Workflow gebaut. Engpässe werden gemessen. Erst dann wird eine Rolle ausgelagert, wenn klare Hypothesen bestehen: bessere Quellenabdeckung, getrennte Prüfung, spezieller Toolzugriff oder echte Parallelität. Die neue Architektur muss gegen die einfachere Baseline gewinnen – nicht nur eindrucksvoller aussehen.

Übungsblatt: Entwirf ein überprüfbares Agententeam

Wähle eine komplexe, aber klar abgrenzbare Aufgabe. Erstelle zunächst eine Ein-Agent-Baseline und danach eine Teamarchitektur.

1. Zeichne den Aufgabengraphen mit Abhängigkeiten und unabhängigen Teilaufgaben.

2. Definiere für jede Rolle Fähigkeit, Tool, Input, Output, Grenze und Done-Kriterium.

3. Lege Task-, Evidence- und Decision-Ledger an.

4. Entwirf vier Nachrichtentypen: Delegation, Ergebnis, Rückfrage und Eskalation.

5. Bestimme gemeinsame und isolierte Kontexte sowie Datenzugriffsrechte.

6. Definiere Merge-Regeln, Konfliktbehandlung und menschliche Checkpoints.

7. Teste Normalfall, widersprüchliche Evidenz, Agentenausfall und manipulierte Nachricht.

8. Vergleiche Team und Baseline nach Qualität, Kosten, Zeit, Wiederholung und Prüfaufwand.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Ein Multi-Agent-System ist nicht automatisch leistungsfähiger, sicherer oder unabhängiger als ein einzelner Agent. Der Nutzen hängt von Aufgabe, Zerlegbarkeit, Spezialisierung, Kommunikationskosten, Kontrollarchitektur und Evaluation ab. Die beschriebenen Muster sind Architekturprinzipien, keine allgemeine Leistungsgarantie.