Wenn KI-Agenten arbeiten: Was Orchestrierung in der Praxis wirklich kostet

Im Juni 2026 legt SAP ein Paper vor, das sich liest wie eine Warnung an alle, die gerade eine KI-Agenten-Plattform bauen. Unter dem Titel «Autonomous Event-Driven Multi-Agent Orchestration for Enterprise AI at Scale» vergleicht es DAG-Plan-and-Execute mit ReAct auf 208 synthetischen, aus Produktionsdaten abgeleiteten Szenarien mit deterministischen Mock-Agenten, einem Single-Worker-Executor und ohne persistentes Memory. Die Bandbreite reicht von Persona-Setups mit weniger als zehn Agenten bis zu Enterprise-Setups mit 200 Agenten. Ergebnis: Bei kleinen Setups funktionieren beide Ansätze passabel, Korrektheitswerte zwischen 74 und 98 Prozent. Bei 200 Agenten kippt das Bild. Die DAG-Planung, also die vermeintlich saubere, im Voraus geplante Ausführung, verliert im Failure-Handling deutlich an Boden: Rund 94 Prozent Korrektheit bei kleinen Setups fallen auf 32 Prozent bei Enterprise-Scale. Gleichzeitig wächst das 95-Prozent-Konfidenzintervall von ±10,3 auf ±30,1 Prozentpunkte. Auf komplexen Aufgaben bei Enterprise-Scale erreicht ReAct 82 Prozent, DAG 73 Prozent. Und dann dieser Satz aus dem Paper, der die ganze Debatte verdichtet: Die Planungsvorteile von DAG erodieren, sobald die Discovery über 200 Agenten unzuverlässig wird und teure Replanning-Zyklen erzwingt.

Das ist keine akademische Fussnote, wohl aber ein Befund unter kontrollierten Bedingungen, nicht das Produktionsgesetz. Er passt trotzdem zu einer zweiten Studie, die im März 2025 erstmals erschienen war und in ihrer aktuellen Fassung vom Oktober 2025 dokumentiert, dass Multi-Agent-Systeme eine eigene Fehlerklasse produzieren, die es bei Single-Agents so nicht gibt. Gleichzeitig hat sich die Plattformseite weiterbewegt: Die GPT-5.6-Familie koordiniert in einer Responses-API-Beta parallele Subagents. Claude Fable 5 ist in Agent-Harnesses wie Claude Code oder Claude Managed Agents für tageweise laufende Arbeit mit Delegation und Selbstprüfung ausgelegt. Das macht Orchestrierung leistungsfähiger. Es macht sie nicht kostenlos. Die Rechnung kommt selten sauber auf der API-Abrechnung. Sie kommt in der Architektur.

Delegation muss ihren Nutzen beweisen

Multi-Agent-Orchestrierung ist im Juli 2026 keine Notlösung für schwache Modelle mehr. Die GPT-5.6-Plattform und Fable-Harnesses können delegieren, lange Abläufe halten und Ergebnisse zusammenführen. Gerade deshalb lautet die härtere Architekturfrage: «Verbessert Delegation auf dieser Aufgabe messbar Qualität oder Laufzeit gegenüber einem einzelnen Frontier-Agenten?» Ohne diesen Nachweis erweitert Multi-Agent nur die Systemoberfläche.

Eine Klasse ist empirisch gut gestützt: sauber teilbare, unabhängige Workstreams mit zentraler Synthese. Eine zweite zeichnet sich ab: lange, mehrstufige Aufgaben mit überprüfbaren Teilprodukten und einem verantwortlichen Hauptagenten. Für dieses zweite Muster liefern Fable-Harnesses eine plausible Anbieterthese, aber noch keinen unabhängigen Eval-Nachweis. Beide Klassen werden weiter unten eingeordnet

