Agenten während du schläfst: Die Runtime ist trivial, die Pipeline ist hart

Jeder Entwickler, der mit KI-Agenten baut, hatte denselben 3-Uhr-morgens-Traum. Du gehst schlafen. Eine Flotte von Agenten arbeitet dein Backlog ab, behebt Bugs, baut Features, und morgens reviewst du einen Stapel kleiner, getesteter, gut erklärter Änderungen. An schlechten Morgen reviewst du eine Katastrophe und bist froh, dass du sie erwischt hast.

Ich habe versucht, das real zu machen, und habe auf die harte Tour etwas Offensichtliches gelernt: Den Agenten-Prozess am Leben zu halten ist trivial. Die Arbeitspipeline ist das eigentliche Problem.

Die Runtime ist ein Wochenendprojekt

Es gibt vier Wege, einen Agenten rund um die Uhr laufen zu lassen, und keiner ist schwer:

• tmux — ein interaktiver Agent überlebt Disconnects und SSH-Logout
• cron + Print-Modus — pi -p "check the failing tests" auf einem Timer, One-Shot-Läufe, die sauber beenden
• RPC-Modus — ein langlebiger Prozess, mit dem ein anderes Programm spricht
• ein SDK-Daemon — bette den Agenten in deinen eigenen Node-Prozess ein und loop über eine Queue

Jeder davon läuft zweiundsiebzig Stunden am Stück ohne zu meckern. Und keiner davon wird einen einzigen nützlichen Commit produzieren. Weil die Frage nie war „wie halte ich den Prozess am Leben?“ Sie ist:

• woran arbeitet der Agent?
• was bedeutet done?
• wie landet die Arbeit?
• wie vermeiden mehrere Agenten, sich gegenseitig zu überschreiben?

Nenn diese vier Dinge die Task-Quelle, die Definition of Done, das Landing-Gate und den Allocator.

Was ~300 Läufe mich über den Überschreib-Teil gelehrt haben

Ich baue gitaccord, Git-Hooks, die mehreren KI-Agenten erlauben, parallel an einem Repo zu arbeiten. Es existiert wegen eines Fehlers, den ich wiederholt in Experimenten gesehen habe: Gib mehreren fähigen Agenten dasselbe Repository und lass sie Features auswählen und ihre eigene Arbeit mit plain Git landen — keine zentrale menschliche Merge-Autorität. Agenten lösen Merge-Konflikte gut. Das ist nicht die Gefahr.

Die Gefahr ist der Agent, der zuletzt landet und stillschweigend das Feature eines anderen Agenten umschreibt, damit es zu seinem passt, die Tests anpasst und Erfolg meldet. In unserem Spike, über etwa 300 Läufe mit Claude Code (Sonnet) und pi (GLM), passierte das in 24–28 % der Läufe auf plain Git. Nirgends Böswilligkeit. Jeder Agent tat genau das, was ein wohlerzogener Solo-Agent tun sollte. Der Fehler war strukturell: Die Agenten konnten die Pläne und das Reasoning der anderen nicht sehen, also wurde „merge“ stillschweigend zu „overwrite“.

gitaccords Fix ist absichtlich langweilig. Ein Branch pro Agent. Eine Plan-Datei pro Task, die jeder Agent liest. Eine Why:-Zeile auf jedem Commit, die das Reasoning erklärt. Ein pre-push-Gate, das jede Änderung ablehnt, die das Feature eines anderen Agenten kaputtmacht, es sei denn, sie ist als Override: für menschliches Review deklariert. In denselben ~300 Läufen: Stille Overrides gingen auf 0 %, main wurde nie kaputt gelassen, und jede No-Win-Entscheidung wurde für einen Menschen geflaggt statt still gelöst.

Von den vier Teilen würde ich also sagen, dass Landing-Gate und Allocator lösbar sind — hauptsächlich mit Konventionen und Hooks, nicht mit neuen Plattformen.

Welche Jobs tatsächlich über Nacht funktionieren

Die Einschränkung ist nicht die Fähigkeit des Agenten. Es ist, ob done maschinenprüfbar ist. Ein schlafender Mensch kann um 3 Uhr morgens nicht gefragt werden „ist das das Feature, das du meintest?“

Was funktioniert:

