Warum dreißig kleine statt einem großen Hirn

Wenn man einmal entschieden hat, dass die Agenten Kollegen sein sollen (Teil 4), kommt sofort die nächste Frage: wie viele?

Die verlockende Antwort ist: einer. Ein Modell, das alles weiß, alles kann und alles im Blick hat. Kein Abstimmungsaufwand, keine Übergaben, keine Missverständnisse. Technisch spricht überhaupt nichts dagegen — die heutigen Modelle können jede einzelne dieser Rollen ausfüllen.

Wir haben uns trotzdem für rund dreißig entschieden. Aktiviert wird einzeln, nie alles auf einmal; im Moment läuft eine Handvoll. Die Gründe dafür haben mit Fähigkeit nichts zu tun.

Grund 1: Ein Kontext ist kein Gedächtnis

Ein Sprachmodell hat ein Fenster, in das der gesamte Arbeitszusammenhang passen muss. Ein Kollege, der für alles zuständig ist, schleppt alles mit: Buchhaltungsregeln in ein Architekturgespräch, Marketing-Tonalität in eine Sicherheitsprüfung.

Das ist nicht nur teuer — jedes mitgeschleppte Wort kostet bei jedem Aufruf erneut — es ist auch fachlich schlecht. Wer alles gleichzeitig im Kopf hat, priorisiert nichts. Ein Spezialist mit engem Mandat und eigenem Gedächtnis hat einen kleinen, dichten, aktuellen Zusammenhang. Das ist der Unterschied zwischen einem Kollegen, der sein Gebiet kennt, und einem, der schon mal von allem gehört hat.

Grund 2: Man kann sich nicht selbst prüfen

Der eigentliche Grund ist aber ein anderer, und er ist der Kern der ganzen Konstruktion.

Es gibt eine Arbeit von Panickssery und Kollegen (NeurIPS 2024), die zeigt: Sprachmodelle erkennen ihre eigenen Ergebnisse wieder und bewerten sie systematisch besser — auch dann, wenn diese objektiv schlechter sind als die Alternative. Das nennt sich self-preference bias, und es ist so gut belegt, dass man es beim Bauen einfach als gegeben nehmen muss.

Wenn ein einziger Agent baut und prüft, prüft niemand. Das ist keine Meinung, das ist gemessen. Aus dieser einen Studie ist bei mir ein Verfassungsartikel geworden — der unbequemste von allen, weil er jeden Arbeitsschritt verdoppelt.

Grund 3: Verantwortung braucht Zuschnitt

Der dritte Grund ist der banalste und in der Praxis der wirksamste. Wenn etwas schiefgeht und alles von einem Kollegen kam, dann weiß man hinterher: es lag am Kollegen. Damit kann niemand arbeiten.

Wenn dagegen die Planung von einem kommt, die Umsetzung von einem zweiten, die Prüfung von einem dritten und die Freigabe von einem vierten, dann lässt sich die Stelle finden, an der es gekippt ist. Das ist genau der Grund, warum arbeitsteilige Organisationen diese Rollen haben. Sie sind nicht entstanden, weil einzelne Menschen zu dumm für den Rest wären, sondern weil Prüfbarkeit Trennung braucht.

Was es kostet — und wo die Grenze ist

Was dabei schiefging: sie haben einander ignoriert

Diesen Fehler will ich ausführlich erzählen, weil ich ihn für den lehrreichsten unserer ersten Wochen halte — und weil er jedem passieren kann, der so etwas baut.

Als die ersten Kollegen liefen, gab es eine Übergabe-Funktion: Ein Agent konnte einem anderen eine Aufgabe geben. Das wurde ordentlich protokolliert, es tauchte im gemeinsamen Kanal auf, alles sah richtig aus.

Nur kam beim Empfänger nichts an.

Der Grund stand in einer einzigen Zeile, und zwar in jedem unserer Agenten: Nachrichten, die von einem anderen Programm stammten, wurden verworfen. Ich hatte das selbst so gebaut, und zwar aus einem guten Grund — ohne diese Sperre antworten sich zwei Bots gegenseitig bis zum Weltuntergang, und jede Runde kostet Geld.

Die Sperre war richtig. Nur war die Folge, dass eine Übergabe zwischen zwei Kollegen technisch gar nicht stattfand. Sie wurde dokumentiert, nicht ausgeführt. Und weil die Dokumentation vollständig und korrekt war, sah das Ganze von außen aus wie ein funktionierendes System.

