Von 1 auf 18: Eine Agenten-Armee in weniger als einer Woche

Der häufigste Fehler, den ich bei KI-Agenten sehe: sie generalistisch zu lassen. Ein Agent, ein riesiger Prompt, alle Aufgaben. Das funktioniert gut genug, dass man das Problem zunächst nicht merkt. Dann fängt man an, echte Arbeit zu machen — und die Risse zeigen sich.

In fünf intensiven Tagen bin ich von einem einzigen Generalisten-Agenten auf 18 Spezialisten gegangen. Das ist die Geschichte davon: warum es nötig war, wie es passiert ist, und wie die finale Architektur aussieht. (Die Memory-Infrastruktur, auf die diese Agenten sich stützen, ist im Post über das Three-Tier Memory beschrieben.)

Warum Generalisten im großen Maßstab scheitern

Ein Generalist kann alles machen. Er kann auch alles gleichzeitig schlecht machen.

Das Problem ist nicht die Kompetenz — moderne KI-Modelle haben das Wissen. Das Problem ist der Kontext. Wenn ein Agent Anweisungen für alle Domänen lädt, die er möglicherweise braucht, ist das Kontextfenster schon voll, bevor die eigentliche Arbeit beginnt. Wenn er bei deiner Aufgabe ankommt, schleppt er bereits die Last von einem Dutzend Dingen mit, die er gerade nicht braucht.

Das zweite Problem ist Fokus. Ein Agent, dem alles mögliche gestellt werden kann, entwickelt Absicherungsverhalten. Er fügt Einschränkungen hinzu. Er prüft Dinge, die keine Prüfung brauchen. Er behandelt jede Aufgabe so, als könnte sie die eine sein, die Vorsicht erfordert — weil er nicht weiß, welche es ist.

Spezialisten haben dieses Problem nicht. Ein kotlin-implementer zögert nicht wegen TypeScript. Er lädt Spring-Boot-Wissen und sonst nichts. Ein git-agent denkt nicht über Test-Suites nach. Er kennt Branches, Commits, Rebases und Push-Muster. Es geht bei der Spezialisierung nicht nur darum, was sie wissen — sondern darum, was sie nicht im Kopf haben müssen.

Die Entwicklung

Ausgangspunkt: die Generalistenphase. Ein Agent. Er schreibt Code, führt Tests aus, macht Commits, erstellt PRs, schickt Slack-Nachrichten. Er macht alles — langsam und mit generischen Fehlern. Test-Befehle, die am falschen Modul laufen. Commit-Messages, die das Falsche beschreiben. PRs, die technisch stimmen, aber am eigentlichen Punkt vorbeigehen.

Erste Aufteilung: Implementierer, Tester, Reviewer. Drei Agenten, jeder mit einem klaren Job. Sofort besser. Der Reviewer findet Dinge, die der Implementierer eingebaut hat. Aber sie sind noch zu breit — der Implementierer arbeitet in Kotlin und TypeScript, und macht beides so, wie jemand, der beide Sprachen halbwegs kennt.

Tech-Stack-Spezialisierung: der Schritt, der alles verändert hat.

Der kotlin-implementer kennt Spring Boot, Maven, Kotlin-Idiome, unsere Backend-Konventionen. Er weiß nicht, dass React existiert. Der typescript-implementer kennt Vite, React 19, Tailwind CSS, unsere Frontend-Muster. Er weiß nicht, was eine JVM ist.

Die Test-Agenten haben sich genauso aufgeteilt. Der mvn-tester kennt Maven-Lifecycle-Phasen, Surefire-Konfiguration, wie man einen fehlschlagenden Test in einem Multi-Modul-Build isoliert. Der npm-tester kennt Jest, Test-Coverage-Flags, wie man eine einzelne Spec-Datei ausführt.

Die Qualität der Arbeit hat sich bei jedem Agenten spürbar verbessert, sobald er nicht mehr das Wissen des anderen Tech-Stacks im selben Kontextfenster halten musste.

Pipeline-Agenten: wo das System zu etwas qualitativ anderem wurde.

Ein git-agent, der nur Versionskontrolle macht. Er kennt Branching-Strategien, Commit-Message-Konventionen, Rebase- vs. Merge-Entscheidungen, wie man Merge-Konflikte sauber löst. Er denkt nicht darüber nach, ob der Code korrekt ist — das ist bereits reviewed worden. Er denkt darüber nach, ob die Git-Historie sauber ist.

Ein github-pr-handler, der Ticket-Kontext liest, ihn mit Code-Änderungen abgleicht, eine PR-Beschreibung schreibt, die ein Mensch tatsächlich nützlich findet, und die richtigen Labels und Reviewer zuweist. Er kennt PR-Konventionen in unserer Codebasis. Er hat Dutzende früherer PRs im Trainingskontext gelesen.

Ein jenkins-handler, der CI-Fehler-Logs liest, diagnostiziert, ob es ein Flaky-Test, eine echte Regression oder ein Infrastruktur-Problem ist, und entsprechend reagiert — Flaky-Tests wiederholen, Regressionen melden, den On-Call für Infra-Fehler benachrichtigen.

Ein slack-handler, der die Channels, den Ton, die Zielgruppe kennt. Er schickt nicht dieselbe Nachricht an den Engineering-Channel und den Stakeholder-Channel. Er kennt den Unterschied zwischen „erfolgreich deployed” und „PR ist bereit fürs Review”.

