Orchestration Topologies: Wie Agenten Workflows koordinieren

Idee in 30 Sekunden

Orchestration Topologies ist eine Methode, die Interaktion zwischen mehreren Agenten in einem System zu organisieren.

Es geht nicht um "kluegere Prompts", sondern um Struktur: wer die Aufgabe annimmt, wer Teilaufgaben ausfuehrt und wie Ergebnis zurueckkommt.

Wann noetig: wenn ein Agent die Aufgabe allein nicht mehr schafft und mehrere Rollen oder Agenten-Teams gebraucht werden.

Das LLM kann einen Plan vorschlagen, aber die Orchestrierungs-Topologie bestimmt den sicheren und vorhersagbaren Ausfuehrungspfad.

Problem

Wenn in einem System mehrere Agenten ohne klare Topologie auftauchen, wird der Prozess schnell chaotisch.

Typische Probleme:

• es ist unklar, welcher Agent wofuer verantwortlich ist;
• Teilaufgaben werden dupliziert oder gehen verloren;
• Agenten "schieben" die Aufgabe einander zu, ohne Abschluss;
• stop conditions und globale Limits auf Systemebene sind schwer zu kontrollieren;
• ein Fehler ist schwer zu lokalisieren, weil ein expliziter Ausfuehrungspfad fehlt.

Dadurch verbraucht das System mehr Ressourcen, waehrend Qualitaet und Vorhersagbarkeit sinken.

Loesung

Fuege Orchestration Topology als explizites Koordinationsschema fuer ein konkretes multi-agent System hinzu: wer orchestriert, wer ausfuehrt, wie handoffs passieren und wann alles stoppt.

Das ergibt eine transparente Route der Aufgabe vom Start bis zum Endergebnis.

Analogie: wie ein oeffentliches Verkehrsnetz.

Ein Fahrgast kann verschiedene Routen fahren, aber es gibt klare Knoten, Umstiege und eine Endstation.

Orchestration Topology legt ebenso die Route einer Aufgabe zwischen Agenten fest.

Wie Orchestration Topologies funktionieren

Orchestration Topology ist ein explizites Koordinationsschema zwischen Koordinator und Agenten-Team, das Reihenfolge von Teilaufgaben-Handoff und Ergebnis-Sammlung festlegt.

Runtime arbeitet innerhalb jedes Agenten, daher ist es im Diagramm nicht als separater Knoten gezeigt.

Dieser Zyklus liefert einen kontrollierten Aufgabenpfad zwischen Agenten und reduziert Chaos im multi-agent System.

Typische Orchestration Topologies

Schneller Auswahl-Leitfaden:

• Centralized - wenn einfache und transparente Kontrolle ueber einen Koordinator noetig ist.
• Pipeline - wenn jeder naechste Schritt vom vorherigen abhaengt.
• Parallel - wenn Teilaufgaben unabhaengig sind und Geschwindigkeit durch Gleichzeitigkeit wichtig ist.
• Hierarchical - wenn es mehrere Koordinations-Ebenen gibt (Team/Subteam-Richtung).
• Hybrid - wenn ein System fuer verschiedene Aufgaben verschiedene Routing-Schemata braucht.

Im Code sieht das so aus

class OrchestrationTopology:
    def __init__(self, coordinator, agents, max_handoffs=12):
        self.coordinator = coordinator
        self.agents = agents
        self.max_handoffs = max_handoffs

    def run(self, task):
        queue = [task]
        results = []
        handoffs = 0

        while queue and handoffs < self.max_handoffs:
            current = queue.pop(0)
            plan = self.coordinator.route(current)
            target = plan["agent"]

            if target not in self.agents and target != "finish":
                return self.coordinator.fallback(results, reason="unknown_agent")

            if target == "finish":
                return self.coordinator.merge(results)

            outcome = self.agents[target].execute(plan["payload"])
            results.append(outcome)
            queue.extend(self.coordinator.next_steps(outcome))
            handoffs += 1

        return self.coordinator.fallback(results, reason="handoff_limit_reached")