Die eigentliche Transportschicht zwischen zwei Agenten war ich. Jedes Mal, wenn etwas weitergereicht wurde, war der Mensch der Bote — ohne dass irgendwo stand, dass das so ist.

Wir haben es umgebaut: Nicht der Sender stößt an, sondern jeder Kollege holt sich seine offenen Aufgaben selbst ab. Die Sperre gegen gegenseitiges Antworten bleibt, damit Endlosschleifen bauartbedingt unmöglich sind — die Arbeit läuft jetzt über die Aufgabenliste, die Sichtbarkeit weiter über den Kanal.

Was ich daraus mitnehme: Wenn ein System sauber protokolliert, prüft man irgendwann nur noch das Protokoll. Die Frage, die ich mir zu spät gestellt habe, war nicht „steht es richtig drin?", sondern „hat der Empfänger es tatsächlich bekommen?". Das sind zwei verschiedene Fragen, und die erste kann man beantworten, ohne die zweite je gestellt zu haben.

Was es kostet — und wo die Grenze ist

Das hat einen Preis, und der ist unangenehm konkret.

Anthropic hat sein eigenes Multi-Agenten-System veröffentlicht und dabei ehrlich mitgeteilt, was es kostet: Ein Orchestrator mit mehreren Zuarbeitern schlägt einen einzelnen Agenten deutlich — und verbraucht dabei etwa das Fünfzehnfache an Tokens. Der zur Verfügung stehende Token-Umfang erklärt in ihren Messungen rund 80 Prozent der Leistungsunterschiede. Typischerweise arbeiten dort drei bis fünf Zuarbeiter parallel, nicht dreißig.

Fünfzehnfache Kosten sind kein Detail. Sie bedeuten, dass Vielagenten-Betrieb nur dort sinnvoll ist, wo das Ergebnis das trägt. Bei uns steht deshalb als Regel: Use Case schlägt Technologie. Kein Agent wird eingestellt, weil er im Organigramm steht, sondern nur, wenn es einen benannten, wiederkehrenden Schmerz gibt — und die erste Prüfung ist immer, ob der Prozess nicht einfach entfallen kann.

Die zweite Zahl, die mich beim Planen begleitet hat, kommt von der Carnegie Mellon University. Dort wurde eine simulierte Firma mit 175 realistischen Büroaufgaben gebaut und gemessen, wie weit Agenten kommen. Ergebnis: Die besten Modelle erledigen 24 bis 30 Prozent der Aufgaben vollständig, mit Teilpunkten kommt man auf 34 bis 39 Prozent.

Das ist die nüchternste Zahl in diesem ganzen Feld, und sie steht bei mir an der Wand. Sie sagt nämlich: Große, unscharfe Aufträge scheitern. Kleine, klar geschnittene, geprüfte Arbeitspakete gehen. Wer einem Agenten sagt „mach mal das Projekt", bekommt in zwei Dritteln der Fälle etwas, das aussieht wie ein Ergebnis und keines ist.

Deshalb ist die Arbeitsteilung bei uns nicht nur eine Frage der Zuständigkeit, sondern der Paketgröße. Der Orchestrator schneidet Aufgaben klein genug, dass sie prüfbar bleiben.

Und wer bezahlt das?

Damit die Fünfzehnfach-Rechnung nicht durch die Decke geht, sind nicht alle Kollegen gleich teuer. Die Buchhaltung braucht kein Spitzenmodell, die Architektur schon. Bei uns hat jede Rolle eine Modellklasse, und jeder neue Kollege startet grundsätzlich auf der billigsten — unabhängig davon, wo er einmal landen soll. Ein besseres Modell ist ein Bonus, den man sich verdient, kein Startgeschenk.

Es gibt zu dieser Frage eine hübsche Arbeit aus dem MetaGPT-Umfeld, die ein komplettes kleines Softwareprojekt für rund einen Dollar durchrechnet. Ich zitiere die Zahl nicht, weil ich sie für übertragbar halte — sie stammt aus einer Laborumgebung mit sehr klaren Aufgaben. Sondern weil sie die richtige Frage stellt: nicht kann das ein Agent?, sondern was kostet es, und ist es das wert?