Autonomer KI-Schwarm

Du bittest einen KI-Agenten, overnight ein Feature zu bauen. In der Theorie klingt das gut. In der Praxis wachst du auf und findest eine halbfertige Migration, zwei kaputte Dateien und eine fröhliche Meldung, dass die Aufgabe erledigt ist.

Dieses Fehlermuster ist häufig. Der Agent hat nicht versagt, weil das Modell schwach ist. Er hat versagt, weil ein lang laufender Agent zu viele Jobs gleichzeitig erledigen muss: die Aufgabe auswählen, den Plan halten, den Code bearbeiten, die Ausgabe prüfen und entscheiden, ob es sicher zu shippen ist.

Genau das behebt dieser Beitrag. Unten ist ein Autonomer KI-Schwarm. Klarer gesagt: automatisierte KI-Orchestrierung. Ein Trigger feuert alle 30 Minuten. Ein Orchestrator liest den Projektstatus, leitet einen oder mehrere Spezialisten weiter und prüft fünf Gates, bevor irgendetwas als erledigt gilt.

Die fünf Arten, wie overnight Agent-Läufe scheitern

Die meisten "autonomen" Demos verstecken den schwierigen Teil. Einen Agenten dazu zu bringen, Code zu schreiben, ist einfach. Ihn stundenlang korrekte Entscheidungen treffen zu lassen ist der schwierige Teil.

Das sind die fünf Fehlermodi, die zuerst auftauchen.

1. Kein Trigger

Nichts weckt das System zum richtigen Zeitpunkt.

Du musst immer noch dasitzen und den Prompt eingeben. Oder du startest einen großen Lauf vor dem Schlafengehen und hoffst, dass er die Nacht übersteht. Wenn der Lauf nach 20 Minuten ins Stocken gerät, stirbt alles genau dort.

Die Lösung ist einfach. Ein zeitgesteuerter Trigger. Alle 30 Minuten wacht das System auf, prüft was passiert ist, und entscheidet, was als nächstes zu tun ist.

2. Kein Routing

Ein Agent ist gezwungen, Projektmanager, Architekt, Frontend-Ingenieur, Backend-Ingenieur, Tester und Reviewer zu spielen.

Das klingt effizient. Ist es nicht. Das gleiche Kontextfenster hat jetzt Planung, Implementierung und Verifikation, die um Platz kämpfen. Der Lauf driftet. Der Agent verliert den Überblick, was erledigt ist, was blockiert ist und was noch Beweis braucht.

Die Lösung ist Rollentrennung. Ein Orchestrator leitet weiter. Spezialisten-Agenten führen aus. Das Routing-Hirn und das Worker-Hirn hören auf, sich gegenseitig im Weg zu sein.

3. Keine Leitplanken

Der Agent schreibt Code, markiert die Aufgabe dann als erledigt, weil die Datei existiert.

Das ist nicht dasselbe wie shippen. Eine Datei kann existieren und trotzdem bei Type-Checks scheitern, bei Lint scheitern, den Build brechen, ein Secret leaken oder Tests komplett verpassen.

Die Lösung ist ein Gate-Stack. Der Lauf zählt nicht, wenn er nicht die Prüfungen besteht, die wichtig sind.

4. Kein Beweis

Der Agent sagt, das Feature ist fertig, aber nichts im System beweist das.

Das ist dasselbe Problem, das auch bei KI-Sicherheit auftaucht. Ein Fund ohne Beweis ist Rauschen. Ein Feature ohne Beweis ist Wunschdenken.

Die Lösung ist Verifikation, die in jedem Zyklus läuft. Das System braucht einen Grund, der Ausgabe zu vertrauen, der stärker ist als das Selbstvertrauen des Agenten.

5. Kein Gedächtnis zwischen Läufen

Ein langer Lauf stockt. Du startest ihn neu. Der nächste Agent weiß nicht, was der letzte tat.

