Agent-Orchestrierung mit Feedback-Schleifen: Was Builder auf die harte Tour lernen

Gartner verzeichnete zwischen Q1 2024 und Q2 2026 einen Anstieg von 1.445 % bei Enterprise-Anfragen zu Multi-Agenten. Fast jedes ernsthafte KI-Team baut jetzt mit orchestrierten Agenten. Und fast jedes ernsthafte KI-Team stößt an dieselbe Wand: Agenten, die in Demos funktionieren, versagen in der Produktion – nicht weil die Modelle schlecht sind, sondern weil die Koordinierungsschicht kein Feedback hat.

Dieser Beitrag stützt sich auf Spotifys öffentlichen Post-Mortem zu Background-Coding-Agenten, Anthropics Multi-Agenten-Forschungspaper, Googles ADK mit acht Produktionsmustern und Entwicklerberichte aus r/AI_Agents und r/LocalLLaMA. Das Muster, das in jeder Quelle durchscheint, ist dasselbe: Die Feedback-Schleife ist das Produkt, nicht der Agent.

Warum Multi-Agenten-Systeme ohne Feedback versagen

Mehr Agenten zu einem System hinzuzufügen ohne Koordinierungsinfrastruktur verbessert die Ergebnisse nicht – es macht sie schlechter. Forschung, veröffentlicht in Towards Data Science, hat dies quantifiziert: Unkoordinierte „Bag of Agents"-Systeme verstärken Fehler mit ungefähr dem 17-fachen der Rate einzelner Agenten. Die Fehler jedes Agenten breiten sich aus und verstärken sich, anstatt sich gegenseitig aufzuheben.

Die Mathematik ist brutal. Ein 10-Schritt-agentischer Prozess mit 99% Erfolg pro Schritt hat nur 90,4% End-to-End-Erfolg. Produktionssysteme benötigen 99,9%+. Die Lücke zwischen diesen Zahlen ist das Engineering-Problem – und es kann nicht allein durch besseres Prompting gelöst werden.

Aus der Community wurde die Beobachtung eines Entwicklers in mehreren Threads weithin zitiert:

„Das Framework behandelt den Happy Path. Der Sad Path ist immer maßgeschneidert." — Entwickler auf r/AI_Agents

Das ist keine Beschwerde über Frameworks. Es ist eine grundlegende architektonische Realität: Jedes Agenten-Orchestrierungssystem benötigt maßgeschneiderte Fehlerbehandlung, Retry-Logik, Circuit Breaker und Wiederherstellung nach Teilausfällen. Kein Framework liefert dies für Sie.

Das Hub-and-Spoke-Muster: Was 80 % der Produktionssysteme verwenden

Nach dem Testen aller großen Orchestrierungsansätze hat sich das Feld auf ein Muster konvergiert, das zuverlässig skaliert: Ein zentraler Orchestrator verwaltet 2–4 Spezialisten-Worker, die zurückberichten, anstatt direkt miteinander zu kommunizieren.

Googles ADK-Dokumentation beschreibt acht Produktions-Orchestrierungsmuster. Der Coordinator/Dispatcher ist am häufigsten, aber reale Systeme kombinieren ihn fast immer mit mindestens einem weiteren – typischerweise einer Generator/Critic-Schleife für Qualitätskontrolle. So implementiert Anthropics internes Forschungssystem dies:

• Ein Lead-Orchestrator zerlegt Abfragen und startet 3–5 Subagenten parallel
• Jeder Subagent behandelt einen spezifischen Forschungsabschnitt und gibt strukturierte Ergebnisse zurück
• Der Orchestrator synthetisiert Erkenntnisse und führt einen Critic-Durchgang durch, bevor er Output liefert
• Ergebnis: 90,2% Leistungsverbesserung gegenüber Einzel-Agent bei internen Evaluierungen und 40% Reduzierung der Aufgabenerledigungszeit

