18.06.2025 AI Engineering 5 Minuten Lesezeit

Die Multi-Agenten-Debatte: Warum beide Seiten recht haben

Am 12. und 13. Juni 2025 veröffentlichten Cognition und Anthropic scheinbar gegensätzliche Empfehlungen zu Multi-Agenten-Systemen. Wir vergleichen "Don't Build Multi-Agents" mit Anthropics Research-System-Post — 90,2 Prozent Verbesserung bei rund 15-fachen Token-Kosten — und leiten eine Entscheidungsregel ab: zerlegbare Breite parallelisieren, Arbeit mit geteiltem Kontext einsträngig halten.

Zwei Posts in 24 Stunden

Am 12. Juni 2025 veröffentlichte Cognition — das Unternehmen hinter dem Coding-Agenten Devin — den Essay "Don't Build Multi-Agents". Einen Tag später publizierte Anthropic "How we built our multi-agent research system" und berichtete, ein Multi-Agenten-System habe einen einzelnen Agenten in einer internen Research-Evaluation um 90,2 Prozent übertroffen. Zwei erfahrene Engineering-Teams, zwei Produktionssysteme — und innerhalb von 24 Stunden zwei scheinbar entgegengesetzte Empfehlungen. Die Posts wurden sofort als Debatte über den richtigen Bau agentischer Systeme gelesen.

Die eigentliche Frage ist eng und technisch: Wann verbessert das Aufteilen einer Aufgabe auf mehrere LLM-Agenten mit getrennten Kontextfenstern die Ergebnisse — und wann verschlechtert es sie? Beide Posts argumentieren aus gemessener Produktionserfahrung, nicht aus Intuition. Nebeneinander gelesen widersprechen sie sich deutlich weniger, als die Schlagzeilen nahelegen. Sie beschreiben unterschiedliche Aufgabenklassen.

Eine Aufgabe kommt an — der Agent plant den nächsten Schritt. 1/4

Das Plädoyer gegen Multi-Agenten

Walden Yans Essay ist ein Argument über Zuverlässigkeit. Er formuliert zwei Prinzipien. Erstens: Kontext teilen — vollständige Agent-Traces, nicht nur einzelne Nachrichten. Zweitens: Aktionen tragen implizite Entscheidungen, und widersprüchliche Entscheidungen erzeugen schlechte Ergebnisse. Parallele Subagenten, die die Arbeit der jeweils anderen nicht sehen, treffen inkompatible implizite Entscheidungen. Yans Beispiel ist ein Flappy-Bird-Klon: Ein Subagent baut den Vogel, ein anderer den Hintergrund — heraus kommen zwei visuelle Stile, die nicht zusammenpassen.

Seine Empfehlung ist ein einsträngiger, linearer Agent. Wächst der Trace über das Kontextfenster hinaus, nutzt Cognition ein dediziertes Modell, das die Historie auf Schlüsseldetails komprimiert — keinen zweiten autonomen Agenten. Yan zeigt auch, wie Zurückhaltung in der Praxis aussieht: Claude Code startet mit Stand Juni 2025 Subagenten nur, um klar umrissene Fragen zu beantworten, nie um parallel Code zu schreiben. Sein Urteil für 2025: Kollaboration zwischen Agenten erzeugt fragile Systeme, weil die Kontextübergabe zwischen Agenten ungelöst ist.

Die Orchestrator-Worker-Antwort

Anthropics Post beschreibt die Architektur hinter der Research-Funktion in Claude: ein Orchestrator-Worker-Muster, das das Unternehmen bereits im Dezember 2024 in "Building effective agents" definiert hatte. Ein Lead-Agent auf Basis von Claude Opus 4 analysiert die Anfrage, sichert einen Plan im Memory und startet drei bis fünf Claude-Sonnet-4-Subagenten, die parallel und mit jeweils eigenem Kontextfenster das Web durchsuchen. Die Subagenten liefern verdichtete Befunde zurück; der Lead synthetisiert; ein Citation-Agent belegt jede Aussage mit einer Quelle.

Das gemessene Ergebnis: Das Multi-Agenten-System übertraf den einzelnen Claude-Opus-4-Agenten in Anthropics interner Research-Evaluation um 90,2 Prozent. Das kanonische Beispiel ist eine Breitenanfrage — alle Vorstandsmitglieder der IT-Unternehmen im S&P 500 identifizieren —, die sich sauber zerlegen lässt und ein einzelnes Kontextfenster von 200.000 Token übersteigt. Parallele Subagenten und parallele Tool-Aufrufe verkürzten die Recherchezeit komplexer Anfragen um bis zu 90 Prozent. Anthropic ist ebenso offen bei den Fehlermodi: Frühe Versionen starteten Dutzende Subagenten für simple Anfragen und suchten endlos nach nicht existierenden Quellen.

Was die Zahlen wirklich sagen

