Kapitel 7 — Fortgeschrittene kollaborative und dynamische Muster

Siebter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Wenn die Topologie zur Designzeit nicht gezeichnet werden kann — wenn der richtige nächste Schritt davon abhängt, was der vorherige gefunden hat — reichen die Muster aus Kapitel 6 nicht mehr.

Warum dieses Kapitel existiert

Die Muster aus Kapitel 6 teilen ein architektonisches Merkmal, das für härtere Aufgaben zur Bürde wird: die Topologie ist zur Designzeit fest. Der Entwickler zeichnet die Pipeline, benennt die Stages, entscheidet, wer wen füttert, und die Laufzeit überdenkt das nie. Für Aufgaben mit vorab bekannter Form ist das eine Stärke. Für Aufgaben mit echt emergenter Form — bei denen der richtige Spezialist davon abhängt, was die Nutzerin wirklich gefragt hat, bei denen der Plan selbst gebaut werden muss, während die Arbeit voranschreitet — wird die feste Topologie zum Käfig.

Dieses Kapitel geht die dynamischen Muster durch: Roundtables, in denen Agenten zum Konsens iterieren, Router, die zur Laufzeit gewählte Spezialisten delegieren, und magentische Orchestrierung, die Pläne baut, während die Aufgabe entsteht. Jedes kauft Fähigkeit, die die einfacheren Muster nicht bieten. Jedes führt Fehlermodi — Nicht-Terminierung, Fehlrouting, durchgegangenes Planen — ein, die die einfacheren Muster vermeiden.

7.1 Gruppenchat und Roundtable: Macher-Prüfer, Mehrteilnehmer-Konsens

Gruppenchat-Orchestrierung platziert mehrere Agenten in einem gemeinsamen Konversationskontext und lässt sie reihum sprechen. Die einfachste Form ist die Zwei-Agenten-Macher-Prüfer-Schleife: der Macher produziert einen Kandidaten, der Prüfer bewertet ihn gegen eine Rubrik, der Macher überarbeitet auf Feedback, und die Schleife terminiert auf Zustimmung oder ein Turn-Budget. Sprachmodelle sind messbar besser im Bewerten als im Produzieren, wenn beides richtig gerahmt ist — ein Modell, das in derselben Anrufung schreiben und selbst bewerten soll, neigt dazu, seinen ersten Versuch zu verteidigen; dasselbe Modell mit derselben Ausgabe in frischem Kontext mit klarer Rubrik ist deutlich kritischer.

Die ehrlichen Fehlermodi sind drei. Kollusion — teilen Macher und Prüfer Modell und Prompt, segnet der Prüfer alles ab. Die Verteidigung ist echte Rollendifferenzierung, idealerweise verschiedene Modelle. Nicht-Terminierung — ein strenger Prüfer lehnt jeden Kandidaten ab; der Orchestrator muss den besten gesehenen akzeptieren oder eskalieren. Prüferdrift — in einem geteilten Roundtable-Kontext fängt der Prüfer an, Dinge abzunicken, die er früher abgelehnt hätte, weil sich die Begründungen des Machers akkumulieren. Ein Feldbefund von Ende 2025 ist kontraintuitiv: die verlässlichsten Macher-Prüfer-Systeme verhindern, dass der Prüfer sieht, wie der Kandidat produziert wurde. Zustandslose Prüfer — nur mit Kandidat und Rubrik gefüttert — erhöhen korrekte Ablehnungen um 30–50%. Geteilter Kontext ist ein Werkzeug, kein Default.

Mehrteilnehmer-Roundtables erweitern das Muster mit mehreren Spezialisten und einem Moderator. Die Kosten wachsen rasch: Tokenkosten mit dem geteilten Transkript, Latenz mit den Turns, und Agenten, die in Tangenten hängenbleiben, sind in Produktion beobachtet. Die Disziplinen, die es zum Funktionieren bringen — Token-Limit pro Turn, strukturierte Turn-Ausgaben, explizite Terminierungsrubriken — sind der Unterschied zwischen einem produktiven Meeting und einem Meeting, das eine E-Mail hätte sein sollen.

7.2 Handoff und Routing: dynamische Delegation

Handoff-Orchestrierung verfolgt einen anderen Ansatz: jeweils ein Agent bearbeitet die Konversation, und der aktive Agent kann übergeben, wenn seine Arbeit erledigt ist oder wenn der Request in eine andere Spezialität rutscht. Der Router — üblicherweise selbst ein LLM — liest den Konversationsstand und gibt eine Routing-Entscheidung aus: „bleib beim aktuellen" oder „übergib an Spezialist X mit dieser Kontextzusammenfassung." Die Zusammenfassung ist der Vertrag zwischen Routingschicht und Spezialist.

Das schwerste Engineering-Problem ist zu erkennen, wann ein Handoff nötig ist. Fehlrouting ist der häufigste Fehler: der Router schickt eine Rechnungsfrage an den technischen Support, Support tut sein Bestes, und die Nutzerin bekommt eine verwirrte Antwort, die keines ihrer Anliegen adressiert. Verteidigungen schichten: eine Vertrauensschwelle, unter der der Router an einen Menschen abgibt, explizite „das ist nicht mein Gebiet"-Aktionen, die Spezialisten ergreifen können, und das Loggen jeder Routing-Entscheidung zur Prüfung.