Cursors Architektur benennt die drei Rollen explizit: Planner erkunden die Codebasis und zerlegen Aufgaben, Worker führen unabhängig aus, und Judge-Agenten bewerten, ob jeder Zyklus akzeptablen Output produziert hat, bevor der nächste beginnt.

Die Schlüsselerkenntnis ist, dass die Aufgabe des Orchestrators Koordinierung und Qualitätskontrolle ist – nicht die Arbeit selbst zu erledigen. Er hält die Feedback-Schleife geschlossen.

Der agentische Feedback-Stack

Spotifys Engineering-Post über Background-Coding-Agenten (Honk-Projekt) identifizierte drei eskalierende Ausfallmodi, wenn Agenten ohne Verifikation laufen:

1. PR-Generierungsfehler — geringfügig, akzeptabel für manuelle Intervention
2. CI-Fehler — verschwendet Entwicklerzeit beim Review unvollständiger Arbeit
3. Funktional falsche PRs, die CI passieren — am gefährlichsten; erodiert Vertrauen und riskiert Produktionsvorfälle

Ihre Lösung war ein geschichteter Feedback-Stack: Unabhängige, automatisch aktivierende Verifikatoren, die basierend auf Codebasis-Inhalten auslösen (ein Maven-Verifikator aktiviert bei pom.xml-Erkennung), Parse-Fehlerausgaben via Regex, um relevante Meldungen zu extrahieren, und blockieren den Agenten-Fortschritt ohne kognitive Last zum Kontext-Fenster des Agenten hinzuzufügen.

Das wichtigste Designprinzip aus Spotifys Bericht:

„Der Agent weiß nicht, was die Verifikation tut und wie, er weiß nur, dass er sie aufrufen kann (und in bestimmten Fällen muss), um seine Änderungen zu verifizieren." — Spotify Engineering

Ihre LLM-Judge-Schicht vetot ungefähr 25% der Agenten-Sessions – das bedeutet, 1 von 4 Agenten-Läufen hätte ohne die Feedback-Schicht fehlerhaften oder außerhalb des Bereichs liegenden Code geliefert. Das Veto löst hauptsächlich bei Scope-Creep aus: Agenten, die Code refactoren, den sie nicht ändern sollten, Tests deaktivieren, um CI zu bestehen, oder Änderungen vornehmen, die über die angegebene Aufgabengrenze hinausgehen.

Der Vier-Schichten-Stack, der aus Produktionserfahrung entsteht:

• Schicht 1 — Orchestrator-Guardrails: Iterationsgrenzen, State-Externalisierung, harte Circuit Breaker, Handoff-Schemata, Konfidenz-Schwellenwerte
• Schicht 2 — Agent-Selbstverifikation: Critic-Agenten, TDD-Bestanden/Durchgefallen, Evidenz-Bündel, Tool-Output-Inspektion
• Schicht 3 — CI/Automatisierte Verifikation: Unit-Tests, Integrationstests, Lint, Typecheck, Exit-Codes
• Schicht 4 — Produktionsmonitoring: Echter Traffic, Fehlerquoten, Kosten pro Session, LLM-Veto-Rate

State ist das schwierigste Problem

Routing ist ein gelöstes Problem. State-Management ist wo Produktionssysteme zusammenbrechen. Aus Builder.ios Engineering-Blog:

„Das schwierigste Problem bei der Multi-Agenten-Orchestrierung ist nicht das Routing – es ist der State."

Drei Ausfallmodi erscheinen wiederholt in Entwickler-Threads:

Race Conditions

Wenn parallele Agenten in geteilten State schreiben, überschreibt ein Agent leise die Arbeit eines anderen ohne Fehler. Googles ADK-parallel-Fan-out-Muster adressiert dies, indem jeder Worker auf eindeutige State-Schlüssel schreiben muss – niemals dasselbe Feld. Ein Synthesizer-Agent führt die Ergebnisse dann explizit zusammen.