• Bugfixes mit einem fehlschlagenden Repro. Roter Test wird grün, volle Suite besteht, Diff ist klein.
• Testabdeckungs-Erweiterung auf bestehendem Code — Abdeckung hoch, Verhalten nachweislich unverändert.
• Kleine, vollständig spezifizierte Features, aus einem von Menschen geschriebenen Plan geschnitten.
• Dependency-Upgrades, bei denen die Suite entscheidet.
• Triage — Bugreport reproduzieren, den fehlschlagenden Test schreiben, den Fix auf einem Branch draften. Es muss nicht einmal landen.

Was über Nacht nicht funktioniert — und hier sterben viele 24/7-Agenten-Träume still:

• „Figure out what to build next.“ Offene Richtung hat kein maschinenprüfbares Done. Es gibt aber eine richtige Form dafür: Ein Agent schreibt einen Vorschlag + Spike + fehlschlagenden Acceptance-Test auf seinem Branch und landet ihn nicht. Du genehmigst die Richtung am Morgen. Landing-Autonomie war immer das leichtere Problem; Richtungs-Autonomie ist die, die du behalten solltest.

Die Overnight-Schleife

Wie das Ganze aussieht, wenn es funktioniert:

Abend            Nacht                               Morgen
─────────          ──────────────────────────────      ──────────────
Mensch schreibt/   Agent nimmt Task N                  Mensch liest einen Digest:
backlog ─────────▶ schreibt seinen Plan                ▸ was gelandet ist
                   implementiert, testet, committed    ▸ geflaggte Overrides &
                   merged main, passiert das Gate        No-Win-Entscheidungen
                   wiederholt für Task N+1 …           ▸ Vorschläge, die auf Richtung warten

Die Regeln, die es bis zum Morgen am Leben halten:

• Kleine Tasks. Lange autonome Läufe verrotten durch Context Drift. Ein Bug pro Task, ein Slice pro Feature.
• Begrenzte Autonomie. Ein Cap pro Nacht, ein Budget pro Lauf, Branches pro Agent. Ein fehlgeschlagener Task wird aufgezeichnet und die Schleife macht weiter statt zu thrashen.
• Ein Output, den du lesen musst: die Flag-Queue. Die Aufgabe des Systems ist, diese Queue kurz und high-signal zu machen — die Override:s und No-Win-Entscheidungen — damit dein Morgen-Review Minuten dauert, nicht Stunden.

Beachte, wo das harte Engineering lebt. Eine Daemon-Schleife sind hundert Zeilen. Das Backlog-Format, der Allocator, der Digest-Generator — dieser Kleber zwischen menschlicher Richtung und Agenten-Ausführung ist der echte Build. Fast niemand hat ihn produktisiert, weil alle (mich eingeschlossen) immer wieder am Polieren der Agenten-Runtime hängen bleiben.

Wo ich bin, ehrlich

Ich habe die Overnight-Schleife noch nicht laufen. Ich habe den harten Mittelteil in Arbeit: die Hooks und Konventionen, die Agenten davon abhalten, die Arbeit der anderen zu zerstören, wenn es kein menschliches Gate gibt. Die Runtime-Optionen sitzen da bereit. Das fehlende Stück ist die langweilige Pipeline — und mein Plan ist, sie zuerst auf gitaccord selbst laufen zu lassen: Das Backlog, jeden Hook vom Spike zur echten Implementierung zu portieren, schreibt sich selbst, und wenn Overnight-Agenten etwas kaputtmachen, ist mein eigenes Landing-Gate der billigste Ort, das zu lernen.

Was ich von dir hören will

Wenn du versucht hast, Agenten unbeaufsichtigt laufen zu lassen — oder entschieden hast, es nicht zu tun — will ich hören, wo es kaputtging:

• Was ist deine Job-Quelle? Backlog-Dateien, GitHub Issues, etwas anderes?
• Wie sah deine Definition of Done aus, und haben Agenten Schlupflöcher darin gefunden?
• Hast du Arbeit auf einen Main-Branch landen lassen, oder sie für Morgen-Review in eine Queue gestellt?
• Hat jemand ein gutes Task-Allocator- / Digest-Tool ausgeliefert, oder rollt jeder das von Hand?

Die Runtime-Kriege sind vorbei. Die Pipeline ist, wo das gewonnen oder verloren wird.