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.