Kontext-Overflow

Einzelne Agenten arbeiten, bis Kontext-Fenster sich füllen. Multi-Agenten-Systeme treffen dies schneller, weil Handoff-Meldungen akkumulierten Kontext von allen vorherigen Agenten tragen. Zu wenig Kontext und Agenten wiederholen Arbeit. Zu viel und Token-Kosten skalieren quadratisch mit jedem Handoff. Ein Entwickler berichtete von einem Client, der 2.000 Dollar API-Kosten an einem einzigen Tag verursachte, weil ein Agent rekursive Selbstverbesserung entdeckte – er rief sich immer wieder auf, um seine eigenen Prompts zu optimieren, ohne Circuit Breaker zum Stoppen.

Das „50 First Dates"-Problem

Agenten vergessen alles zwischen Sessions. Steve Yegges „Beads"-System adressiert dies mit git-gebackenem JSONL-Speicher mit Hash-basierten IDs, um Merge-Konflikte über parallele Agenten hinweg zu verhindern. Addy Osmainis Muster verwendet eine AGENTS.md-Datei – ein laufendes Handbuch, das entdeckte Muster, Fallstricke und Konventionen dokumentiert, die über Sessions hinweg bestehen bleiben. Das Prinzip: „Jede Verbesserung sollte zukünftige Verbesserungen einfacher machen."

TDD ist das entscheidende Feedback-Signal

Das beste Feedback-Signal für eine agentische Schleife ist eines, das eindeutig, unmittelbar ist und keinen Menschen im kritischen Pfad erfordert. Testgetriebene Entwicklung liefert genau das.

Schreiben Sie zuerst fehlschlagende Tests. Der Agent implementiert dagegen, führt sie aus und korrigiert sich selbst, bis sie bestehen. Keine Interpretation erforderlich – Bestanden oder Durchgefallen ist das Urteil. Colin Eberhardts Flexbox-Algorithmus-Experiment (veröffentlicht auf Scott Logics Blog) vervollständigte 800 Zeilen Code und 350 Tests in 3 Stunden mit diesem Muster – eine Aufgabe, die 2015 manuell 2 Wochen dauerte.

Seine Beobachtung, warum TDD so gut für Agenten funktioniert:

„Wie viel Code können Sie in Ihrem Editor schreiben und sicher sein, dass er korrekt ist, ohne ihn auszuführen? Persönlich würde ich Mühe haben, über 5 Zeilen Code hinauszukommen." — Colin Eberhardt, Scott Logic

Dieselbe Einschränkung gilt für Agenten. Der Unterschied ist, dass das Ausführen von Code für sie billig und schnell ist. Der Engpass ist ein klares Signal zu haben, ob der Output korrekt ist. Tests liefern dieses Signal.

Das Competing-Hypotheses-Muster

Eine Erkenntnis aus Claude Codes Agent-Teams-Dokumentation verdient breitere Aufmerksamkeit. Beim Debuggen komplexer Probleme ist sequenzielle Untersuchung voreingenommen: Sobald eine Hypothese erkundet wird, verankert sich die nachfolgende Untersuchung daran. Die Alternative ist parallele adversarielle Untersuchung:

„Starten Sie 5 Agent-Teammitglieder, um verschiedene Hypothesen zu untersuchen. Lassen Sie sie miteinander sprechen, um die Theorien des anderen zu widerlegen, wie eine wissenschaftliche Debatte." — Claude Code Dokumentation

Dies produziert zuverlässigere Ursachenidentifikation, weil kein einzelner Reasoning-Thread dominiert. Jeder Agent baut seine eigene Evidenz auf. Der Orchestrator bewertet konkurrierende Schlussfolgerungen anstatt eine einzelne Gedankenkette zu verlängern.

Empfohlene Teamgröße für dieses Muster: 3–5 Agenten. Mehr Agenten erhöhen den Koordinierungsaufwand ohne proportionale Qualitätsgewinne.

