Metas schlankes Orchestrator-Muster für zuverlässige KI-Agenten

Ingenieure von Meta haben die Zuverlässigkeit ihrer produktiven KI-Agenten verbessert, indem sie eine "Thin Orchestrator"-Architektur eingeführt haben, die Routing-Logik von domänenspezifischem Reasoning trennt. Die am 19. Oktober 2026 veröffentlichte Fallstudie zeigt, wie ein 1.300 Zeilen langer deterministischer Router nun über 20 Workflows in 14 spezialisierten Agenten verwaltet und Fehler aufgrund von Kontextüberlastung signifikant reduziert.

Was passiert ist

Als Meta erstmals versuchte, die Onboarding-Prozesse für Datenspalten in seinen Empfehlungssystemen zu automatisieren, baute das Team einen einzelnen KI-Agenten mit umfassendem Domänenwissen. Dieser Agent musste drei Code-Repositories, drei Programmiersprachen und bis zu sechs Pipeline-Stufen bewältigen. Während der Ansatz in kontrollierten Demos funktionierte, scheiterte er im Produktionsbetrieb aufgrund häufiger Halluzinationen. Der Agent vermischte Konzepte und wandte Namenskonventionen oder Codegenerierungsmuster aus einem Subsystem fälschlicherweise auf ein anderes an.

Das Engineering-Team erkannte, dass das Hinzufügen von mehr Kontext die Leistung verschlechterte, statt sie zu verbessern. Sie bewerteten einen alternativen Single-Agent-Ansatz, der manuelles Prompt-Engineering für jede Aufgabe erforderte. Dieser erreichte nur eine Erfolgsquote von 70–80 % bei hohem menschlichem Eingriffsaufwand und fiel ohne diesen auf 10–20 %. Unter Berufung auf Forschungsergebnisse des Windreich Department of Artificial Intelligence and Human Health am Mount Sinai stellten sie fest, dass Multi-Agenten-Systeme durch die Isolierung von Aufgaben eine höhere Genauigkeit beibehalten können, während einzelne Agenten mit Kontextinterferenzen kämpfen.

Um dies zu lösen, teilte Meta das System in zwei unterscheidbare Ebenen auf. Die erste ist ein deterministischer Orchestrator, der Intent-Klassifizierung, Feldsammlung und Zuverlässigkeitsprüfungen übernimmt, ohne selbst Domänenarbeit zu leisten. Die zweite Ebene besteht aus 14 spezialisierten Subagenten, die jeweils als vollständige Domänenexperten mit isoliertem Kontext fungieren. Beispielsweise verwaltet ein Agent Schema-Konfigurationen, während ein anderer die Code-Population für spezifische Datenquellen übernimmt. Kein einzelner Agent sieht das Gesamtbild, was die Kreuzkontamination verhindert, die das anfängliche monolithische Design plagte.

Wie es funktioniert

Der schlanke Orchestrator folgt für jede Anfrage einem festen siebenstufigen Protokoll, um sicherzustellen, dass das Reasoning großer Sprachmodelle (LLM) nur dort eingesetzt wird, wo es notwendig ist. Die Schritte eins bis fünf sowie Schritt sieben sind deterministisch: Der Router liest Anweisungsdateien, prüft auf Duplikate, sammelt Benutzerfelder, erkennt Repository-Typen automatisch und führt Zuverlässigkeits-Gates aus. Nur Schritt sechs umfasst die Delegation der Aufgabe an einen Subagenten, wobei das LLM-Reasoning innerhalb eines isolierten Kontexts stattfindet, der mit spezifischem Domänenwissen geladen ist.

Diese Architektur basiert auf Workflow-Vorlagen, die deterministische Zustandsmaschinen sind und die Sequenz der Operationen definieren. Vorlagen wie "Column Onboarding" oder "Pipeline Migration" nutzen denselben Pool von 14 Subagenten in unterschiedlicher Reihenfolge. Diese Trennung ermöglicht es dem Team, neue Fähigkeiten durch das Schreiben neuer Workflow-Vorlagen hinzuzufügen, anstatt neue Agenten zu bauen. Jeder Subagent folgt einer standardisierten Struktur mit definierten Wissensquellen, Checklisten zur Vorbereitung und Fehlerbehandlungsprotokollen, was das System modular und leicht erweiterbar macht.