Jetzt bekommst du doppelte Arbeit, widersprüchliche Bearbeitungen und vage Zusammenfassungen statt echtem Fortschritt. Das System bewegt sich weiter, aber es dreht sich im Kreis.

Die Lösung ist externer Zustand. Der Orchestrator liest den aktuellen Projektzustand vor jedem Zyklus und leitet von dort weiter, nicht von dem, was ein Agent sich erinnert.

Warum ein einzelner Agent nicht ausreicht

Die übliche Antwort lautet: "Lass einfach einen Agenten weitermachen, bis die Tests grün sind."

Das ist besser als ein One-Shot-Prompt. Es reicht immer noch nicht.

Ein einzelner Agent hilft bei der Beharrlichkeit. Er löst kein Routing. Er löst keine Spezialisierung. Er löst nicht das Problem, dass ein Agent seine eigene Arbeit bewertet. Er löst nicht das Problem, zu entscheiden ob man planen, bauen, fixen oder stoppen soll.

Das ist der Unterschied zwischen einem Worker und einem Schwarm.

Ein einzelner Worker wiederholt eine Aufgabe immer wieder.

Ein Schwarm ist ein kleines System, das aufwacht, Zustand liest, eine Rolle auswählt, den richtigen Worker ausführt, das Ergebnis prüft und entweder vorwärts geht oder schläft.

Deshalb ist dieser Schwarm kein verteiltes Cluster, keine Kubernetes-Control-Plane oder ein abstraktes "Agent-Mesh." Es ist viel einfacher. Eine Maschine. Ein Repo. Ein zeitgesteuerter Trigger. Ein Orchestrator. Ein oder mehrere Spezialisten. Abgetrennte Worktrees sind der Parallelmodus, wenn die Arbeit sauber aufgeteilt werden kann.

Die Schwarm-Form

Ein KI-Orchestrations-Schwarm wie dieser hat fünf bewegliche Teile:

1. Trigger: ein 30-Minuten-Aufwachen.
2. Orchestrator: eine Hauptsitzung liest Kontext und wählt den nächsten Schritt.
3. Spezialisten: Planer, Builder, Designer, Tester und Guard. Der Orchestrator kann einen oder mehrere von ihnen weiterleiten.
4. Gates: Lint, Types, Clean Build, Commit Guard, Test Suite.
5. Output: Wenn alle Prüfungen bestanden werden, ist das Feature fertig. Wenn nicht, arbeitet der Schwarm weiter oder schläft.

Das ist die gesamte Form:

30-Minuten-Trigger
      ↓
Orchestrator liest Zustand
      ↓
nächste Aufgabe auswählen
      ↓
einen Spezialisten oder mehrere einsetzen
      ↓
Quality Gates ausführen
      ↓
shippen, weitermachen oder schlafen

Der wichtige Teil ist nicht "mehr Agenten." Der wichtige Teil ist, dass jeder Zyklus eine Aufgabe hat.

Abgetrennte Orchestratoren sind hier wichtig, weil sie der Parallelmodus sind. Nutze sie, wenn die Arbeit in zwei oder drei unabhängige Features mit klaren Grenzen aufgeteilt werden kann.

Schritt 1: der Trigger

Der Trigger ist ein Ping alle 30 Minuten.

Du kannst das mit einem echten System-Cron-Job implementieren. Du kannst es mit Claude Code Desktop Scheduled Tasks implementieren. Der Punkt ist nicht der Anbieter des Schedulers. Der Punkt ist der Rhythmus.

Der Rhythmus macht zwei Dinge.

Erstens gibt er dem System mehr als eine Chance zur Erholung. Wenn ein Lauf um 2:07 Uhr stirbt, wacht der nächste Zyklus um 2:30 Uhr auf und macht weiter.

Zweitens hält es das System günstig und lesbar. Du brauchst keinen ständig laufenden Agenten, der jede Sekunde Tokens verbrennt. Du brauchst ein Automatisierungsmuster, das aufwacht, entscheidet, handelt und stoppt.

In einem solchen Setup ist der Trigger-Schritt in einer Zeile zusammengefasst:

Ein Cron-Job. Terminiert den gesamten Schwarm.

Das ist das richtige mentale Modell. Ein Scheduler. Keine Cloud-Plattform.

Schritt 2: der Orchestrator

Der Orchestrator ist das Gehirn.

Er versucht nicht, das gesamte Feature selbst zu machen. Das ist die erste Regel.

Seine Aufgabe ist es, den aktuellen Zustand zu lesen und eine Frage zu beantworten: Was ist der nächste Schritt?

Diese Frage ist enger als sie klingt. Der Orchestrator erfindet keine Produktstrategie. Er liest Kontext, der bereits existiert:

• welche Aufgabe zuletzt versucht wurde
• welche Dateien sich geändert haben
• welche Prüfungen bestanden wurden
• welche Prüfungen fehlgeschlagen sind
• was blockiert ist
• welches Feature dem Abschluss am nächsten ist

Sobald er diesen Zustand hat, leitet er Arbeit an den richtigen Spezialisten weiter, oder an mehrere Spezialisten, wenn die Arbeit sich sauber aufteilen lässt.

Deshalb heißt es in der Karussell-Beschreibung:

Er wählt den nächsten Schritt.

Dieser Satz ist wichtig, weil er den Orchestrator korrekt definiert. Er ist nicht "der Hauptworker." Er ist der Dispatcher.

Schritt 3: die Spezialisten

Dieser Schwarm verwendet fünf Spezialisten-Rollen.

Du kannst sie umbenennen. Die Namen sind nicht der wichtige Teil.

Der wichtige Teil ist, dass jeder Agent eine engere Aufgabe hat als "das Feature bauen." Das reduziert Drift und hält die Ausgabe von Zyklus zu Zyklus konsistenter.

Das ist auch der Punkt, an dem die meisten Agent-Team-Setups schiefgehen. Leute starten fünf Agenten und geben dann allen fünf denselben Prompt. Das ist kein Team. Das ist Verdoppelung.

Ein echter Spezialist braucht nur den Kontext, der für seine Aufgabe erforderlich ist.

Der Planer braucht die Aufgabe und die Projektform.

Der Builder braucht die Zieldateien und Akzeptanzkriterien.

Der Designer braucht die UI-Anforderungen und die Komponentenbeschränkungen.

Der Tester braucht die Fehlerbedingungen und die Prüfungen.

Der Guard braucht die Richtlinie.

Der Orchestrator muss nicht alle fünf jedes Mal aufwecken.

Manchmal reicht ein Spezialist. Manchmal teilt sich die Arbeit auf und der Orchestrator fächert zu mehreren Spezialisten parallel auf.

Die saubere Version davon verwendet isolierte Sitzungen oder separate Git-Worktrees. Jeder Spezialist bekommt seine eigene Kopie des Repos, erledigt seinen Teil und vermeidet es, die Dateien eines anderen Spezialisten anzufassen. So bleibt parallele Arbeit real statt chaotisch. Selbst grundlegende Repo-Details wie .gitignore, .gitkeep, Migrationen, Tests und UI-Dateien sind leichter nachzuvollziehen, wenn jeder Worker seine eigene Spur hat.

Das ist es, was "Ein Orchestrator. Ein oder mehrere Spezialisten." in der Praxis wirklich bedeutet.

Wie parallele Arbeit wieder zusammengeführt wird

Parallele Arbeit ist nützlich, bis zwei Spezialisten dieselben Dateien berühren.

Deshalb arbeitet jeder Spezialist in seinem eigenen Git-Worktree. Der Main-Branch bleibt sauber, während die Spezialisten parallel bauen.

Wenn ein Spezialist fertig ist, mergt sein Branch nicht direkt zurück. Im abgetrennten Modus geht er durch einen begrenzten Merge-Helfer. Ein Branch auf einmal. Ein Ziel-Branch. Einfache Fallback-Regeln.

Wenn der Merge sauber ist, landet er.