Die finale Architektur: 18 Agenten

Nach fünf Tagen:

• jira-ticket-handler — liest Tickets, extrahiert Akzeptanzkriterien, markiert Unklarheiten
• planning-writer — wandelt Ticket-Kontext in einen Implementierungsplan um
• kotlin-implementer — Spring Boot / Kotlin Backend-Arbeit
• typescript-implementer — React / Vite / TypeScript Frontend-Arbeit
• mvn-tester — führt Maven-Test-Suites aus, interpretiert Ergebnisse
• npm-tester — führt npm/pnpm-Test-Suites aus, interpretiert Ergebnisse
• code-reviewer — prüft Implementierung gegen Konventionen und Akzeptanzkriterien
• code-refiner — setzt Reviewer-Feedback um, ohne alles neu zu schreiben
• git-agent — alle Versionskontroll-Operationen
• github-pr-handler — PR-Erstellung, Beschreibung, Labeling, Reviewer-Zuweisung
• jenkins-handler — CI-Monitoring und Fehler-Triage
• slack-handler — Team-Benachrichtigungen und Status-Updates
• agent-optimizer — liest operative Logs, erkennt Muster, aktualisiert Agenten-Anweisungen
• feedback-recorder — nimmt menschliches Feedback auf und leitet es an den Optimizer weiter
• Plus 4 domänenspezifische Agenten für unser konkretes Service-Ökosystem

Die Design-Entscheidungen, die es zum Laufen gebracht haben

AGENT.md vs CLAUDE.md — die Trennung.

Jeder Agent hat eine AGENT.md-Datei: reines Tech-Stack-Wissen. Spring-Boot-Muster, Maven-Befehle, Kotlin-Idiome. Nichts Projektspezifisches. Und eine CLAUDE.md-Datei: projektspezifischer Kontext. Unsere Konventionen, unsere Service-Namen, unser Deployment-Setup.

Das macht Agenten portierbar. Den kotlin-implementer in ein anderes Projekt zu bringen bedeutet, nur die CLAUDE.md auszutauschen — die AGENT.md bleibt. Das Tech-Stack-Wissen überträgt sich. Das Projektwissen nicht.

Das Symlink-Setup.

Alle 18 Agenten leben in einem einzigen versionskontrollierten Repository. Jedes Agenten-Verzeichnis ist per Symlink mit ~/.claude/agents/ verknüpft — dem Pfad, in dem Claude Code nach Sub-Agenten sucht. Eine einzige Quelle der Wahrheit, überall verfügbar, versionskontrolliert wie Code.

Wenn ich die Anweisungen eines Agenten aktualisiere, gilt die Änderung sofort in allen Projekten, die ihn verwenden. Kein Kopieren, kein Drift zwischen Kopien.

Der Evolutionszyklus.

Agenten protokollieren relevante Ereignisse während der Arbeit — unerwartetes Verhalten, hilfreiche Muster, Entscheidungen, die Klärung brauchten. Ein separater agent-optimizer liest diese Logs regelmäßig, erkennt Muster, die 3 oder mehr Mal auftauchen, und aktualisiert die entsprechenden Agenten-Anweisungen.

Der Kreislauf: Agenten beobachten → Optimizer lernt → Agenten verbessern sich. Es ist nicht vollautomatisch — der Optimizer läuft nach Zeitplan, und ein Mensch prüft die vorgeschlagenen Änderungen. Aber das System wird dadurch systematisch besser mit der Zeit, nicht nur dann, wenn ich zufällig dran denke, etwas zu aktualisieren. (Wie sich dieses Design weiterentwickelt hat — und was schiefging, als die Memory-Dateien auf 95 KB anwuchsen — ist in The Memory Bloat Crisis beschrieben.)

Was es wirklich gekostet hat

18 Agenten klingt nach Komplexität. Ist es auch. Das Setup hat fünf intensive Tage dedizierter Arbeit gekostet. Den Großteil davon nicht für das Schreiben von Anweisungen — sondern dafür, herauszufinden, welche Aufteilungen tatsächlich etwas bringen und welche nur Overhead erzeugen. Die Grenzen zu finden, wo Spezialisierung echte Gewinne produziert.

Ein paar Aufteilungen, die ich versucht habe und die sich nicht gelohnt haben: Lese- von Schreib-Operationen trennen (zu viel Übergabe-Overhead), nach Domänenbereich im Backend aufteilen (die Agenten haben ständig den Kontext des anderen gebraucht), einen separaten Dokumentations-Agenten einsetzen (Implementierer und Reviewer haben das zusammen gut hinbekommen).

Die Aufteilungen, die funktioniert haben, waren die, die echten unterschiedlichen Wissensdomänen und wirklich verschiedenen Denkmodi entsprechen. Spring-Boot-Code schreiben und React-Code schreiben stellen unterschiedliche Anforderungen ans Kontextfenster. Code reviewen und Code committen sind grundlegend verschiedene kognitive Vorgänge. Diese Grenzen sind real.

Wenn ich nochmal von vorne anfangen würde: erst auf 4 oder 5 Agenten gehen. Implementierer, Tester, Reviewer, Git und Deployment. Diese zum Laufen bringen und kalibrieren, bevor mehr dazukommen. Die 18-Agenten-Architektur ist das Ergebnis von Iteration — nicht der Startpunkt. (In My First Autonomous Ticket siehst du, wie diese Pipeline ausgesehen hat, als sie zum ersten Mal end-to-end lief.)