Die Illusion des virtuellen Unternehmens: Warum rollenbasierte Multi-Agenten-Architekturen im Engineering scheitern

**

Eine in der KI-Community weit verbreitete Architekturidee führt viele Teams in die Irre.

Das Fazit vorweg

Wenn Sie darüber nachdenken, mehrere KI-Agenten als „Produktmanager", „Architekt" und „Testingenieur" zu bezeichnen und sie wie Unternehmensabteilungen Dokumente weiterreichen und zusammenarbeiten zu lassen – hören Sie bitte damit auf.

Dieses Modell wirkt intuitiv und logisch schlüssig, hat aber grundlegende Mängel in der technischen Umsetzung. Noch wichtiger: Keiner der drei großen Anbieter – Anthropic, OpenAI und Google – verwendet dieses Modell beim Bau seiner eigenen Agent-Systeme.

Das ist kein Zufall.

Was ist die „Drei Abteilungen und sechs Ministerien"-Architektur?

Diese Metapher bezieht sich auf eine Klasse von Multi-Agent-Designideen, die in der Community weit verbreitet sind und in verschiedenen Frameworks und Artikeln unterschiedliche Namen tragen: rollenbasierte Agenten, virtuelle Teams, CrewAI-artige Arbeitsteilung oder MetaGPT-artige Organisation. Dieser Artikel bezeichnet sie gemeinsam als das „Abteilungsmodell".

Das Kernmuster ist: Zerlege eine komplexe Aufgabe in mehrere Funktionen, wobei jeder Agent eine Rolle spielt – PM für Anforderungen, Tech Lead für Architektur, Dev für Implementierung und QA für Tests. Aufgaben fließen zwischen den Agenten wie in einem Fließband.

Dieses Modell sieht in einem Diagramm großartig aus. Es befriedigt die menschliche Intuition für „Arbeitsteilung" und macht das Konzept eines „KI-Teams" konkret und erklärbar. Frameworks wie CrewAI haben deshalb viele Nutzer gewonnen.

Das Problem ist: Es löst menschliche Engpässe, nicht KI-Engpässe.

Warum diese Analogie grundlegend falsch ist

Menschen brauchen Arbeitsteilung, weil:

• Eine einzelne Person eine begrenzte Aufmerksamkeitsspanne hat und nicht alle Informationen gleichzeitig verarbeiten kann.
• Menschen berufliche Barrieren und hohe Lern-/Umstellungskosten haben.
• Menschen Schnittstellen zur Koordination untereinander benötigen.

Aber die Eigenschaften von LLMs sind völlig anders:

• Dasselbe Modell kann sowohl PRDs als auch Code schreiben; es gibt keine „beruflichen Grenzen".
• Der Engpass für Modelle ist nicht die Aufmerksamkeitsspanne, sondern die Argumentationstiefe und Informationsintegrität.
• Modelle haben keine „Kultur" und kein „stillschweigendes Verständnis", um Informationsverluste auszugleichen.

Einem Agenten das Etikett „Produktmanager" zu geben, macht ihn nicht professioneller – es bringt ihn dazu, Grenzen nicht zu überschreiten. Ein Agent, der in die Rolle eines „Testingenieurs" gezwängt wird, könnte ein Architekturproblem übersehen, weil „es nicht in meinen Zuständigkeitsbereich fällt". Die wertvollste Argumentation findet oft an den Grenzen statt, und das Abteilungsmodell versiegelt diese Möglichkeit auf Systemebene.

Rollen spielen schafft künstliche Grenzen. Das ist das erste Problem.

Das zweite Problem: Informationen sterben auf dem Weg

Im Abteilungsmodell erstellt Agent A ein Dokument und übergibt es an Agent B.

Dieser Prozess übergibt Schlussfolgerungen, nicht den Argumentationsprozess.

B erhält das Dokument, versteht es neu und baut den Kontext wieder auf. Die ursprüngliche Absicht verfällt, versteckte Annahmen gehen verloren, und jede Übergabe akkumuliert Fehler. Je länger der Workflow, desto mehr wird das Endergebnis „lokal korrekt, aber global abgedriftet" – jeder Knoten sieht vernünftig aus, aber das Ganze ist vom ursprünglichen Ziel abgewichen.

Menschliche Organisationen verlassen sich auf Meetings, Kultur und informelle Kommunikation, um diesen Informationsverlust auszugleichen. Agenten haben diese Mechanismen nicht.

Es gibt einen häufigen Einwand: Verwenden die Lösungen der drei großen Anbieter (progress.txt, Spec-Dateien, Runbooks) nicht auch „Dateiübergaben"? Was ist der Unterschied?

Der Unterschied liegt darin, wer es schreibt, für wen es bestimmt ist und wie es aktualisiert wird.