Anthropic hatte die erste Klasse bereits im Juni 2025 in seinem Multi-Agent-Research-System beschrieben: Subagents parallelisieren die Suche und komprimieren ihre Ergebnisse für den Lead-Agent. Harnesses mit Fable 5 erweitern dieses Muster 2026 auf tageweise laufende, mehrstufige Projekte mit Delegation und Selbstprüfung. OpenAI beschreibt die Multi-Agent-Beta der GPT-5.6-Familie ähnlich eng für komplexe Aufgaben, die sich sauber in unabhängige Workstreams zerlegen lassen. Die neue Plattformgeneration erweitert damit den sinnvollen Bereich. Sie widerlegt die Bedingung klarer Arbeitsteilung nicht.

Die eigene Fehlerklasse orchestrierter KI-Agenten

Wer die MAST-Studie liest, die im März 2025 erstmals erschienen und zuletzt Ende Oktober 2025 aktualisiert wurde, spürt, wie sich die Argumente für «mehr Agenten gleich mehr Leistung» leise auflösen. Die Autoren annotierten 1.642 Execution Traces aus sieben Open-Source-Frameworks, darunter ChatDev, MetaGPT, HyperAgent und AppWorld. Herausgekommen ist eine Taxonomie mit 14 Failure Modes in drei Kategorien. System Design Issues machen 41,8 Prozent aus, Task Verification 21,3 Prozent, und dazwischen liegt eine Kategorie, die in Single-Agent-Systemen strukturell nicht vorkommt: Inter-Agent Misalignment mit 36,9 Prozent.

Die Zahlen aus der Studie sind ernüchternd. AppWorld schafft eine Fehlerrate von 86,7 Prozent, AG2 landet bei 59 Prozent, selbst das häufig zitierte MetaGPT liegt bei 40 Prozent. Einfache Interventionen wie explizite Rollenspezifikation oder ein zusätzlicher Verification-Schritt bringen maximal 15,6 Prozentpunkte Verbesserung. Der grössere Hebel liegt in der Architektur, Prompt-Tuning allein reicht nicht. Und selbst erfolgreiche Runs sind, so formulieren es die Autoren, nicht fehlerfrei; Failure Modes tauchen auch in Traces auf, die am Ende ein akzeptables Ergebnis liefern.

Ein weiterer Befund ist heute nur noch historisch einzuordnen. Im damaligen MAST-Setup zeigte GPT-4o weniger System-Design- und Misalignment-Fehler als Claude 3.7 Sonnet; die getesteten Open-Source-Modelle lagen dahinter. Das ist im Juli 2026 keine belastbare Rangliste aktueller Modelle. Relevant bleibt etwas anderes: Dieselben Fehlerklassen traten über mehrere Modellfamilien hinweg auf, und die Autoren mutmassen, dass reine Modellverbesserungen sie nicht schliessen werden. Die Aussage betrifft die Koordination, nicht die heutige Modellwahl.

Vier Architekturen, ein Trade-off

Die zweite empirische Grundlage liefert eine NYU-Studie vom März 2026, die vier Multi-Agent-Muster auf 10.000 SEC-Filings mit 25 Feldtypen und fünf verschiedenen LLMs vergleicht. Sequential, Parallel Fan-Out, Hierarchical Supervisor-Worker und ein reflexiver Self-Correcting-Loop treten gegeneinander an. Der reflexive Ansatz erreicht die höchste Accuracy, F1 von 0,943. Er kostet aber 2,3 Mal so viel wie die sequenzielle Baseline und produziert ein p99-zu-p50-Latenzverhältnis von 3,34. Für die meisten Unternehmen zahlt sich das nicht aus. Ein wichtiger Vorbehalt: Getestet wurden Modellversionen und API-Preise mit Stand Januar 2025, darunter Claude 3.5 Sonnet, GPT-4o und Gemini 1.5 Pro. Auch diese Studie taugt deshalb als Architektur- und Skalierungstest, nicht als Empfehlung für die Modellwahl im Juli 2026.

Der Hybrid, den die NYU-Autoren als hierarchisch-optimiert bezeichnen, erreicht laut Paper 89 Prozent der Accuracy-Vorteile bei nur dem 1,15-Fachen der sequenziellen Baseline-Kosten. Der Trend ist klar: Der reflexive Loop skaliert nicht. Ab etwa 25.000 Dokumenten pro Tag degradiert er messbar. Bei 50.000 Dokumenten fällt Reflexive mit 0,898 erstmals unter Hierarchical mit 0,907. Bei 100.000 sinkt Reflexive auf 0,871, Hierarchical auf 0,891; Parallel ist dort mit 0,898 die beste Architektur.

