03 · Multi-AgentManager AgentCoordinator AgentCentral Controller

Supervisor.
Einer entscheidet. Spezialisten handeln.

Ein zentraler Agent entscheidet dynamisch, welcher spezialisierte Agent oder welches Tool als Nächstes arbeitet.

Wann man dazu greift

Zentrale Kontrolle und Nachvollziehbarkeit wesentlich sind.
Mehrere Spezialisten koordiniert werden müssen.
Aufgaben dynamisch delegiert werden.

Wann es nach hinten losgeht

Vollständig dezentralisierte Kooperation benötigt wird.
Der Supervisor zum Single Point of Failure zu werden droht.
Die Delegation für einfaches Routing statisch genug ist.

Die Abwägung

Klare operative Kontrolle wird auf Kosten eines potenziellen Koordinierungsengpasses aufrechterhalten.

Das mentale Modell

Eine Form, die du auf eine Serviette zeichnen kannst.

Jeder Schritt beginnt und endet beim Supervisor. Beobachte den Dispatch: Der Supervisor wählt einen Spezialisten, der Spezialist gibt zurück, der Supervisor entscheidet, ob er erneut dispatcht oder antwortet.

Einmal durchspielen

Ein realer Ablauf, Schritt für Schritt.

Aufgabe"Mein Paket ist nicht angekommen, und ich möchte eine Rückerstattung."

1 / 8

Entscheiden"Zwei Probleme: Lieferung und Rückerstattung. Ich bearbeite zuerst die Lieferfrage — ich brauche Fakten, bevor ich Geldangelegenheiten klären kann."

Dispatch → Versandshipping_agent.handle(order_id="A-77192")

Versand antwortet"Tracking zeigt, dass das Paket am 12. Mai an eine falsche Adresse als zugestellt markiert wurde. Der Kunde hat Recht, dass es nicht angekommen ist."

Entscheiden"Lieferung ist bestätigt verloren. Jetzt kann ich die Rückerstattung autorisieren."

Dispatch → Rückerstattungenrefunds_agent.handle(order_id="A-77192", reason="lost_in_transit", amount=47.00)

Rückerstattungen antwortet"Rückerstattung von €47,00 verarbeitet. Referenz R-30482. Kunde per E-Mail benachrichtigt."

Entscheiden"Beide Probleme gelöst. Nichts mehr zu dispatchen. Durchlauf wird beendet."

Antwort"Ihr Paket wurde an eine falsche Adresse zugestellt. Wir haben €47,00 erstattet (Ref. R-30482) und eine Bestätigung per E-Mail gesendet."

Im Code

Die Schleife ist schon eingebaut.

LangGraphpython

from langgraph.graph import StateGraph, END

def supervisor(state):
    # LLM picks the next agent by name — or "done"
    choice = llm.choose_next(
        history=state["messages"],
        options=["shipping", "refunds", "tech", "done"],
    )
    return {"next": choice}

graph = StateGraph(State)
graph.add_node("supervisor", supervisor)
graph.add_node("shipping", shipping_agent)
graph.add_node("refunds", refunds_agent)
graph.add_node("tech", tech_agent)

graph.add_conditional_edges("supervisor",
    lambda s: s["next"],
    {"shipping": "shipping", "refunds": "refunds",
     "tech": "tech",   "done": END})

# Each specialist returns control to the supervisor:
for spec in ["shipping", "refunds", "tech"]:
    graph.add_edge(spec, "supervisor")

graph.set_entry_point("supervisor")

Fallstricke

Drei Wege, wie dieses Pattern Probleme verursachen kann.

God Orchestrator

Der Supervisor häuft Tools an, wird zum Ort, an dem jede Prompt-Änderung landet, und hält am Ende rohe Nutzerdaten, die er nicht benötigt.

Lösung · Prompt & Toolset des Supervisors minimal halten. Spezialisten besitzen ihre Tools. Sensible Daten bleiben im Bereich des Spezialisten.

Ping-Pong-Routing

Der Supervisor sendet an Versand, bekommt eine Teilantwort, sendet erneut an Versand, bekommt dieselbe Teilantwort, und die Schleife endet nie.

Lösung · Hartes max_iterations-Limit. Die 'next'-Ausgabe des Supervisors schema-validieren. Jede Routing-Entscheidung protokollieren.

Kontextverlust zwischen Spezialisten

Rückerstattungen weiß nicht, was Versand herausgefunden hat, weil der Supervisor das Detail zusammengefasst und dabei verworfen hat. Entscheidungen werden auf Basis veralteter oder falscher Annahmen getroffen.

Lösung · Strukturierten Zustand übergeben, keine Textzusammenfassungen. Pydantic v2 Schemas bei jeder Übergabe. Rohe Fakten inspizierbar halten.