Der Informationsfluss im Abteilungsmodell ist eine Einweg-Übergabe zwischen Rollen: A ist fertig und gibt es an B; B schaut nicht zurück, und A weiß nicht, wie B das Dokument verwendet hat. Informationen werden zu Schlussfolgerungen komprimiert, der Argumentationsprozess geht verloren, und die Übergabe ist ein Bruchpunkt.

Externe Zustandsdateien sind inkrementelle Protokolle derselben Aufgabe: Die ausführende Entität hängt an jedem Kontrollpunkt an denselben Datensatz an, und die nächste Sitzung liest die vollständige Historie der Aufgabe, nicht die Ausgabeschlussfolgerung eines vorherigen „Kollegen". Die Person, die den Zustand schreibt, und die Person, die den Zustand liest, sind dieselbe Rolle, nur zu unterschiedlichen Zeitpunkten. Informationen werden nicht „komprimiert und weitergegeben", sondern „kontinuierlich akkumuliert".

Dieser Unterschied bestimmt, ob die Argumentationskette über Sitzungen hinweg kontinuierlich bleiben kann.

Eine massive Menge an Tokens wird für „Übergabedateien" zwischen Agenten verschwendet, anstatt für tatsächliche Argumentation. Sie erhalten ein System, das Unternehmensverhalten simuliert, nicht ein System, das Probleme löst.

Wie die drei großen Anbieter es tatsächlich machen

Es ist bemerkenswert, dass die technischen Dokumente von Anthropic, OpenAI und Google beim Bau ihrer produktionsreifen Agent-Systeme fast nie „Rollen spielen" oder „Abteilungsteilung" erwähnen.

Anthropic: Context Engineering + explizite Zustandsdateien

Anthropic hat „Prompt Engineering" zu „Context Engineering" aufgewertet: Die Frage ist nicht, wie man einen guten Prompt schreibt, sondern welche Token-Konfiguration am besten das gewünschte Verhalten erzeugt.

Beim Bau von Claude Code und Research-Systemen war ihre Kernherausforderung: Agenten müssen in diskreten Sitzungen arbeiten, und jede neue Sitzung hat keine Erinnerung an das, was zuvor passiert ist. Ihre Metapher sind „Schichtingenieure" – jede neue Schicht von Ingenieuren weiß nichts über die Arbeit der vorherigen Schicht.

Die Lösung besteht nicht darin, Agenten verschiedene Rollen spielen zu lassen, sondern:

• claude-progress.txt: Ein sitzungsübergreifendes Arbeitsprotokoll, das der Agent am Ende jeder Sitzung aktualisiert und zu Beginn der nächsten liest.
• Git-Historie: Dient als Zustandsanker, zeichnet jede inkrementelle Änderung auf.
• Initializer-Agent: Läuft nur in der ersten Sitzung, um die Umgebung einzurichten, die Funktionsliste zu erweitern und das Runbook für alle nachfolgenden Sitzungen zu schreiben.

Wichtige Erkenntnis: Die Kontinuität der Argumentationskette hängt nicht davon ab, dass sich das Modell „erinnert"; sie hängt von explizitem externem Zustand ab, um sie zu verankern.

Sie fanden auch heraus, dass das feste Einprogrammieren von „Modellfähigkeitsannahmen" in das Harness gefährlich ist. Sonnet 4.5 hatte „Kontextangst" – es beendete Aufgaben frühzeitig, wenn es sich der Kontextgrenze näherte, also fügten sie einen Kontext-Reset zum Harness hinzu. Aber in Opus 4.5 verschwand dieses Verhalten, und der Reset wurde zu totem Ballast. Dies zeigt, dass sich das Harness mit dem Modell weiterentwickeln muss; jede „permanente Lösung" ist nur ein technischer Kompromiss für die aktuelle Stufe.

In Multi-Agent-Research-Systemen ist die Architektur von Anthropic Orchestrator-Worker: Ein leitender Agent zerlegt Aufgaben und koordiniert Unteragenten, die verschiedene Richtungen parallel erkunden, wobei die Ergebnisse zum leitenden Agenten zurückfließen, der sie synthetisiert. Sie fanden heraus, dass der Token-Verbrauch allein 80 % der Leistungsunterschiede erklärte – der Wert von Multi-Agenten liegt nicht in der „Arbeitsteilung", sondern darin, mehr Tokens zu verwenden, um einen größeren Suchraum abzudecken.

Es gibt hier einen Punkt der Verwirrung: Die Unteragenten von Anthropic mögen wie „Arbeitsteilung" aussehen, aber der Kern ist anders. Abteilungsbildung ist funktionale Teilung – verschiedene Rollen erledigen verschiedene Arten von Arbeit (PM zu Dev zu QA). Anthropics Unteragenten sind funktionale Parallelität – mehrere identische Agenten durchsuchen gleichzeitig verschiedene Richtungen, es gibt keine „nächste Übergabe", und alle Ergebnisse konvergieren zurück zum selben Orchestrator. Ersteres ist ein Staffellauf; Letzteres ist ein weites Auswerfen von Netzen.