Der dominante Failure Mode im reflexiven Setup trägt den nüchternen Namen Ambiguous Disclosure Resolution und macht 39,3 Prozent der Fehler aus. Übersetzt: Der Loop oszilliert zwischen Interpretationen und findet keinen Abschluss. Bei der sequenziellen Architektur dominieren Cross-Table-Reference-Failures mit 28,4 Prozent. Und die Rate der reinen Agent-Coordination-Failures wächst konsistent mit der Komplexität: 8,1 Prozent bei parallelem Fan-Out, 12,4 Prozent hierarchisch, 14,2 Prozent reflexiv. Jede zusätzliche Koordinationsschicht bringt ihren eigenen Fehleranteil mit.

Zwei Optimierungen aus dem Paper verdienen den Weg in jede Architekturskizze. Semantisches Caching senkt die Kosten um 34,5 Prozent, kostet dabei nur 0,005 F1. Ein zweistufiges Modell-Routing, das billigere Modelle für einfache Felder einsetzt, reduziert die Gesamtkosten um 51,3 Prozent und hält 98,2 Prozent der F1-Performance. Wer beides kombiniert, spart mehr als die Wahl der Multi-Agent-Architektur je einbringt. Das ist die eigentliche Ökonomie der Orchestrierung.

Was die Community nicht sehen will

Die AssetOpsBench Challenge liefert einen dritten Blickwinkel, der wehtut. 149 Teams treten mit Multi-Agent-Setups gegen industrielle Physical-Assets-Szenarien an. Das Ergebnis der Meta-Analyse ist ernüchternd: Die öffentliche Execution-Rangliste sagt die versteckte Testperformance statistisch nicht vorher. Spearman-Rho liegt bei minus 0,13 mit n gleich 13 und p gleich 0,71. Bei nur 13 ausgewerteten Execution-Teams ist das ein suggestiver Befund, kein präziser Effekt. Ohne die versteckte Bewertung wäre das öffentliche Ranking, so formulieren es die Autoren, nicht von einer zufälligen Anordnung zu unterscheiden.

Zweite unbequeme Zahl aus derselben Analyse: Single-Agent-Executions verbrauchen im Schnitt 121.000 Tokens, Multi-Agent-Setups nur 63.000. Statistisch hochsignifikant, t-Wert von 7,18. Das klingt zunächst wie ein Argument für Multi-Agent. Aber die Autoren fügen sofort an, dass Tokenverbrauch nicht mit Wanduhr-Dauer korreliert. Multi-Agent produziert Latenzkosten, die keine Token-Rechnung abbildet. Wer nur auf die API-Kosten schaut, misst am falschen Ende.

Der dritte Befund aus der Challenge sitzt tiefer. Die zugänglichen Top-Artefakte setzen primär auf das, was die Autoren Guardrail-Engineering nennen: Fallbacks, Context Control, Response Cleanup, statt auf neue Orchestrierungsarchitektur. Halluzinationsraten korrelieren in der Meta-Analyse stark negativ mit Qualität, Pearson-r rund minus 0,93. Und 17,7 Prozent aller Submissions scheitern schon an Infrastruktur- oder Konformitätsprüfungen, bevor irgendein Agent bewertet wird. Das ist noch kein Beweis, dass Ops der grösste Posten in Produktion ist. Es ist ein deutlicher Hinweis, dass die Ops-Schicht dort, wo Multi-Agent-Systeme in einer realistischen Umgebung antreten, ein eigener Ausfallpfad ist.

Die Diagnose: drei Posten, die zusammen die Rechnung ergeben