Wissensdateien werden bei Bedarf zur Laufzeit geladen, anstatt im Orchestrator eingebettet zu sein. Das bedeutet, dass bei Aktualisierung einer Wissensdatei die nächste Sitzung automatisch die neueste Version verwendet, ohne dass Änderungen am Orchestrator-Code erforderlich sind. Das System verwaltet derzeit über 25 Wissensdateien, organisiert nach Workflow-Domäne, sodass Aktualisierungen sofort in allen Plattformimplementierungen wirksam werden.

Wichtige Details

• Der Orchestrator ist ein 1.300 Zeilen langer deterministischer Router, der selbst keine Domänenarbeit leistet.
• Das System leitet über 20 Workflows an 14 spezialisierte KI-Agenten weiter, jeder mit isoliertem Kontext.
• Die Konfigurationsvorbereitung für eine neue Datenspalte sank von drei bis vier Tagen manueller Arbeit auf unter eine Stunde.
• Ungefähr zwei Drittel der Systemänderungen erfolgen ohne nennenswerte manuelle Bearbeitungen.
• Workflow-Vorlagen ermöglichen die Unterstützung neuer Anwendungsfälle durch unterschiedliche Sequenzierung bestehender Agenten.
• Zitierte Forschungsergebnisse zeigen, dass Multi-Agenten-Systeme in Batches von 80 Aufgaben eine Genauigkeit von 65,3 % behielten, verglichen mit 16,6 % bei einzelnen Agenten.

Warum das wichtig ist

Für Software-Ingenieure, die produktive KI-Systeme entwickeln, verdeutlicht dieses Muster die Risiken, einen einzelnen Agenten mit zu viel Kontext zu überladen. Wenn sich die Kontextfenster vergrößern, entsteht die Versuchung, alles verfügbare Wissen in einen einzigen Prompt zu stopfen, was oft zu verringerter Leistung und Halluzinationen führt. Durch das Ziehen einer klaren Grenze zwischen deterministischem Routing und probabilistischem Reasoning können Teams Systeme erstellen, die einfacher zu debuggen und im großen Maßstab zuverlässiger sind. Fehler bleiben auf spezifische Subagenten beschränkt, wodurch verhindert wird, dass ein einzelner Fehler den gesamten Workflow korrumpiert.

Der Ansatz verändert auch, wie Teams Wartung und Updates verwalten. Da Wissen zur Laufzeit geladen wird und die Agenten strukturell einheitlich sind, wird das Hinzufügen neuer Fähigkeiten zu einer templatisierten Aufgabe, anstatt zu einer großen architektonischen Überholung. Diese Modularität ermöglicht es verschiedenen Teilen des Systems, unabhängig voneinander zu verbessern. Ein besseres zugrunde liegendes Modell verbessert alle Subagenten gleichzeitig, während Wissensupdates sofort wirksam werden, ohne den Kern-Orchestrator neu bereitstellen zu müssen.

Was Sie tun können

• Trennen Sie Routing vom Reasoning, indem Sie sicherstellen, dass Ihr Orchestrator nur deterministische Entscheidungen wie Intent-Klassifizierung trifft.
• Entwerfen Sie Subagenten als strukturell einheitliche Spezialisten mit konsistenten Eingaben, Ausführungsschritten und Fehlerbehandlung.
• Verwenden Sie Workflow-Vorlagen, um bestehende Agenten für neue Anwendungsfälle sequenziell einzusetzen, anstatt neue Agenten von Grund auf zu bauen.
• Laden Sie Domänenwissen zur Laufzeit, anstatt es in den Orchestrator einzubetten, um sofortige Updates zu ermöglichen.
• Definieren Sie die Grenze zwischen deterministischen Routing-Aufgaben und probabilistischen Reasoning-Aufgaben in Ihrer Architektur explizit.
• Isolieren Sie den Kontext für jeden Subagenten, um die Kreuzkontamination von Konzepten aus verschiedenen Domänen zu verhindern.