Anthropic benennt den Mechanismus explizit — und es ist keine emergente Intelligenz, sondern Token-Budget. In der Analyse des BrowseComp-Benchmarks erklärten drei Faktoren 95 Prozent der Leistungsvarianz; der Token-Verbrauch allein erklärte 80 Prozent, die Anzahl der Tool-Aufrufe und die Modellwahl den Rest. Eine Multi-Agenten-Architektur ist in erster Linie ein Weg, mehr Tokens für ein Problem auszugeben, als ein einzelnes Kontextfenster zulässt.

Die Kostenseite ist mit derselben Präzision beziffert. Agenten verbrauchen etwa das 4-Fache der Tokens einer Chat-Interaktion; Multi-Agenten-Systeme etwa das 15-Fache. Eine Verbesserung um 90,2 Prozent zum 15-fachen Token-Preis ist ein Tausch, kein Geschenk. Anthropic zieht die Konsequenz selbst: Die Ökonomie funktioniert nur bei Aufgaben, deren Wert den Aufwand rechtfertigt.

Zerlegbare Breite vs. geteilter Kontext

Beide Teams ziehen dieselbe Grenze — von entgegengesetzten Seiten. Anthropics Post räumt den Cognition-Fall nahezu wörtlich ein: Domänen, in denen alle Agenten denselben Kontext teilen müssen oder viele Abhängigkeiten zwischen Agenten bestehen, passen heute schlecht — die meisten Coding-Aufgaben eingeschlossen. Cognitions Essay räumt die Umkehrung ein: Read-only-Subagenten, die begrenzte Fragen beantworten, sind nützlich — gerade weil ihre Befunde keine widersprüchlichen Schreibentscheidungen tragen.

Die Trennlinie ist die Abhängigkeitsstruktur der Aufgabe. Breitensuche, die in unabhängige Read-only-Teilaufgaben zerfällt — Recherche, Quellen-Triage, Auswertung über viele Dokumente — parallelisiert gut; getrennte Kontextfenster werden zum Vorteil. Schreiblastige Arbeit, in der jeder Schritt implizite Entscheidungen enthält — Code-Änderungen, Refactorings, ein Dokument mit einer Stimme — braucht einen einzigen Strang geteilten Kontexts. Die Architektur sollte der Aufgabe folgen, nicht dem Trend.

Eine Entscheidungsregel vor dem Bau

In unseren Agentenprojekten bei Blue IT Systems verdichten wir beide Posts zu drei Fragen, die wir stellen, bevor ein zweiter Agent hinzukommt. Sind die Teilaufgaben wirklich unabhängig? Sind die Ausgaben der Subagenten Lesezugriffe — Berichte, Listen, Zitate — statt Schreibzugriffe? Deckt der Wert der Aufgabe rund eine Größenordnung mehr Tokens? Dreimal Ja rechtfertigt ein Orchestrator-Worker-Design. Ein einziges Nein bedeutet: ein Strang, besseres Context Engineering.

Die Checkliste erfasst nicht alles. Sie ignoriert Latenz, die Parallelität auch bei gleicher Qualität verbessert, und sie ignoriert Betriebskomplexität: Multi-Agenten-Systeme sind schwerer zu evaluieren und zu debuggen, weil sich Nichtdeterminismus über Agenten hinweg verstärkt. Anthropics Post ist in beiden Punkten offen. Behandeln Sie die drei Fragen als Filter, nicht als Beweis.

Kriterium	Orchestrator-Worker	Ein Strang
Aufgabenform	Breitensuche, zerlegbar	Sequenziell, voneinander abhängig
Subagenten-Ausgabe	Read-only-Befunde	Schreibzugriffe und Edits
Kontextbedarf	Passt in Einzelfenster	Muss durchgehend geteilt sein
Token-Kosten vs. Chat	ca. 15x	ca. 4x
Typischer Fehler	Lücken oder doppelte Abdeckung	Kontextüberlauf

Was nach der Debatte kommt

Aus Sicht vom Juni 2025 erwarten wir, dass sich die Trennung zunächst verfestigt, bevor sie sich auflöst. Research-artige Produkte werden Orchestrator-Worker-Muster übernehmen, weil die Ökonomie von Breitenanfragen sie trägt. Coding-Agenten bleiben einsträngig und investieren in Kontextkompression. Bemerkenswert: Beide Posts benennen dasselbe offene Problem — zuverlässige Kontextübergabe zwischen Agenten. Yan erwartet die Lösung als Nebenprodukt besserer Kommunikation einzelner Agenten; Anthropic erwartet Modelle, die besser delegieren und koordinieren.

Zahlen wie 90,2 Prozent und 15x werden dem Feld mehr nützen als jedes Framework-Release, weil sie Architektur zu einer Entscheidung mit Kostenmodell machen. Was keiner der beiden Posts löst, ist paralleles Schreiben: Solange Agenten implizite Entscheidungen nicht miteinander aushandeln können, bleibt der sichere Standard ein Schreiber und viele Leser. Prognosen in diesem Feld altern in Monaten. Diese beiden Posts, denken wir, bleiben länger lesbar als die meisten.