Zusammengenommen ergibt sich ein Diagnoseraster, das brauchbarer ist als jedes Framework-Vergleichsdiagramm. Der erste Posten ist die Handoff-Tax. Agentenübergänge können Kontext duplizieren, komprimieren oder verlieren; moderne Runtimes mit gemeinsamem State, Prompt-Caching und persistiertem Reasoning reduzieren diesen Effekt, beseitigen ihn aber nicht. Bei kleinen Setups mit weniger als zehn Agenten liegt der Aufwand nach den SAP-Zahlen bei drei- bis fünftausend Tokens pro Event. Bei 200 Agenten sind es 20.000 bis 55.000. Die Gesamtkosten wachsen zwar sublinear zur Pool-Grösse, immerhin drei- bis viereinhalbfach beim Sprung von Persona- zu Enterprise-Scale. Wer lokal auf einem DGX-Spark-artigen Setup fährt, macht Tokens billiger. Koordination, Latenz und Recovery werden dadurch nicht automatisch billiger.

Der zweite Posten ist die Inter-Agent-Fehlerklasse. In Single-Agent-Setups fehlt ihr strukturell die Grundlage, in den von MAST untersuchten Multi-Agent-Frameworks tauchte sie durchgängig auf. MAST beziffert sie auf 36,9 Prozent aller Failures im annotierten Sample. Neuere Frontier-Modelle dürften einzelne Fehlertypen reduzieren; für die aktuellen GPT-5.6- und Fable-Orchestrierungspfade liegt aber noch kein vergleichbarer Nachweis vor, dass sie diese Klasse als Ganzes beseitigen. Wer sie ignoriert, plant seine Recovery-Strategie ohne belastbare Evidenz.

Der dritte Posten ist Ops-Komplexität. Die AssetOpsBench-Analyse zeigt, dass die zugänglichen Top-Artefakte einen erheblichen Teil ihres Codes in Guardrails investieren: semantisches Caching, Modell-Routing, Fallback-Ketten, Retries, Kontextkontrolle. Modellnative Orchestrierung kann davon Infrastruktur abstrahieren. Beobachtbarkeit, Freigaben, Fehlerbehandlung und Evaluation verschwinden nicht. Wie stark dieser Aufwand mit der Zahl der Agenten wächst, hängt von Topologie und Runtime ab; ein belastbares allgemeines Skalierungsgesetz gibt es nicht.

Was GPT-5.6 und Fable an der Rechnung ändern

Die erste Änderung ist technisch. GPT-5.6 verbindet langes Kontextfenster, persistiertes Reasoning und Programmatic Tool Calling mit einer Multi-Agent-Beta für die gesamte Modellfamilie. Für begrenzte Tool-Abläufe kann ein einzelner Modelllauf Zwischenresultate verarbeiten, ohne jeden Schritt an einen neuen Agenten zu delegieren. Für sauber teilbare Aufgaben kann ein Root-Agent parallele Subagents koordinieren und ihre Ergebnisse synthetisieren. Fable 5 verschiebt in Harnesses wie Claude Code und Claude Managed Agents die andere Grenze: lange, asynchrone Projekte, Planung über mehrere Stufen, Delegation und Selbstprüfung. Architekturwahl wird damit eine Eval-Frage, keine Capability-Frage.

Die zweite Änderung ist ökonomisch und regulatorisch. Modellanbieter ziehen Orchestrierung in die Plattform und können State, Caching und Scheduling effizienter integrieren als eine lose Kette externer Agenten. Das senkt Reibung, verschiebt aber Lock-in, Beobachtbarkeit und Kostenkontrolle zum Provider. Für regulierte DACH-Workloads kommt eine konkrete Asymmetrie hinzu: Anthropic verlangt für Fable 5 eine 30-tägige Datenaufbewahrung zur Sicherheitsüberwachung. OpenAI dokumentiert Programmatic Tool Calling als ZDR-kompatibel, sofern ZDR für Organisation oder Projekt aktiviert und der gesamte Request dafür qualifiziert ist. Das ist kein direkter ZDR-Nachweis für die Multi-Agent-Beta, zeigt aber, dass bereits die Wahl des Orchestrierungspfads Daten-Governance verändert.

Lokale Inferenz setzt den Gegenakzent. In unserer DGX-Spark-Analyse vom Mai hatte ich argumentiert, dass Tokens lokal wirtschaftlich anders zu bewerten sind. Das gilt weiter. Ein DGX Spark macht jedoch weder Fehlrouting noch Recovery gratis. Der Sicherheitsdiskurs, den wir zu LangSmith-Sandboxes geführt hatten, bleibt Voraussetzung, keine Kür.

