Kapitel 6 — Grundlegende Orchestrierungsstrategien

Sechster Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Ein Multi-Agent-System ist ein verteiltes System — sobald dieser Rahmen akzeptiert ist, werden die meisten Designentscheidungen dieses Kapitels vertraut, und die meisten teuren Fehlschläge von 2024 und 2025 hören auf, mysteriös zu sein.

Warum dieses Kapitel existiert

Die Marketingsprache rund um agentische Systeme suggeriert, dass mehr Agenten von sich aus besser sind — mehr kognitive Pferdestärke, mehr Spezialisierung, mehr emergente Fähigkeit. Die Ingenieurrealität ist in den meisten Fällen das Gegenteil. Jeder zusätzliche Agent fügt einen Round Trip hinzu, eine Serialisierungsstelle, einen Punkt, an dem die Ausgabe eines Agenten zur Eingabe eines anderen wird, und eine neue Gelegenheit, dass die Konversation aus der Spur läuft. Die richtige Anfangsfrage lautet nicht „wie verteile ich das auf Agenten?", sondern „kann ein einzelnes Modell mit den richtigen Werkzeugen das in einem Aufruf erledigen?"

Dieses Kapitel geht die zwei einfachsten Orchestrierungsformen durch — sequenziell und nebenläufig — und die vorgelagerte Frage, die beiden vorausgehen sollte. Viele der teuersten Produktionsfehler der letzten zwei Jahre waren keine Orchestrierungsfehler. Es waren Systeme, gebaut als Multi-Agent, wo ein einzelner gut bewaffneter Agent die Aufgabe mit einem Zehntel der Latenz und ohne Koordinationsbugs erledigt hätte.

6.1 Wann mehrere Agenten wirklich helfen

Das Argument für einen einzelnen Agenten mit Tools ist am stärksten, wenn die Aufgabe sich in eine kleine Anzahl wohldefinierter Operationen gegen wohldefinierte Datenquellen zerlegt. Ein Code-Review-Assistent, der ein Diff liest, einen Linter fährt, Konventionen nachschlägt und einen Kommentar schreibt, lässt sich als eine Modellanrufung mit vier Werkzeugen bauen. Einen zweiten Agenten hinzuzufügen, bringt Latenz ohne zusätzliche Fähigkeit — das Modell plant bereits; ein zweites Modell, das anders plant, ist Koordinationskost, keine Verbesserung.

Drei Eigenschaften machen mehrere Agenten lohnend. Heterogenität des Kontexts — wenn zwei Phasen dramatisch andere System-Prompts, Werkzeuge oder Referenzmaterialien brauchen, verdünnt das Zwängen beider in ein Fenster die Aufmerksamkeit des Modells. Recherchieren-dann-schreiben ist der kanonische Fall: Retrieval will Breite und Suchwerkzeuge, Schreiben will Prosa und keine Werkzeuge. Iterative Verfeinerung gegen eine externe Prüfung — muss eine Ausgabe geprüft und ggf. neu geschrieben werden, wollen Macher und Prüfer je eigenen Kontext und Prompt. Parallelismus über unabhängige Teilaufgaben — fünf zu fassende Quellen, drei Perspektiven, zehn Dateien zu analysieren — sie seriell zu fahren, verschwendet Wandzeit für Arbeit ohne Kausalabhängigkeit.

Vor der Festlegung auf Multi-Agent sollte ein Entwickler die Eigenschaft benennen können, die das motiviert. Ein 2025er-Rückblick eines großen Logistikers ersetzte eine Sieben-Agenten-Support-Orchestrierung durch einen einzelnen Claude-Agenten plus sechs MCP-Tools; die Einzelagent-Version war schneller, billiger und punktete höher in der Lösungsqualität. „Können wir das kollabieren?" sollte eine stehende Frage in jedem Orchestrierungs-Review sein.

6.2 Sequenzielle Orchestrierung: Pipelines und progressive Verfeinerung

Sequenzielle Orchestrierung ist die einfachste Multi-Agent-Form. Die Ausgabe eines Agenten wird zur Eingabe des nächsten. Die meisten produktiven „Multi-Agent"-Systeme sind verkleidete sequenzielle Pipelines. Die Stärke ist Lesbarkeit: die Pipeline lässt sich auf einem Whiteboard zeichnen, Stage für Stage testen und als Folge von Input-Output-Verträgen verstehen. Der Vertrag zwischen Stages ist das Schlüsselartefakt — jede Stage deklariert ihr Input-Schema, der Orchestrator setzt es per Code durch statt per Vertrauen, und Validierungsfehler lösen Retries oder Fallbacks aus statt still weiterzulaufen.

Der kanonische Fall ist Recherchieren-dann-schreiben. Ein Rechercheagent mit Websuche und Retrieval-Tools erzeugt ein strukturiertes Briefing; ein Schreibagent ohne Tools und mit Prosa-Prompt verwandelt das Briefing in einen Artikel. Der Schreibagent sieht keine Fehlversuche, verworfenen Quellen oder langen Reasoning-Ketten. Er sieht das Briefing. Beide Stages dürfen unterschiedliche Modelle nutzen — starkes Reasoning fürs Recherchieren, starke Prosa fürs Schreiben — und die Kosten fallen nur dort an, wo nötig. Progressive Verfeinerung ist nahe verwandt: entwerfen, redigieren, faktenprüfen, neu formatieren. Spezialisierte Operatoren übertreffen einen Generalisten, der alles in einem Durchgang versucht.