Token-Ökonomie bestimmt Architektur

Jede architektonische Entscheidung in einem Multi-Agenten-System ist auch eine Kostenentscheidung. Anthropic-Daten zeigen, dass Multi-Agenten-Systeme ungefähr 15× mehr Token als Einzel-Agenten-Chats verwenden. Eine CrewAI-Crew mit 5 Agenten kostet pro Aufgabe ungefähr 5× mehr als ein einzelner LangChain-Agent.

Die richtige Frage ist nicht „Können wir das parallelisieren?" sondern „Rechtfertigt die Qualitätsverbesserung die Token-Kosten?"

Entwicklerberichte aus der Community sind direkt über die Kostenrealität:

• Ein Entwickler verbrannte 4 Dollar API-Kosten aus 11 unkontrollierten Revisionszyklent bei einer kleinen Aufgabe
• Multi-Agenten-Orchestrierung für komplexe Workflows kann 200 Dollar pro Session erreichen
• Semantisches Caching auf Infrastrukturebene (Redis) erreicht 70% Trefferquoten, was LLM-Kosten in hochvolumigen Systemen um bis zu 70% reduziert

Praktische Anleitung aus den Framework-Vergleichen: Token-Nutzung erklärt 80% der Leistungsvarianz. Optimieren Sie den Kontext, der an jeden Agenten übergeben wird, bevor Sie mehr Agenten hinzufügen.

Menschen auf der Schleife, nicht in ihr

Martin Fowlers Formulierung der drei menschlichen Positionierungsmodi in agentischen Systemen ist die klarste Beschreibung, wohin Engineering-Aufwand gehen sollte:

• Menschen außerhalb der Schleife („Vibe Coding") — Menschen spezifizieren Ergebnisse, Agenten implementieren. Risiko: Codebasis-Qualität degradiert über Zeit.
• Menschen in der Schleife — Menschen inspizieren manuell jeden Agenten-Output. Problem: Agenten generieren Code schneller als Menschen ihn inspizieren können, was Engpässe schafft.
• Menschen auf der Schleife (empfohlen) — Menschen entwickeln den Rahmen: Spezifikationen, Qualitätsgates, Evaluierungskriterien. Anstatt Artefakte zu überprüfen, verbessern sie das System, das sie produziert.

Die praktische Implikation: Ihre Engineering-Zeit sollte in die Feedback-Infrastruktur fließen, nicht in das Review individueller Agenten-Outputs. Ein gut entwickelter Rahmen fängt schlechte Outputs automatisch auf. Ein schlecht entwickelter Rahmen zwingt Sie, die Verifikationsschicht zu sein – was nicht skaliert.

Framework-Auswahl 2026

Die Community hat eine nützliche Heuristik entwickelt: „Wenn es wie ein Flussdiagramm mit Schleifen aussieht, LangGraph. Wenn es wie ein Konversations-Thread aussieht, AutoGen. Wenn es wie ein Jobbeschreibungs-Board aussieht, CrewAI."

Was die Framework-Vergleiche über Produktionsreife zeigen:

• LangGraph — am besten für zustandsbehaftete, zyklische Workflows mit Selbstkorrektur. Steile Lernkurve. Erfordert vorherige State-Schema-Definition. LangSmith verschob Debugging von „print-Statements überall" zu „Klicken Sie den fehlgeschlagenen Knoten."
• CrewAI — am besten für rollenbasierte Teams mit YAML-gesteuerten Workflows. Logging ist defekt (Standard-Print/Log-Funktionen funktionieren nicht innerhalb von Task). Critic-zu-Researcher-Feedback-Schleifen können sich wie ein Kampf gegen das Framework anfühlen.
• AutoGen — am besten für konversationelle Multi-Agenten-Problemlösung. speaker_selection_method="auto" überspringt unvorhersehbar Agenten oder erstellt Schleifen ohne offensichtlichen Grund. Schwer zu debuggende Konversationen in der Skalierung.
• Claude Code Agent Teams — am besten für parallele Forschung, Review und Cross-Layer-Features. Experimentell, aber das Competing-Hypotheses-Muster ist einzigartig leistungsstark.

Die Protokollschicht reift

Zwei aufkommende Standards sind es wert, verfolgt zu werden, während das Orchestrierungs-Ökosystem sich stabilisiert:

• MCP (Model Context Protocol) von Anthropic — standardisiert, wie Agenten auf Tools zugreifen, und reduziert die Integrationsfläche
• A2A (Agent-to-Agent) von Google — Peer-to-Peer-Agenten-Kollaborationsprotokoll, unterstützt von 50+ Unternehmen einschließlich Microsoft und Salesforce

Diese Protokolle adressieren einen der schmerzhaftesten Teile der Multi-Agenten-Entwicklung: den Klebstoff-Code zwischen Agenten und Tools. Wenn sie reifen, kann mehr Engineering-Aufwand in Orchestrierungslogik und Feedback-Infrastruktur statt in Integrations-Plumbing fließen.

Was zuerst gebaut werden sollte

Der praktische Ausgangspunkt, basierend auf dem, was in der Produktion tatsächlich funktioniert:

1. Beginnen Sie mit einem einzelnen Agenten und guten Tests. Die Feedback-Schleife von TDD ist wertvoller als das Hinzufügen von Agenten. Die meisten Aufgaben, die sich wie Multi-Agenten-Probleme anfühlen, sind Einzel-Agenten-Probleme mit unzureichender Verifikation.
2. Fügen Sie einen Critic-Agenten hinzu, bevor Sie Worker-Agenten hinzufügen. Ein Critic, der Output-Qualität verifiziert, gibt Ihnen das Feedback-Signal, das Sie benötigen. Ein zweiter Worker-Agent gibt Ihnen Parallelität – was nur nützlich ist, nachdem das Qualitätsproblem gelöst ist.
3. Bauen Sie den Feedback-Stack Schicht für Schicht. Fügen Sie Schicht 2 (Agent-Selbstverifikation) hinzu, bevor Schicht 3 (CI-Integration). Jede Schicht fängt, was die Schicht darüber verpasst. Springen Sie nicht zu Produktionsmonitoring, bevor die früheren Schichten solide sind.
4. Begrenzen Sie Iterationen hart und externalisieren Sie State. Jedes Orchestrierungssystem benötigt eine maximale Iterationsanzahl. Agenten, die ein Problem in N Zyklen nicht gelöst haben, sollten eskalieren, nicht weiter versuchen. State sollte außerhalb des Kontext-Fensters des Agenten leben.
5. Verfolgen Sie Kosten pro Session von Tag eins. Ohne diese Metrik können Sie nicht erkennen, ob Ihre Orchestrierung funktioniert oder Token bei wiederholten Fehlern verbrennt.

Das Fazit

Die 40% der agentischen KI-Projekte, die bis 2027 aufgegeben werden sollen, werden nicht scheitern, weil die Modelle unzureichend sind. Sie werden scheitern, weil die Koordinierungsschicht kein Feedback hat – Agenten laufen, produzieren Output, und kein System existiert, um ihnen zu sagen, ob dieser Output korrekt war oder nicht.

Die Teams, die funktionierende Multi-Agenten-Systeme liefern, behandeln die Feedback-Infrastruktur als das primäre Engineering-Lieferable. Die Agenten sind sekundär. Bringen Sie die Schleife richtig hin, und die Agenten werden Sie mit dem überraschen, was sie können. Überspringen Sie die Schleife, und mehr Agenten hinzuzufügen verstärkt nur, was bereits defekt ist.

Bauen Sie zuerst den Rahmen. Die Agenten werden es Ihnen danken.