Autonomer KI-Schwarm

Du bittest einen KI-Agent, overnight ein Feature zu bauen. Klingt gut in der Theorie. In der Praxis wachst du auf: halbfertige Migration, zwei kaputte Dateien, eine fröhliche Meldung, dass alles erledigt ist.

Dieses Muster ist häufig. Der Agent hat nicht versagt, weil das Modell schwach ist. Er hat versagt, weil ein einzelner langlebiger Agent zu viele Jobs gleichzeitig erledigen muss: Aufgabe auswählen, Plan halten, Code schreiben, Output prüfen, entscheiden ob es sicher ist zu shippen.

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

Die fünf Gründe, warum overnight Agent-Runs scheitern

Die meisten "autonomen" Demos verstecken den schwierigen Teil. Einen Agent dazu zu bringen, Code zu schreiben, ist einfach. Ihn stundenlang richtige Entscheidungen treffen zu lassen, ist die eigentliche Herausforderung.

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

1. Kein Trigger

Nichts weckt das System zum richtigen Zeitpunkt.

Du sitzt immer noch da und tippst den Prompt selbst. Oder du startest einen großen Run vor dem Schlafen und hoffst, dass er die Nacht übersteht. Wenn er nach 20 Minuten abstirbt, war's das.

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

2. Kein Routing

Ein Agent muss gleichzeitig Projektmanager, Architekt, Frontend-, Backend-Engineer, Tester und Reviewer spielen.

Das klingt effizient. Ist es nicht. Planung, Implementierung und Verifikation kämpfen im selben Kontextfenster um Platz. Der Run driftet. Der Agent verliert den Überblick: Was ist fertig, was ist blockiert, was braucht noch Beweis?

Die Lösung ist Rollentrennung. Ein Orchestrator routet. Spezialisten führen aus. Das Routing-Hirn und das Worker-Hirn stören sich nicht mehr gegenseitig.

3. Keine Leitplanken

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

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

Die Lösung ist ein Gate-Stack. Der Run zählt nicht, ohne die Checks zu bestehen, die wichtig sind.

4. Kein Beweis

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

Das ist dasselbe Problem wie bei KI-Security. Ein Fund ohne Beweis ist Rauschen. Ein Feature ohne Beweis ist Wunschdenken.

Die Lösung ist Verifikation in jedem Zyklus. Das System braucht einen Grund, dem Output zu vertrauen, der stärker ist als das Selbstvertrauen des Agents.

5. Kein Gedächtnis zwischen Runs

Ein langer Run steckt fest. Du startest neu. Der nächste Agent weiß nicht, was der letzte getan hat.

Jetzt gibt es doppelte Arbeit, widersprüchliche Edits und vage Zusammenfassungen statt echtem Fortschritt. Das System bewegt sich, aber im Kreis.

Die Lösung ist externer State. Der Orchestrator liest den aktuellen Projektzustand vor jedem Zyklus und routet von dort, nicht aus dem Gedächtnis eines Agents.

Warum ein einzelner Agent nicht reicht

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

Besser als ein One-Shot-Prompt. Immer noch nicht genug.

Ein einzelner Agent hilft bei der Beharrlichkeit. Er löst kein Routing. Er löst keine Spezialisierung. Er löst nicht das Problem, dass einer seine eigene Arbeit bewertet. Er löst nicht die Frage: Soll ich jetzt planen, bauen, fixen oder stoppen?

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, State liest, eine Rolle wählt, den richtigen Worker startet, das Ergebnis prüft und entweder vorwärts geht oder schläft.

Deshalb ist dieser Schwarm kein verteiltes Cluster, keine Kubernetes Control Plane, kein abstraktes "Agent Mesh." Viel einfacher. Eine Maschine. Ein Repo. Ein zeitgesteuerter Trigger. Ein Orchestrator. Ein oder mehrere Spezialisten. Abgetrennte Worktrees sind der Parallelmodus, wenn die Arbeit sich sauber aufteilen lässt.

Die Schwarm-Struktur

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