Die ehrlichen Kosten sind drei. Latenz — eine N-Stage-Pipeline hat einen Boden in Höhe der Summe der Stage-Laufzeiten. Lange Pipelines schließen sich selbst aus der Konversationslatenz aus. Fehlerverstärkung — eine Vier-Stage-Pipeline mit 95% pro Stage ergibt 81% End-to-End; bei acht 66%. Pro-Stage-Validierung mit begrenzten Retries hält die Mathematik betriebsfähig. Informationsverlust zwischen Stages — jede Ausgabe ist notwendig schmaler als ihr Arbeitskontext, und Information, von der der Schreibagent später merkt, dass er sie braucht, ist weg, wenn das Briefing-Schema nicht reicher war als unbedingt nötig.

6.3 Nebenläufige Orchestrierung: Scatter, Gather, Multi-Perspektive

Nebenläufige Orchestrierung fährt mehrere Agenten parallel und kombiniert ihre Ausgaben. Die definierende Eigenschaft ist keine Kausalabhängigkeit während der Arbeit — Abhängigkeit nur am Kombinationsschritt. Manchmal Scatter-Gather genannt, manchmal Map-Reduce für Agenten; die Topologie ist dieselbe.

Drei Anwendungsfälle motivieren das Muster. Parallelismus über unabhängige Teilaufgaben — fünf Quellen parallel gelesen, dann ein Synthetisierer. Wandzeit ist die langsamste Quelle plus der Synthetisierer, nicht die Summe. Multi-Perspektive-Analyse — derselbe Input einem Finanzanalysten-Prompt, einem Rechtsprüfer-Prompt und einem Produktstrategen-Prompt gegeben, mit Rahmen, die ehrlich unterschiedlich genug sind, dass die Ausgaben nicht nur kosmetische Varianten sind. Ensembling für Verlässlichkeit — derselbe Prompt über mehrere Agenten mit gewählten oder gemittelten Ausgaben, vertretbar, wenn falsche Antworten viel teurer sind als eine dreifache Tokenrechnung.

Der Kombinationsschritt ist, wo Ingenieurarbeit sich lohnt. Naive Synthetisierer mit langen, widersprüchlichen Eingaben werden zum Flaschenhals. Drei Muster verbessern ihn: strukturierte Zwischenausgaben, sodass der Synthetisierer Felder deterministisch mergt statt Prosa zu re-lesen; hierarchische Reduktion, sodass jeder Kombinationsagent eine begrenzte Anzahl Eingaben sieht, wenn der Fan-Out wächst; und Konfliktdarstellung, sodass der Synthetisierer Meinungsverschiedenheiten markiert statt still eine Seite zu wählen.

Die diagnostische Frage, ob Scatter-Gather richtig ist: wenn ich einem parallelen Agenten sagte, was ein anderer gerade produziert, würde das seine Ausgabe ändern? Wenn ja, war die Arbeit nicht unabhängig und das Muster ist falsch — du brauchst entweder sequenzielle Abhängigkeiten oder die dynamischen Muster aus Kapitel 7.

6.4 Die ehrliche Mathematik der Koordination

Jedes Orchestrierungsmuster ist zur Laufzeit ein verteilter Workflow über unzuverlässige Worker. Pro-Aufruf-Fehlerraten von 1–5% sind selbst bei Qualitätsmodellen typisch — JSON-Parse-Fehler, Vertragsverletzungen, halluzinierte Werkzeugnamen, stille Skips. Durch eine Pipeline multipliziert ergibt 2% pro Stage bei acht Stages 85% End-to-End. Die Minderungen sind strukturell: Pro-Stage-Validierung, die begrenzte Retries auslöst; Pro-Stage-Observability, die Inputs, Outputs, Latenz, Tokenkosten und welche Validierungsgates bestanden wurden, festhält; und begrenztes Fallback, sodass ein erschöpftes Retry-Budget elegant degradiert statt den ganzen Flow zu kollabieren.

Latenzbudgets brauchen eine Decke, nicht nur einen Boden — Nutzern ist der Durchschnitt egal, sie kümmern sich um den langen Schwanz. Kostenbudgets brauchen vorab ein Modell: eine Zwei-Stage-Pipeline kostet ~1,5x ein Ein-Stage-Äquivalent, Scatter-Gather über fünf Zweige 5–8x, Roundtables 10x oder mehr. Manche Systeme sind im Maßstab nicht tragfähig, weil ihre Pro-Interaktion-Kosten den Wert übersteigen. Mach die Arithmetik beim Design, nicht nach der Rechnung.

Was Kapitel 6 vorbereitet

Sequenziell und nebenläufig sind die Bausteine. Sie decken die meisten Multi-Agent-Anwendungsfälle ab, wenn die Aufgabentopologie vorab bekannt ist und die Rollen der Worker fest sind. Beide teilen eine Annahme: jemand hat beim Design entschieden, was die Agenten sind und wie sie verbunden werden. Die Orchestrierung ist statisch; die Pipeline wird gezeichnet, bevor irgendein Nutzerrequest eintrifft. Kapitel 7 nimmt diese Annahme weg.

Als Nächstes — Kapitel 7: Fortgeschrittene kollaborative und dynamische Muster. Roundtables, Handoff-Routing und magentische Orchestrierung — was passiert, wenn die Topologie pro Request statt pro Design gebaut werden muss, und die Fehlermodi (Nicht-Terminierung, Fehlrouting, durchgegangenes Planen), die die einfacheren Muster vermeiden.