Wenn es einen Konflikt gibt, versucht das System drei Schritte. Erstens ein sauberes git merge. Zweitens deterministisches Auto-Resolve für einfache Fälle. Drittens ein Pro-Datei LLM-Resolve mit harter Ablehnung von Prosa-Ausgaben. Das hält den Merge-Pfad eng und vorhersehbar.

Wenn nichts davon funktioniert, stoppt der Merge und der Branch wird als fehlgeschlagen markiert.

Das ist wichtig. Ein Schwarm ist nicht "alles mergen und hoffen." Es ist parallele Arbeit mit Regeln.

Schritt 4: der Fullstack-Ausführungspfad

Die Builder-Phase ist der Punkt, an dem das System seinen Wert beweist.

Viele Agent-Demos stoppen bei "der Agent hat eine Datei geschrieben." Wir wollten das Gegenteil. Wir wollten einen Pfad von der Datenbank bis zur Live-Ausgabe.

Deshalb wird die Build-Phase im Schwarm nicht als "Code schreiben" beschrieben. Sie wird beschrieben als:

Agenten führen den Full-Stack aus.

In einem solchen System bedeutet das, dass der Orchestrator über die tatsächlichen Ebenen hinweg weiterleiten kann, die ein echtes Feature berührt:

• Datenbankarbeit
• Backend-Logik
• Seiten und UI-Verdrahtung
• Design-Polish
• Tests

Deshalb endet Folie 4 mit:

Database to live. Ein Feature, null manuelle Schritte.

Das ist auch der richtige Ort, um Full-Stack in einfachen Worten zu definieren. In diesem System bedeutet das nicht "jede Technologie der Welt." Es bedeutet die Ebenen, die nötig sind, um ein Feature von der Speicherung bis zum Bildschirm real zu machen.

Wenn sich die Datenbank ändert, aber die Seite nicht, ist das Feature nicht fertig.

Wenn sich die Seite ändert, aber die Tests scheitern, ist das Feature nicht fertig.

Wenn alles lokal baut, aber der Commit Guard ein Secret markiert, ist das Feature nicht fertig.

Der Schwarm bewegt sich durch diese Ebenen, bis die Kette geschlossen ist.

Schritt 5: die fünf Gates

Die Guard-Phase ist der Teil, der das System vertrauenswürdig macht.

Ohne sie ist der Schwarm nur ein schneller Weg, kaputte Arbeit zu generieren.

Unser Gate-Stack hat fünf Prüfungen:

Das ist das genaue Gegenteil von "den Agenten shippen lassen und hoffen."

Der Text hier ist aus gutem Grund direkt:

Nichts shippt ohne zu bestehen.

Das ist kein Slogan. Es ist die Regel.

Die fünf Gates machen zwei Dinge.

Erstens verhindern sie, dass schlechter Code main erreicht.

Zweitens geben sie dem Orchestrator ein zuverlässiges Signal, was als nächstes zu tun ist. Wenn der Type-Check scheitert, ist der nächste Schritt nicht "feiern." Der nächste Schritt ist "einen Fix routen."

Das bedeutet, die Gates sind nicht nur Sicherheitsprüfungen. Sie sind Routing-Signale.

Wie die Ausgabe aussieht

Das Ziel ist nicht "der Agent lief vier Stunden."

Das Ziel ist: Du kommst zurück und das Feature ist wirklich fertig.

Deshalb heißt die letzte Phase im Schwarm nicht "Zusammenfassung" oder "Reporting." Sie heißt Output.

Ein overnight-Lauf kann so aussehen:

• 2:00 Uhr: Auth-System geplant
• 2:30 Uhr: drei API-Endpunkte gebaut
• 3:00 Uhr: 47 Tests ausgeführt
• 3:30 Uhr: in Produktion deployed

Diese Sequenz ist wichtig, weil sie beweist, dass das System geordnete Arbeit leistet, keine zufällige.

Ein einfaches Beispiel ist:

4 Stunden. Auth wurde gebaut, getestet und geshippt.

