Multi-Agent-Topologien: Supervisor, Netzwerk, Hierarchie und adaptive Systeme

Warum die Topologie wichtiger ist als die Prompts

Ein Team aus fünf KI-Agenten, das niemand verdrahtet hat, ist kein System. Es ist ein Stimmengewirr. Genau hier liegt der Punkt, den ich in Projekten am häufigsten unterschätzt sehe: Die Qualität eines Multi-Agent-Systems steckt nicht primär in den einzelnen Prompts, sondern in der Architektur. Also darin, wer mit wem kommuniziert und wer am Ende entscheidet.

Zur Erinnerung die Abgrenzung. Ein Multi-Agent-System (MAS) besteht aus mehreren autonomen, interagierenden Agenten in einer gemeinsamen Umgebung, die kooperieren, koordinieren oder konkurrieren, um Ziele zu erreichen. Statt einer zentralen Entscheidungsinstanz gibt es verteilte Kontrolle und spezialisierte Rollen — wie ein gut eingespieltes Team, in dem jeder einen Teil verantwortet. Wer den Unterschied zum Einzelagenten noch sauber ziehen möchte, findet das im Beitrag Multi-Agent-System vs. Single-Agent.

Die Topologie ist die Verdrahtung dieses Teams. Und davon gibt es vier etablierte Klassen. Schauen wir sie der Reihe nach an.

Zentralisiert: der Supervisor delegiert, der Rest arbeitet zu

Das zentralisierte Muster heißt auch Hub-and-Spoke. Ein einzelner Orchestrator — der Supervisor — nimmt die Aufgabe entgegen, zerlegt sie, delegiert die Teilaufgaben an spezialisierte Worker-Agenten und führt deren Ergebnisse wieder zusammen. Die Worker reden nicht untereinander. Alle Kommunikation läuft über die Nabe.

Der große Vorteil ist Kontrolle. Es gibt genau einen Punkt, an dem Entscheidungen fallen, und genau einen Punkt, an dem Sie ins Logging schauen müssen. Das macht Tracing, Debugging und Governance vergleichsweise einfach. Für die meisten produktiven Anwendungsfälle im Mittelstand ist das der richtige Start.

Die Schwäche ist ebenso offensichtlich. Der Supervisor ist ein potenzieller Flaschenhals und ein Single Point of Failure. Fällt er aus oder trifft er eine schlechte Routing-Entscheidung, leidet das ganze System. Bei sehr vielen Workern wird der Orchestrator außerdem selbst zur komplexen Komponente.

Wann einsetzen? Immer dann, wenn sich die Aufgabe in klar abgegrenzte Teilaufgaben zerlegen lässt, die unabhängig voneinander bearbeitet werden können. Klassischer Fall: eine Kundenanfrage, die je nach Inhalt an einen Recherche-, einen Berechnungs- oder einen Formulierungsagenten geht.

Eine Supervisor-Routing-Skizze in Pseudocode

Damit das konkret wird, hier eine reduzierte Skizze eines Supervisor-Routings. Der Supervisor klassifiziert die Anfrage und routet an den passenden Worker. Das Muster ist bewusst schlicht gehalten.

WORKER = {

"recherche": research_agent,

"rechnen": calc_agent,

"schreiben": writing_agent,

}

def supervisor(anfrage: str, max_schritte: int = 5) -> str:

verlauf = []

for _ in range(max_schritte):

# LLM-Entscheidung: welcher Worker, oder fertig?

plan = llm_route(anfrage, verlauf, optionen=list(WORKER) + ["FERTIG"])

if plan.ziel == "FERTIG":

return plan.antwort

worker = WORKER[plan.ziel]

ergebnis = worker(plan.teilaufgabe)        # Worker reden NICHT untereinander

verlauf.append((plan.ziel, ergebnis))      # alles laeuft ueber die Nabe

return zusammenfuehren(verlauf)                 # Fallback nach Schrittlimit

Zwei Details sind in der Praxis wichtig. Erstens das harte Schrittlimit max_schritte. Ohne diese Bremse drehen sich LLM-gesteuerte Loops gern im Kreis. Zweitens das FERTIG-Signal: Der Supervisor muss explizit beenden dürfen, sonst läuft er bis zum Limit. In ausgereiften Frameworks ist genau dieses Muster die Grundlage, nur mit Zustandspersistenz, Fehlerbehandlung und Tracing drumherum.

Dezentral: Agenten reden direkt, ohne Chef in der Mitte

Im dezentralen Netzwerk gibt es keine zentrale Instanz. Die Agenten kommunizieren direkt miteinander, Peer-to-Peer. Jeder kann mit jedem reden, Ergebnisse weitergeben, Anfragen stellen, verhandeln.