1. Trigger: ein 30-Minuten-Aufwachen.
2. Orchestrator: eine Hauptsession liest Kontext und wählt den nächsten Schritt.
3. Spezialisten: Planer, Builder, Designer, Tester und Guard. Der Orchestrator kann einen oder mehrere routen.
4. Gates: Lint, Types, Clean Build, Commit Guard, Test Suite.
5. Output: Alle Checks bestanden? Feature ist fertig. Sonst: Schwarm arbeitet weiter oder schläft.

Die gesamte Struktur:

30-minute trigger
      ↓
orchestrator reads state
      ↓
pick the next task
      ↓
dispatch one specialist or several
      ↓
run quality gates
      ↓
ship, continue, or sleep

Der wichtige Teil ist nicht "mehr Agents." Der wichtige Teil: jeder Zyklus hat einen Job.

Abgetrennte Orchestratoren sind hier der Parallelmodus. Nutze sie, wenn sich die Arbeit in zwei oder drei unabhängige Features mit klaren Grenzen aufteilt.

Schritt 1: der Trigger

Der Trigger ist ein Ping alle 30 Minuten.

Umsetzen kannst du das mit einem echten System-Cron-Job oder mit Claude Code Desktop Scheduled Tasks. Die Marke des Schedulers ist egal. Was zählt, ist der Rhythmus.

Der Rhythmus macht zwei Dinge.

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

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

Kurz gesagt:

Ein Cron-Job. Schedulet den ganzen 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 umzusetzen. Das ist die erste Regel.

Sein Job ist es, den aktuellen State 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 Checks bestanden wurden
• welche Checks fehlgeschlagen sind
• was blockiert ist
• welches Feature dem Abschluss am nächsten ist

Damit routet er Arbeit an den richtigen Spezialisten, oder an mehrere, wenn sich die Arbeit sauber aufteilt.

Er wählt den nächsten Schritt.

Dieser Satz definiert den Orchestrator korrekt. Er ist nicht "der Hauptworker." Er ist der Dispatcher.

Schritt 3: die Spezialisten

Dieser Schwarm nutzt fünf Spezialisten-Rollen.

Die Namen kannst du ändern. Das ist nicht der wichtige Teil.

Der wichtige Teil: jeder Agent hat einen engeren Job als "das Feature bauen." Das reduziert Drift und macht den Output von Zyklus zu Zyklus konsistenter.

Hier gehen die meisten Agent-Team-Setups schief. Fünf Agents starten und alle fünf bekommen denselben Prompt. Das ist kein Team. Das ist Duplikation.

Ein echter Spezialist braucht nur den Kontext, der für seinen Job nötig ist.

Der Planer braucht die Aufgabe und die Projektstruktur.

Der Builder braucht die Zieldateien und Akzeptanzkriterien.

Der Designer braucht die UI-Anforderungen und die Komponentengrenzen.

Der Tester braucht die Fehlerbedingungen und die Checks.

Der Guard braucht die Policy.

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

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

Die saubere Version nutzt isolierte Sessions oder separate Git-Worktrees. Jeder Spezialist bekommt seine eigene Kopie des Repos, erledigt seinen Teil und vermeidet es, die Dateien eines anderen anzufassen. So bleibt parallele Arbeit ordentlich statt chaotisch. Selbst grundlegende Repo-Details wie .gitignore, .gitkeep, Migrationen, Tests und UI-Dateien lassen sich leichter im Blick behalten, wenn jeder Worker seine eigene Spur hat.

Das ist es, was "Ein Orchestrator. Ein oder mehrere Spezialisten." in der Praxis 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 läuft er durch einen begrenzten Merge-Helper. Ein Branch auf einmal. Ein Ziel-Branch. Einfache Fallback-Regeln.

Ist der Merge sauber, landet er.

Gibt es einen Konflikt, 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 für Prosa-Output. Das hält den Merge-Pfad eng und vorhersehbar.

Funktioniert nichts davon, 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 Full-Stack-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." Das Gegenteil war das Ziel: ein Pfad von der Datenbank bis zum Live-Output.

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

Agents führen den Full-Stack aus.

In einem solchen System kann der Orchestrator über alle Ebenen hinweg routen, die ein echtes Feature berührt:

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

Das ist auch der richtige Ort, um Full-Stack klar 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.

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

Ändert sich die Seite, aber die Tests schlagen fehl, ist das Feature nicht fertig.