Das ist genau das richtige Beweis-Format für ein autonomes Build-System. Kurz. Konkret. Überprüfbar.

Nicht "das Modell hat wirklich gut nachgedacht." Nicht "das System sah vielversprechend aus." Ein Feature hat die Ziellinie überschritten.

Wie die Automatisierung tatsächlich läuft

Dieser Teil ist wichtig, weil "autonom" wenig bedeutet, wenn der Trigger unscharf ist.

Die Automatisierung ist keine Magie. Sie beginnt mit einem geplanten Aufwachen.

Die einfachste Version ist ein System-Cron-Eintrag, der alle 30 Minuten einen neuen Lauf startet. Konzeptionell sieht das so aus:

*/30 * * * * cd /path/to/repo && claude -p "run the swarm orchestrator for the next task"

Das reicht aus, um den Rhythmus zu erzeugen.

Du kannst dasselbe Muster auch mit Claude Code Desktop Scheduled Tasks ausführen. In diesem Modell hält die Desktop-App den Zeitplan und startet im gewählten Intervall eine neue Sitzung. Die Aufgabe funktioniert nach dem Aufwachen immer noch genauso:

1. ein geplanter Lauf startet
2. der Orchestrator liest den aktuellen Projektstatus
3. ein Spezialist oder mehrere Spezialisten bekommen die nächste Aufgabe
4. das Ergebnis geht durch die Quality Gates
5. das System shippt, wiederholt oder schläft

Die Wahl zwischen Cron und Desktop Scheduled Tasks ist operationell, nicht architektonisch.

Nutze Cron, wenn du den einfachsten Machine-Level-Trigger willst.

Nutze Desktop Scheduled Tasks, wenn du einen sichtbaren Zeitplan, eingebaute History und eine neue Claude-Sitzung jedes Mal willst, ohne Shell-Scripts selbst zu verdrahten.

Was zählt: jeder Lauf startet frisch und jeder Lauf kann den aktuellen Zustand sehen. Das macht den Schwarm dauerhaft statt zerbrechlich.

Was passiert, wenn nichts bereit ist

Ein guter automatisierter Schwarm braucht einen Schlafzustand.

Das klingt klein. Ist es nicht.

Wenn sich nichts geändert hat, kein Gate fehlgeschlagen ist und kein Feature nah genug ist, um voranzukommen, sollte der Orchestrator den Zustand protokollieren und stoppen. Er sollte keine Arbeit erzwingen, nur weil der Scheduler gefeuert hat.

So hältst du das System sauber.

Der Trigger erzeugt Gelegenheit. Er erzeugt keine falsche Dringlichkeit.

Warum das besser funktioniert als ein generisches Agent-Framework

Die meisten generischen Agent-Frameworks geben dir die beweglichen Teile, aber nicht die Betriebsregeln.

Du bekommst Tools zum Starten von Agenten. Du bekommst Tools zum Übergeben von Nachrichten. Du bekommst das Gefühl von Struktur. Dann musst du trotzdem entscheiden:

• wann das System aufwacht
• welchen Zustand es liest
• wie es die nächste Aufgabe auswählt
• wie es doppelte Arbeit vermeidet
• was einen Schritt abschließt
• was ein Shippen blockiert

Das sind die echten Fragen.

Der Schwarm funktioniert, weil er sie im Voraus beantwortet.

Trigger gibt ihm Rhythmus.

Orchestrator gibt ihm Routing.

Spezialisten geben ihm Fokus.

Gates geben ihm Beweis.

Output gibt ihm eine Ziellinie.

Ein generisches Framework kann diese Form aufnehmen. Es kann sie nicht ersetzen.

Wie du deine eigene Version baust

Du brauchst keinen riesigen Stack, um das zu kopieren.

Fang mit dieser Minimalform an:

ein Scheduler
ein Orchestrator
ein oder mehrere Spezialisten
drei bis fünf Quality Gates
eine State-Datei oder ein Report-Verzeichnis

Dann befolge diese Regeln.