Zwei weitere Fehlermodi prägen Produktionsdesign. Handoff-Schleifen — Spezialist A sendet an B, B sendet zurück an A — verteidigt durch das Erkennen wiederholter Handoffs und das Erzwingen einer anderen Auflösung. Kontextverlust — jede Handoff-Zusammenfassung verliert etwas, und der nächste Spezialist fragt vielleicht Information ab, die die Nutzerin schon gegeben hat — verteidigt durch das Speichern der vollen Konversation außerhalb des Kontexts eines jeden Spezialisten, mit der Zusammenfassung als primärer Payload und der vollen Historie auf Anfrage verfügbar. Wachsen die Spezialistenzahlen, werden flache Router spröde; das 2025 entstandene Muster ist hierarchisches Routing — ein grober Router wählt eine Kategorie, ein kategorie-spezifischer Router den Spezialisten. Zwei Ebenen sind in Produktion der Sweet Spot.

7.3 Magentische Orchestrierung: Pläne, die mit der Arbeit entstehen

Für Aufgaben, deren Zerlegung am Anfang nicht bekannt ist — untersuche, warum die Datenbank langsam ist, debugge ein unbekanntes System, recherchiere ein komplexes Thema — reicht keines der bisherigen Muster. Magentische Orchestrierung, benannt nach Microsofts Magentic-One-Framework, ist die Familie von Mustern, in denen ein Manager-Agent ein Aufgaben-Ledger hält und es aktualisiert, während die Arbeit voranschreitet. Das Ledger hat explizite Slots: das ursprüngliche Ziel, das aktuelle Verständnis (das sich verfeinern darf), offene Teilaufgaben mit Prioritäten, erledigte Teilaufgaben mit Ergebnissen, Entdeckungen, die eine Planrevision erzwingen können, und eine Stoppbedingung. Der Manager liest das Ledger in jedem Schritt, entscheidet die nächste Dispatchaufgabe und integriert die Ergebnisse zurück.

Die Stärke ist echte Offenheit. „Untersuche, warum die Datenbank langsam ist" lässt sich vorab nicht zerlegen — die nächste Teilaufgabe hängt davon ab, ob der Flaschenhals Netzwerk, Query-Plan oder Hot-Row ist. Keine feste Pipeline kommt damit klar; keine statische Handoff-Topologie könnte korrekt routen, ohne vorher zu wissen, welche Spezialitäten relevant würden.

Die Kosten sind die strengsten in diesem Kapitel auf allen Dimensionen: Latenz, Tokens, Engineering-Aufwand, operatives Risiko. Tokenkosten wachsen superlinear, weil das Ledger in jedem Turn gelesen wird. Die katalogisierten Fehlermodi sind scharf. Durchgegangenes Planen — der Manager öffnet Teilaufgaben schneller, als er sie schließt, Ledger wächst unbegrenzt. Zieldrift — während der Manager lernt, formuliert er das Ziel weg von der Absicht der Nutzerin. Plan-Churn — jeder neue Befund löst eine Planrevision aus, kein Commitment hält lange genug, um Fortschritt zu machen. Das entstandene Muster ist die begrenzte magentische Schleife: Budgets für offene Teilaufgaben, gesamte Worker-Anrufungen und Wandzeit, mit Eskalation, wenn eine Grenze gerissen wird. Produktive magentische Systeme ohne Grenzen verbrennen gelegentlich Hunderte Dollar an Tokens für Aufgaben, die der Manager innerhalb keines praktischen Budgets lösen konnte.

7.4 Wahl zwischen den Mustern

Drei Fragen wählen aus. Ist die Topologie vorab bekannt? Wenn ja, bleib bei den statischen Mustern aus Kapitel 6. Profitiert die Arbeit von Iteration gegen eine externe Prüfung? Wenn ja, ist eine Macher-Prüfer-Schleife die richtige Ergänzung — einbettbar in jedes andere Muster. Wie offen ist die Planung? Bei klaren Grenzen leistet Handoff oder Sequenz die Arbeit; wenn die Form wirklich emergent ist, ist magentic das nötige Muster, akzeptiert mit seinen Kosten.

Eine 2025er-Fallstudie aus dem Finanzdienstleistungssektor ist die lehrreiche Warnung: ein magentischer Kundenonboarding-Workflow, gewählt, weil das Team die Flexibilität des Frameworks attraktiv fand, wurde durch eine feste sequenzielle Pipeline ersetzt. Die Pro-Onboarding-Kosten sanken von etwa sieben Dollar auf achtzig Cent; die Abschlussraten verbesserten sich. Das Muster, nach dem allgemeinsten Werkzeug zu greifen, wenn ein spezifischeres reichen würde, ist in der Softwaretechnik nicht neu, und in der Multi-Agent-Orchestrierung manifestiert es sich scharf, weil die Allgemeinheit in Tokens bezahlt wird.

Was Kapitel 7 vorbereitet

Die Kapitel 6 und 7 spezifizieren, wie Agenten koordinieren. Sie spezifizieren nicht, wo die Agenten laufen, wie das Sprachmodell mit den Tools co-located ist oder wie die Deployment-Topologie auf der Ebene von Prozessen, Maschinen und Netzwerkgrenzen aussieht. Zwei Systeme mit identischen Orchestrierungsmustern lassen sich dramatisch unterschiedlich deployen — andere Latenzprofile, andere Kostenstrukturen, andere Sicherheitshaltungen. Kapitel 8 deckt diese Dimension ab.

Als Nächstes — Kapitel 8: Architektonische Deployment-Layouts. Drei grundlegend verschiedene Arten, MCP physisch zu deployen — Model-mit-Server, Model-im-Client, Hybrid — mit den realen Trade-offs in Latenz, Kosten, operativer Komplexität und den Fehlern, die jedes wahrscheinlich macht.