So sieht es zur Laufzeit aus

Anfrage: "Erstelle einen Vergleich von 3 CRM und gib eine Empfehlung fuer ein kleines Unternehmen"

Step 1
Coordinator: Decompose -> [Datensammlung, Kostenbewertung, finale Empfehlung]
Topology: Route -> Agent A (Datensammlung), Agent B (Kostenbewertung)

Step 2
Agent A: liefert einen Funktionsvergleich zurueck
Agent B: liefert Preis- und Einschraenkungsvergleich zurueck
Coordinator: Merge -> uebergibt an Agent C (finale Empfehlung)

Step 3
Agent C: formuliert die Antwort fuer den Nutzer
Topology: Stop -> final_answer + Trace

Orchestration Topology ersetzt Agenten nicht, sondern organisiert ihre Zusammenarbeit in einen vorhersagbaren Prozess.

Wann es passt - und wann nicht

Orchestration Topologies werden gebraucht, wenn Aufgaben besser von einem Agenten-Team geloest werden. Fuer einfache one-shot Aufgaben ist das meist uebermaessig.

Passt

Passt nicht

In solchen Faellen reicht oft ein einfacher Aufruf:

response = single_agent.run(task)

Typische Probleme und Ausfaelle

Die meisten solcher Probleme werden durch explizites Routing, handoff-Limits und transparenten Trace je Zweig geloest.

Wie es mit anderen Patterns zusammenspielt

Orchestration Topologies beschreiben die Architektur der Agenten-Interaktion und ersetzen keine anderen Systemschichten.

• Agent Runtime - Runtime fuehrt Schritte jedes Agenten aus, waehrend die Topologie die Route zwischen Agenten festlegt.
• Tool Execution Layer - jeder Agent in der Topologie ruft Tools ueber kontrollierte execution layer auf.
• Memory Layer - Topologie bestimmt, welcher Speicher geteilt ist und welcher fuer einen Agenten lokal ist.
• Policy Boundaries - policy rules pruefen erlaubte Uebergaenge und Aktionen in jedem Zweig.

Anders gesagt:

• Agent Patterns definieren wie ein konkreter Agent denkt
• Orchestration Topologies definieren wie mehrere Agenten eine Aufgabe gemeinsam ausfuehren

Unterschied zu Orchestrator Agent

Orchestrator Agent ist die Rolle eines Agenten.

Orchestration Topologies ist die Architekturkarte des gesamten Agenten-Systems.

Kurz

FAQ

Q: Wie waehlt man zwischen Pipeline, Parallel und Hierarchical topology?
A: Wenn Schritte voneinander abhaengen - Pipeline. Wenn Teilaufgaben unabhaengig sind - Parallel. Wenn es mehrere Koordinations-Ebenen gibt - Hierarchical.

Q: Kann man mit einfacher Topologie starten und spaeter erweitern?
A: Ja. Oft startet man mit zentralisiertem Schema und fuegt spaeter Hierarchie oder hybride Zweige bei wachsendem Bedarf hinzu.

Q: Ersetzt Topologie policy rules?
A: Nein. Topologie ist fuer Route und Koordination zustaendig, Policy Boundaries fuer erlaubte Aktionen und Uebergaenge.

Q: Was waehlen: Orchestrator Agent oder Orchestration Topology?
A: Das ist nicht gegenseitig ausschliessend. Orchestrator Agent kann ein Knoten innerhalb der gewaehlten topology sein.

Was als Naechstes

Topologie erklaert, wie sich eine Aufgabe durch das System bewegt. Als Naechstes sieh, wie diese Bewegung kontrolliert und sicher wird:

• Hybrid Workflow Agent - wie feste Stufen mit Agent-Entscheidungen kombiniert werden.
• Agent Runtime - wie Schritte mit kontrollierten Stop-Gruenden ausgefuehrt werden.
• Human-in-the-Loop Architecture - wo ein Mensch die finale Entscheidungsautoritaet behalten sollte.
• Production Stack - wie Topologie in Production skaliert wird.