1. Halte den Trigger günstig

Betreib keinen dauerhaft wachen Agenten, wenn ein zeitgesteuertes Aufwachen funktioniert.

Ein 30-Minuten-Ping reicht für die meisten overnight Build-Systeme. Er gibt dir Retry-Verhalten, ohne für konstante Aktivität zu zahlen.

2. Trenne Routing von Ausführung

Lass den Orchestrator nicht die Implementierungsarbeit machen.

Wenn das Gehirn auch der Worker ist, sinkt deine Routing-Qualität und dein Kontext wird schnell unübersichtlich.

3. Gib jedem Spezialisten eine enge Aufgabe

Ein Agent sollte nicht planen, coden, designen und verifizieren im selben Durchgang.

Enge Prompts sind leichter zu bewerten, leichter wiederzuversuchen und leichter zu ersetzen.

Wenn mehrere Spezialisten parallel laufen, gib jedem eine klare Grenze. Separate Worktrees sind die sauberste Version, weil jeder Spezialist seinen eigenen Checkout bearbeitet statt um dieselben Dateien zu kämpfen.

4. Lass Gates blockieren, nicht beraten

Ein Quality Gate, das nur eine Warnung schreibt, ist kein Gate.

Wenn der Build kaputt ist, muss das System einen Fix routen, statt so zu tun, als ob das Feature vollständig ist.

5. Halte Beweise außerhalb des Selbstberichts des Agenten

Der Agent, der "fertig" sagt, ist kein Beweis.

Beweis kommt von Prüfungen, Tests, Logs und erfolgreichen Builds. Externe Signale schlagen internes Selbstvertrauen jedes Mal.

6. Schlafe bewusst

Wenn nichts bereit ist, protokolliere den Zustand und schlafe.

Das ist wichtiger als es klingt. Systeme werden teuer und chaotisch, wenn sie nicht entscheiden können zu stoppen.

Was dieses System tatsächlich ist

Das ist die direkte Antwort auf deine Frage: Ist es ein Crontab?

Auf der Trigger-Ebene, ja, es ist cron-förmig.

Es gibt einen Scheduler, der das System alle 30 Minuten aufweckt. Dieser Scheduler kann sein:

• ein echter crontab-Eintrag auf deiner Maschine
• eine Claude Code Desktop Scheduled Task

Der Schwarm ist nicht der Scheduler allein.

Der vollständige Fluss ist:

1. Scheduler feuert
2. neue Sitzung wacht auf
3. Orchestrator liest Zustand
4. Orchestrator wählt den nächsten Schritt
5. ein Spezialist oder mehrere Spezialisten laufen
6. Gates prüfen das Ergebnis
7. System shippt, wiederholt oder schläft

Deshalb ist die richtige Antwort nicht "es ist ein Crontab" und nicht "es ist ein KI-Framework."

Es ist ein automatisierter KI-Schwarm.

Eine gültige Form ist:

main session -> route work -> sub-agents -> gates -> sleep

Eine andere gültige Form ist:

main session -> partition 2-3 independent features -> spawn isolated worktree sessions -> merge back safely

Beide sind dieselbe Idee. Automatisierte KI-Orchestrierung mit klaren Rollen, begrenzten Merge-Regeln und einer Ziellinie.

Wo dieses Muster sonst noch gilt

Wenn du die Form einmal siehst, kannst du sie außerhalb von Feature-Builds anwenden.

Dasselbe Schwarm-Muster funktioniert für:

• Security Review
• Dependency Audits
• Content-Produktion
• Analytics-Triage
• PR-Babysitting

Der Scheduler weckt das System. Der Orchestrator prüft den Zustand. Ein oder mehrere Spezialisten erledigen die enge Arbeit. Die Gates entscheiden, ob die Ausgabe gut genug ist. Dann schläft der Schwarm wieder.

Das ist das gesamte Modell.

Ein Ping. Ein Gehirn. Ein oder mehrere Spezialisten. Fünf Gates. Features fertig, wenn du aufwachst.