Baut alles lokal, aber der Commit Guard flaggt ein Secret, ist das Feature nicht fertig.

Der Schwarm arbeitet 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 Checks:

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

Nichts shippt ohne zu bestehen.

Kein Slogan. 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 für den nächsten Schritt. Schlägt der Type-Check fehl, ist der nächste Schritt nicht "feiern." Der nächste Schritt ist "einen Fix routen."

Die Gates sind also nicht nur Sicherheitschecks. Sie sind Routing-Signale.

Wie der Output aussieht

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

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

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

Ein overnight Run 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 geordnet arbeitet, nicht zufällig.

4 Stunden. Auth gebaut, getestet, geshippt.

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

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

Wie die Automatisierung tatsächlich läuft

"Autonom" bedeutet wenig, wenn der Trigger unscharf ist.

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

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

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

Das reicht für den Rhythmus.

Das gleiche Muster funktioniert auch mit Claude Code Desktop Scheduled Tasks. In diesem Modell hält die Desktop-App den Zeitplan und startet im gewählten Intervall eine neue Session. Der Job läuft nach dem Aufwachen identisch:

1. ein geplanter Run startet
2. der Orchestrator liest den aktuellen Projektstatus
3. ein 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.

Nimm Cron für den einfachsten Machine-Level-Trigger.

Nimm Desktop Scheduled Tasks, wenn du einen sichtbaren Zeitplan, eingebaute History und eine neue Claude-Session ohne Shell-Script-Gebastele willst.

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

Was passiert, wenn nichts bereit ist

Ein guter automatisierter Schwarm braucht einen Schlafzustand.

Klingt klein. Ist es nicht.

Ändert sich nichts, ist kein Gate fehlgeschlagen und ist kein Feature nah genug am Abschluss: dann soll der Orchestrator den State loggen und stoppen. Keine Arbeit erzwingen, nur weil der Scheduler gefeuert hat.

So bleibt das System sauber.

Der Trigger schafft Gelegenheit. Er schafft keine falsche Dringlichkeit.

Warum das besser ist 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 Agents. Tools zum Übergeben von Nachrichten. Das Gefühl von Struktur. Und dann musst du trotzdem entscheiden:

• wann das System aufwacht
• welchen State 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 Struktur aufnehmen. Ersetzen kann es sie nicht.

Wie du deine eigene Version baust

Du brauchst keinen riesigen Stack, um das zu kopieren.

Fang mit dieser Minimalstruktur an:

one scheduler
one orchestrator
one or several specialists
three to five quality gates
one state file or report directory

Dann befolge diese Regeln.

1. Halte den Trigger günstig

Kein dauerhaft wacher Agent, wenn ein zeitgesteuertes Aufwachen reicht.

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

2. Trenne Routing von Ausführung

Der Orchestrator macht nicht die Implementierungsarbeit.

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

3. Gib jedem Spezialisten einen engen Job

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

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

Laufen mehrere Spezialisten parallel, bekommt jeder eine klare Grenze. Separate Worktrees sind die sauberste Version: jeder Spezialist bearbeitet seinen eigenen Checkout, statt um dieselben Dateien zu kämpfen.

4. Lass Gates blockieren, nicht beraten

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

Ist der Build kaputt, muss das System einen Fix routen, statt so zu tun, als wäre das Feature fertig.

5. Halte Beweise außerhalb des Selbstberichts des Agents

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

Beweis kommt aus Checks, Tests, Logs und erfolgreichen Builds. Externe Signale schlagen internes Selbstvertrauen jedes Mal.

6. Schlafe bewusst

Ist nichts bereit, logge den State und schlaf.

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

Was dieses System eigentlich ist

Direkte Antwort auf die Frage: Ist es ein Crontab?

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

Ein Scheduler weckt das System alle 30 Minuten. 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:

1. Scheduler feuert
2. neue Session wacht auf
3. Orchestrator liest State
4. Orchestrator wählt den nächsten Schritt
5. ein 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:

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

Eine andere gültige Form:

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 passt

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

Das gleiche 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 State. Ein oder mehrere Spezialisten erledigen den engen Job. Die Gates entscheiden, ob der Output gut genug ist. Dann schläft der Schwarm wieder.

Das ist das ganze Modell.

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