Das ist robust. Es gibt keinen einzelnen Ausfallpunkt, und das System kann emergentes Verhalten zeigen, das keiner explizit programmiert hat. Schwarmverhalten in der Robotik ist das klassische Beispiel, ebenso der Peer-to-Peer-Energiehandel im Smartgrid. Dort verhandeln Agenten autonom miteinander, ohne dass eine Leitstelle jeden Handel orchestriert.

Der Preis ist Komplexität. Mit jedem zusätzlichen Agenten steigt die Zahl möglicher Kommunikationspfade überproportional. Ohne saubere Protokolle wird aus Peer-Kollaboration schnell ein nicht nachvollziehbares Durcheinander. Und es gibt eine spezifische Falle bei LLM-Agenten, die ich für unterschätzt halte: semantische Intent-Divergenz. Jeder Agent sitzt in seinem eigenen Kontextfenster mit eigenem Prompt-Framing. Zwei Agenten können dasselbe geteilte Ziel unterschiedlich interpretieren und auf Intent-Ebene gegeneinander arbeiten, ohne dass ein Mechanismus das überhaupt bemerkt. Das ist kein syntaktischer Konflikt wie in klassischen verteilten Systemen, sondern ein semantischer. Forschung wie das Semantic Consensus Framework (arXiv 2026) adressiert genau das mit prozessbewusster Middleware. Für die Praxis heißt es vor allem: Echte Dezentralität braucht durchdachte Kommunikationsprotokolle.

Wann einsetzen? Nur bei echter Peer-Kollaboration, in der Agenten gleichberechtigt verhandeln müssen und keine sinnvolle zentrale Autorität existiert. Wer das System ohnehin steuern will, ist mit einem Supervisor besser bedient.

Hierarchisch: ein Baum aus Meta-Agenten und Sub-Agenten

Die hierarchische Topologie ist im Kern ein Supervisor mit mehreren Ebenen. Ein Meta-Agent steht über Sub-Agenten, die ihrerseits wieder eigene Sub-Agenten dirigieren können. Es entsteht eine Baumstruktur. Man kann sie sich wie ein Organigramm vorstellen: oben die Geschäftsführung, darunter Abteilungsleiter, darunter Teams.

Die Stärke liegt in der Aufgabenzerlegung. Komplexe Probleme, die sich in Teilprobleme und Teil-Teilprobleme gliedern, lassen sich sauber auf Ebenen abbilden. Jede Ebene arbeitet auf ihrer eigenen Abstraktionshöhe. Das Koordinationsmuster dahinter ist alt und bewährt: Das Contract Net Protocol (Reid G. Smith, 1980) beschreibt genau dieses Task-Sharing. Ein Manager schreibt eine Aufgabe aus, Agenten machen Angebote, der Manager vergibt — und eine vergebene Aufgabe kann weiter zerlegt und untervergeben werden. Subcontracting im Wortsinn.

Die Schwäche ist die Tiefe selbst. Jede zusätzliche Ebene fügt Latenz hinzu und erschwert das Tracing. Eine Entscheidung der untersten Ebene bis zur Wurzel zurückzuverfolgen, kann mühsam werden. Und wie beim Supervisor gilt: Ein schwacher Knoten weit oben im Baum vergiftet alles darunter.

Wann einsetzen? Bei tiefer, mehrstufiger Aufgabenzerlegung. Wenn Ihre Aufgabe natürlicherweise in eine Gliederung mit Unterpunkten zerfällt, ist die Hierarchie das passende Bild. Ein Beispiel sind mehrstufige Geschäftsprozesse, etwa eine Kundenservice-Kette, die über Triage, Fachbearbeitung und Qualitätsprüfung läuft.

Dynamisch-adaptiv: die Struktur formt sich zur Laufzeit

Die ersten drei Muster legen die Struktur zur Designzeit fest. Das adaptive Muster nicht. Hier sind Topologie und Rollenverteilung nicht fix, sondern entwickeln sich zur Laufzeit mit dem Aufgabenfortschritt. Ein Meta-Mechanismus beobachtet, rekonfiguriert das Agenten-Netz, erzeugt Agenten on-demand, weist Rollen neu zu und routet Kommunikation um.

In der Praxis begegnet Ihnen das bereits in gängigen Frameworks. AutoGen nutzt eine auto-speaker-selection, bei der ein LLM pro Zug entscheidet, welcher Agent als Nächstes spricht. LangGraph arbeitet mit conditional edges: Prädikate, die zur Laufzeit ausgewertet werden und Branches, Loops oder dynamisches Routing steuern. Das System verzweigt also abhängig vom aktuellen Zustand, nicht nach einem starren Ablauf.