Die zwei Klassen, in denen es sich rechnet

Die erste Klasse ist echte Parallelität: Recherche über breite Korpora, unabhängige Klassifikation vieler Dokumente oder die Bewertung mehrerer Optionen, die sich nicht gegenseitig bedingen. Dafür liefern die Studien, Anthropics Research-System, Cognitions Read/Write-Muster und die GPT-5.6-Multi-Agent-Beta eine belastbare Linie.

Eine zweite Klasse zeichnet sich bei langen, mehrstufigen Vorhaben mit klaren Teilprodukten ab: Migrationen, komplexe Implementierungen oder Wissensarbeit, bei denen ein Hauptagent Aufgaben abgrenzt, Zwischenresultate prüft und die Schreibhoheit behält. Fable-Harnesses sind dafür gebaut; ob sie gegenüber einem einzelnen Fable-Lauf messbar gewinnen, muss ein unabhängiger Eval aber erst zeigen.

Vier Bedingungen entscheiden: Die Teilaufgaben müssen unabhängig oder klar sequenzierbar sein. Jeder Subagent braucht ein überprüfbares Ergebnis. Ein Hauptagent oder deterministischer Merge-Prozess muss Owner des Endprodukts bleiben. Und der Qualitäts- oder Laufzeitgewinn muss Handoffs, zusätzliche Tokens und Recovery-Aufwand tragen. Die SAP-Werte von 20.000 bis 55.000 Tokens pro Enterprise-Event sind kein allgemeiner Preis für moderne Systeme, aber eine Warnung vor unbegrenzter Agentenzahl.

Ein pragmatischer Bonus, der aus dem SAP-Paper hervorgeht: Ein einfacher Task Manager, der Prioritäten verwaltet und Merge-Konflikte auflöst, senkt die High-Priority-Queue-Latenz um 14 bis 75 Prozent und verbessert die Merge-Korrektheit um mehr als 20 Prozentpunkte. Das ist keine neue Architektur, das ist gutes Systems Engineering. Wer diese Grundschicht baut, gewinnt mehr als jeder Prompt-Trick.

Stand Juli 2026: Delegation muss sich beweisen

Die Entwicklung, die noch wie eine Prognose klang, ist bereits da. GPT-5.6 bietet langes Kontextfenster und API-integrierte Parallelisierung; Fable-Harnesses tageweise laufende Agentenarbeit mit Subagents. Damit verliert die Zahl der Agenten als Qualitätsmerkmal endgültig ihren Sinn. Entscheidend sind Erfolgsrate, Wallclock-Dauer, Kosten, Korrekturbedarf und die Qualität des Endprodukts im direkten Vergleich mit einem einzelnen Frontier-Agenten.

Der Default sollte deshalb «Baseline zuerst» heissen. Ein starker Einzelagent mit passenden Tools und genügend Kontext setzt die Referenz. Sols Kontextfenster von 1,05 Millionen Tokens macht Zerlegungen, die früher nur dem Kontextlimit geschuldet waren, in vielen Fällen überflüssig und erhöht damit die Messlatte für Delegation. Sie kommt hinzu, wenn sie in wiederholbaren Evals mindestens eine relevante Dimension verbessert, ohne Sicherheit oder Nachvollziehbarkeit zu verschlechtern. Neue Modellfähigkeiten verschieben diese Grenze fortlaufend; sie schaffen die Messpflicht nicht ab.

Wer heute plant, sollte den Vergleich hart durchziehen. Zuerst die Aufgabe und Erfolgsmetrik beschreiben. Dann eine Single-Agent-Baseline messen. Danach prüfen, ob unabhängige Parallelität oder überprüfbare Teilprodukte vorliegen. Erst dann delegieren. Budget für Evaluation, Beobachtbarkeit und Recovery gehört von Beginn an in die Rechnung. Sonst bleibt auch anbieterintegrierte Orchestrierung teures Theater mit Token-Rechnung.