OpenAI: Kompaktierung + Skills + strukturierte Spec-Dateien

Die Prinzipien von OpenAI für langfristige Aufgaben sind noch direkter: Plane zu Beginn der Aufgabe für Kontinuität.

In ihren Codex-Experimenten gaben Ingenieure dem Agenten eine Spec-Datei (das Ziel einfrieren, um zu verhindern, dass der Agent etwas „Beeindruckendes, aber in die falsche Richtung" macht), ließen ihn einen meilensteinbasierten Plan erstellen und verwendeten dann eine Runbook-Datei, um dem Agenten zu sagen, wie er operieren soll. Dieses Runbook ist auch ein gemeinsamer Speicher und ein Prüfprotokoll.

Ergebnis: GPT-5.3-Codex lief etwa 25 Stunden ununterbrochen und vollendete ein komplettes Designtool, während die Kohärenz während des gesamten Prozesses erhalten blieb.

Server-seitige Kompaktierung dient als standardmäßiges Grundelement, nicht als Notfall-Ausweichlösung. Bei mehrschrittigen Aufgaben ermöglicht previous_response_id dem Modell, im selben Thread weiterzuarbeiten, anstatt jedes Mal den Kontext neu aufzubauen.

Sie führten auch das Konzept der Skills ein – wiederverwendbare, versionierte Anweisungssätze, die in Container eingehängt werden und Agenten stabile Betriebsstandards für bestimmte Aufgaben geben. Dies sind keine „Rollen"; es sind Werkzeuge und Betriebsabläufe, was grundlegend anders ist.

Google: 1M Kontext + kontextgesteuerte Entwicklung

Die Richtung von Google ist, das Fenster mit roher Gewalt zu erweitern: Der 1M-Token-Kontext von Gemini ist eine klare Differenzierungsstrategie. Ihre Logik ist, dass zuvor erzwungene Techniken wie RAG-Zerlegung und Verwerfen alter Nachrichten durch „einfach alles hineinpacken" ersetzt werden können, wenn das Fenster groß genug ist.

Aber sie geben zu, dass selbst das nicht ausreicht. Google hat die Conductor-Erweiterung für Gemini CLI eingeführt, mit einer Kernidee, die mit Anthropic identisch ist: Projektabsichten aus dem Chat-Fenster heraus in persistente Markdown-Dateien im Codebase zu verschieben. Die Philosophie: „Verlasse dich nicht auf instabile Chat-Verläufe; verlasse dich auf formale Spec- und Plan-Dateien."

Gemini 3 führte auch Thought Signatures ein: Speichern von Schlüsselknoten der Argumentationskette in langen Sitzungen, um „Argumentationsdrift" zu verhindern – das Problem der logischen Inkonsistenz in langen Kontexten.

Was sind die wahren Architekturprinzipien?

Aus den technischen Praktiken dieser drei Unternehmen lassen sich mehrere gemeinsame Prinzipien ableiten:

Die Argumentationskette darf nicht unterbrochen werden; sie kann sich nur verzweigen und wieder zusammenführen. Die korrekte Verwendung von Multi-Agenten ist kein Fließband, sondern ein Hauptagent, der die vollständige Absicht hält, mit Unteraufrufen, um tief in Teilprobleme einzutauchen, und Ergebnisse, die zum Hauptagenten zurückfließen, nicht zum nächsten Agenten weitergegeben werden.

Expliziter externer Zustand, verlasse dich nicht auf das Modellgedächtnis. Ob progress.txt, Git-Historie, Spec-Dateien oder Datenbanken – die Form spielt keine Rolle. Das Prinzip ist: Schlüsselknoten der Argumentationskette müssen in persistenten Speicher externalisiert werden.

Der Wert von Multi-Agenten liegt in paralleler Abdeckung, nicht in Arbeitsteilung. Die Schlussfolgerung des Anthropic-Research-Systems ist klar: Leistungssteigerungen kommen von „mehr Tokens ausgeben", nicht von „besserer Arbeitsteilung". Multi-Agenten eignen sich für breitenorientierte Aufgaben – Szenarien, die die gleichzeitige Erkundung unabhängiger Richtungen erfordern. Sie eignen sich nicht für Szenarien, die kontinuierliche Argumentation und tiefe Kontextabhängigkeit erfordern.

Der Verifier-Agent ist ein Verneiner, kein Staffelläufer. Wenn Multi-Agenten zur Qualitätskontrolle verwendet werden, ist das korrekte Design, einen Agenten zu haben, der speziell Probleme in der Arbeit eines anderen findet, anstatt „das Arbeitsergebnis weiterzugeben". Adversariales Testen, keine Fließbandübergabe.

Werkzeuge sind Werkzeuge, keine Rollen. Mit welchen Werkzeugen Sie einen Agenten ausstatten (Bash, Datei-I/O, Suche, Code-Ausführung) ist weitaus wichtiger als das Etikett, das Sie ihm aufkleben. Werkzeuge bestimmen, was ein Agent kann; Rollenetiketten beschränken nur, was er bereit ist zu tun.

Warum ist das „Abteilungsmodell" beliebt?

Weil es leicht zu erklären ist.

„Dieser Agent ist der PM, jener ist der QA" – jeder kann das verstehen. Es befriedigt das menschliche Verlangen nach Erklärbarkeit von KI-Systemen und die Vorstellung des Managements von „KI, die wie ein Team arbeitet".

Es ist auch leicht zu demonstrieren. Als Flussdiagramm mit Abteilungen, Pfeilen und Übergaben gezeichnet, ist es sehr intuitiv.

Aber leicht zu erklären und zu demonstrieren ist etwas anderes als technisch solide zu sein.

Ein tieferer Grund ist, dass die meisten Teams, die dieses Modell übernehmen, das Problem des „Kontextverlusts während der Multi-Agent-Übergabe" nicht wirklich erlebt haben. Ihre Aufgaben sind möglicherweise nicht komplex genug, oder das Problem wird durch andere Faktoren überdeckt. Sobald die Aufgabenkomplexität steigt und das System beginnt, „lokal korrekte, aber global falsche" Fehler zu zeigen, wird das Problem offengelegt.

Praktische Ratschläge

Das beste Multi-Agent-System sieht nicht wie ein Unternehmen aus. Es sieht eher aus wie die mehreren Entwürfe eines Denkers – dasselbe Gehirn, das Argumentation über verschiedene Dimensionen ausdehnt und sie schließlich zu einer kohärenten Schlussfolgerung zusammenführt.

Basierend auf diesem Prinzip:

Fragen Sie nicht „Wie viele Agenten brauche ich?"; fragen Sie „Wie ist die Informationsabhängigkeitsstruktur dieser Aufgabe?"

Wenn eine Aufgabe kontinuierliche Argumentation und hohe Kontextabhängigkeit erfordert (z. B. das Schreiben eines Design-Dokuments für eine komplexe Funktion), ist ein einzelner Agent + gutes Context Engineering in der Regel Multi-Agenten überlegen.

Wenn eine Aufgabe die gleichzeitige Erkundung unabhängiger Richtungen erfordert (z. B. die gleichzeitige Recherche von 10 Wettbewerbern), ist Multi-Agent-Parallelität sinnvoll – jede Unteraufgabe ist unabhängig, und die Kosten des Informationsverlusts sind minimiert.

Wenn eine Aufgabe mehrere Sitzungen umfasst, sind externe Zustandsdateien obligatorisch. Eine effektive Zustandsdatei sollte vier Arten von Informationen enthalten:

• Aufgabenziel (Unveränderlich, wird zu Sitzungsbeginn gelesen, um Drift zu verhindern)
• Abgeschlossene Schritte (Angehängt, nicht überschrieben, um die vollständige Historie zu behalten)
• Aktueller Zustand (Überschrieben, um den neuesten Fortschritt widerzuspiegeln)
• Bekannte Fallstricke (Angehängt, um Wiederholungen von Fehlern in der nächsten Sitzung zu vermeiden)

Diese vier Arten von Informationen, getrennt verwaltet und kombiniert, liefern den vollständigen Kontext, den das „zukünftige Ich" benötigt.

Wenn Sie einen Verifikationsschritt hinzufügen, machen Sie die alleinige Aufgabe des Verifier-Agenten, Probleme zu finden, nicht „den Staffelstab zu übernehmen und weiterzumachen". Adversariales Testen, keine Fließbandübergabe.

Schließlich: Die Modellfähigkeiten verbessern sich rasant. Workarounds, die heute im Harness benötigt werden, könnten in sechs Monaten zu totem Ballast werden. Anthropic hat dies bereits bewiesen – die Kontextangst von Sonnet 4.5 verschwand in Opus 4.5. Die Aufrechterhaltung der architektonischen Weiterentwicklungsfähigkeit ist wichtiger als die Wahl einer „perfekten Architektur".

Abteilungsbildung ist eine Illusion, die sich gut anfühlt, aber technisch teuer ist. Ihre wahren Kosten sind nicht direktes Scheitern, sondern dass Ihr System auf schwer diagnostizierbare Weise degradiert, wenn die Komplexität steigt – wo jeder Knoten „aussieht, als ob er funktioniert", aber das Ganze driftet.

Wenn Sie das Problem finden, ist das Fließband bereits sehr lang.

Referenzen: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)