Die Forschung geht weiter. DyLAN berechnet einen Agent-Importance-Score, um zur Laufzeit das optimale Team zusammenzustellen. GPTSwarm modelliert das Agentensystem als optimierbaren Berechnungsgraphen. Laut dem GPTSwarm-Paper erreicht dieser Ansatz eine zu DyLAN vergleichbare Genauigkeit bei rund einem Zwanzigstel der Kosten. Diese Zahl ist eine Studienschätzung, kein hartes Benchmark — aber die Richtung ist bemerkenswert: Gelernte, automatisch optimierte Topologien können token-effizienter sein als handgebaute. Aus meiner Projekterfahrung ist das die spannendste, aber auch die heikelste Klasse.

Die Schwäche ist die Beobachtbarkeit. Wenn sich die Struktur selbst verändert, ist eine fixe Architektur-Dokumentation wertlos. Sie müssen zur Laufzeit sehen können, welche Agenten gerade existieren, wer mit wem redet und warum eine bestimmte Verzweigung genommen wurde. Ohne durchgängiges Tracing ist ein adaptives System eine Blackbox, die im Fehlerfall niemand entwirren kann.

Wann einsetzen? Erst, wenn die Observability steht. Adaptive Topologien lohnen sich bei Aufgaben mit stark schwankender Struktur, deren optimale Bearbeitung sich vorab nicht festlegen lässt. Aber nur, wenn Sie das resultierende Verhalten auch nachvollziehen können.

Entscheidungshilfe: welche Topologie für Ihr Projekt

Die Wahl muss kein Glücksspiel sein. In den meisten Projekten führt eine einfache Reihenfolge zum Ziel, von der robustesten zur anspruchsvollsten Option. Beginnen Sie defensiv und steigern Sie nur bei echtem Bedarf.

Ein Wort zur Realität, bevor Sie loslegen. Laut dem Semantic-Consensus-Paper liegen die Produktions-Failure-Rates von Multi-Agent-Systemen je nach Studie zwischen 41 und 86,7 Prozent — und etwa 79 Prozent dieser Fehler stammen aus Spezifikations- und Koordinationsproblemen, nicht aus mangelnder Modellfähigkeit. Diese Zahlen sind als Studienschätzung zu lesen. Die Botschaft dahinter ist aber stabil: Es scheitert an der Verdrahtung, nicht am Modell. Genau deshalb ist die Topologie-Entscheidung so wichtig. Mehr zu den Stolpersteinen im Beitrag Herausforderungen von Multi-Agent-Systemen.

• Starten Sie mit dem Supervisor. Er ist kontrollierbar, gut zu tracen und deckt die meisten Fälle ab. Im Zweifel ist das die richtige Wahl.
• Wechseln Sie zum Netzwerk nur bei echter Peer-Kollaboration, in der Agenten gleichberechtigt verhandeln und keine zentrale Autorität sinnvoll ist.
• Wählen Sie die Hierarchie bei tiefer, mehrstufiger Aufgabenzerlegung, die natürlicherweise in Ebenen zerfällt.
• Greifen Sie zu adaptiv erst, wenn Sie eine gute Observability haben — sonst ist die Laufzeit-Rekonfiguration nicht beherrschbar.

Governance: mehr Agenten, mehr Verantwortung

Ein Aspekt, der im DACH-Mittelstand keine Fußnote sein darf. Mehr Agenten bedeuten mehr Datenflüsse und mehr Autonomie. Damit rücken regulatorische Anforderungen aus der Kür in die Pflicht. Die DSGVO mit ihren Prinzipien Zweckbindung und Datenminimierung gilt für jeden Agenten, der personenbezogene Daten verarbeitet. Der EU AI Act verlangt mit Artikel 50 eine Kennzeichnung von KI — die Pflicht greift ab dem 2. August 2026.

Praktisch heißt das: Audit-Trails, Tracing und Observability sind keine netten Extras mehr. Sie sind die Voraussetzung dafür, dass Sie ein Multi-Agent-System überhaupt verantworten können. Und sie sind, nebenbei, exakt dieselbe Infrastruktur, die Sie für adaptive Topologien ohnehin brauchen. Wie die Agenten dabei technisch miteinander und mit ihren Werkzeugen sprechen, behandelt der Beitrag Agenten-Kommunikation mit MCP und A2A. Den Gesamtüberblick liefert der Leitfaden Multi-Agent-Systeme.

Bereit, die richtige Architektur zu wählen?

Die Topologie-Entscheidung trifft man am besten einmal richtig, statt sie später teuer umzubauen. Wenn Sie ein Multi-Agent-System für Ihren Anwendungsfall planen oder ein bestehendes System stabilisieren wollen, unterstütze ich Sie gern bei Architektur, Auswahl und Observability. Schreiben Sie mir — wir schauen gemeinsam, welche der vier Topologien zu Ihrer Aufgabe passt.

FAQ

Häufige Fragen