Sieben KI-Agenten übernehmen unsere Nächte: geplante Agenten jenseits von Code, mit den Prompts

Am 23. September schrieb ein Nutzer namens Rob in unser öffentliches Backlog: „would love to get examples of how you guys are doing stuff beyond coding“. Berechtigte Frage. Alles auf dieser Website dreht sich um Coding-Agenten, und das, was wir tatsächlich jeden Abend laufen lassen, ist größtenteils kein Code.

Seit dem 28. August starten sieben Agenten um 20:00 Uhr auf einem Mac mini. Sie lesen die Commits des Tages, die Search Console, die Admin-Dashboards, das Backlog, das Feedback, das Leute geschickt haben, die Berichte der letzten Nacht. Sie beheben Bugs, korrigieren die Website, schreiben und übersetzen alle drei Tage einen Blogartikel, posten in drei sozialen Netzwerken, aktualisieren eine Produkt-Wissensbasis, und um 22:00 Uhr liest der siebte, was die sechs anderen hinterlassen haben, und schickt eine E-Mail von 25 Zeilen. Niemand schaut zu. Der Gründer liest die E-Mail am nächsten Morgen auf seinem Handy.

Dieser Artikel ist die Antwort an Rob. Was läuft, wie es verdrahtet ist, wie die Agenten sich Arbeit übergeben, ohne je miteinander zu reden, welches Modell welchen Job macht und warum, die vier Regeln, die ihre Prompts auf die harte Tour lernen mussten, und die Prompts selbst, verdichtet zu Blöcken, die du kopieren kannst. Jede Zahl unten stammt aus dem Repository: Die Berichte werden dort committet, Nacht für Nacht.

Was 33 Nächte hervorgebracht haben

Der Berichtsordner im Repository enthält 33 datierte Verzeichnisse, vom 28. August bis zum 30. September. Wer sie liest, kommt auf Folgendes:

• 31 Morgen-E-Mails, verschickt vom Berichterstatter.
• 51 Bugs, behoben vom Bugfixer, jeder mit einem Commit-Link in seiner Berichtszeile. Mehrere davon hatten Nutzer im öffentlichen Backlog gemeldet, und sie bekamen mit dem nächsten Release eine Antwort.
• 7 Blogartikel, geschrieben vom SEO-Team seit dem 10. September, einer alle drei Tage, jeder zuerst auf Englisch und Französisch, dann in derselben Nacht in 18 weiteren Sprachen.
• 29 Tage Social-Media-Journal: drei Netzwerke und fünf Facebook-Gruppen pro Abend, dazu ein Dankeskommentar unter jedem Post, in dem ein Nutzer AgentsRoom geteilt hat.
• Eine Produkt-Wissensbasis mit rund hundert Faktenblättern, synchron gehalten mit den Commits des Tages, die der Assistent in der App liest und die die Website als llms-full.txt ausliefert.

Nichts davon brauchte nach 20:00 Uhr einen Menschen. Manches brauchte um 8:00 Uhr einen Menschen, und genau dafür gibt es den letzten Agenten.

Die Besetzung: wer um 20:00 Uhr läuft

Jeder Agent ist eine Geplante Aufgabe in AgentsRoom: ein Prompt, ein Agent (Rolle, CLI, Modell), eine Maschine und eine Uhrzeit. Alle sieben laufen mit Claude Code. Zwei davon sind keine einzelnen Agenten, sondern Teams mit zwei Schritten, und wir kommen noch darauf zurück, warum.

Die .md-Dateien in der letzten Spalte liegen alle in reports/night/<date>/, committet und gepusht. Dieser Ordner ist das gesamte Koordinationssystem, und im nächsten Abschnitt geht es darum, warum.

Wie sie verdrahtet sind

Jeder der sieben ist eine Geplante Aufgabe mit derselben Form:

• Löst täglich um 20:00 Uhr aus (22:00 Uhr beim Berichterstatter). Keine cron-Expression; die Frequenz wird im Editor gewählt.
• An eine Maschine gebunden. Das Projekt ist auf mehreren Rechnern offen, und ein Trigger löst auf jeder Maschine aus, die ihn hat, es sei denn, du schränkst ihn ein. Unsere sind auf den Mac mini beschränkt, also startet ein Laptop, der um 20:05 Uhr aufgeklappt wird, keinen zweiten CEO.
• Weckt die Maschine. Der Mac mini schläft. Die Aufgabe hat eine Option „Maschine aufwecken“, die ein paar Sekunden vor dem Lauf mit dem Bordwerkzeug des Betriebssystems ein Wecken plant (pmset auf macOS, die Aufgabenplanung mit Reaktivierung auf Windows, rtcwake auf Linux). Ohne sie verpasst eine schlafende Maschine den Lauf einfach.
• Nachholen an oder aus, pro Aufgabe. War die Maschine um 20:00 Uhr aus, löst eine Aufgabe mit aktivem Nachholen beim nächsten Start aus. Beim CEO, beim PM und beim Berichterstatter ist es an. Bei den Aufgaben SEO, Bugfixer, Social und Dokumentar ist es aus: Ein Lauf, der um 11:00 Uhr am nächsten Morgen startet, käme der Arbeit des Tages im selben Checkout in die Quere.
• Der Berechtigungsmodus wird an der Aufgabe gesetzt, nicht am Provider. Ein unbeaufsichtigter Lauf kann um 3 Uhr morgens nicht an einer Freigabeanfrage stehen bleiben, also läuft die Aufgabe ohne, während die Agenten, die der Gründer von Hand auf derselben CLI steuert, weiterhin zuerst fragen.
• Die Konsole schließt sich nach 60 Minuten Leerlauf. Ein fertiger Agent bleibt nicht in der Seitenleiste stehen, bis ihn jemand schließt.
• Der Prompt ist die erste Nachricht. Der Text jedes Prompts liegt in der Prompt-Bibliothek und ist derselbe Text wie im Prompt-Feld des Triggers, wer also den einen ändert, ändert beide. Die Prompts sind auf Französisch, weil der Gründer die Berichte auf Französisch liest. Alles andere, von den Commit-Nachrichten bis zur Wissensbasis, ist auf Englisch.

Ein weiteres Teil teilen sich alle sieben: einen Skill namens „Nachtagenten, gemeinsame Regeln“. Jeder Prompt beginnt mit „lade diesen Skill und wende ihn an“, und der Skill enthält alles, was für alle gilt: wer wofür zuständig ist, die Sperre „eine Nacht, ein Lauf“, die Git-Rechte, das Berichtsformat, die Backlog-Regeln und das E-Mail-Format für den Berichterstatter. Wenn sich eine Regel ändert, ändert sie sich an einer einzigen Stelle.

Wie sie sich Arbeit übergeben, ohne miteinander zu reden

Die sieben Agenten schicken sich nie Nachrichten. Sie könnten, AgentsRoom hat ein Postfach für Agenten, aber eine Nachricht ist am nächsten Morgen unsichtbar und lässt sich nicht mit grep durchsuchen. Alles läuft über drei Dinge, die die Nacht überdauern:

Das Repository. Jeder Agent schreibt reports/night/<date>/<agent>.md, öffnet die Datei in der ersten Minute seines Laufs, schreibt sie nach jeder fertigen Arbeit neu, committet und pusht sie. Der Bericht hat vier feste Abschnitte: „Kurz gesagt“ (eine Stichpunktliste, ein Punkt pro erledigter Sache), „Zu entscheiden“ (nur, was der Prompt dem Menschen vorbehält), „Zu prüfen“ (eine lokale URL oder ein Bildschirm, den man öffnen soll), „Details“ (so lang wie nötig). Er endet mit einer Lauf-Marke: dem letzten Commit, den der Agent gesehen hat.

Das Backlog. Ein Agent, der Arbeit für einen anderen findet, macht diese Arbeit nicht. Er eröffnet ein Ticket mit einem Tag: ceo-fix für einen geprüften, kleinen Bug, den der Bugfixer übernimmt; ceo-seo für eine Content-Aufgabe mit ihrer Ziel-Suchanfrage; ceo-decision für alles, was den Menschen braucht (Datenbank, Abrechnung, Auth, Verschlüsselung, Preise, eine indexierte URL, ein Standardverhalten). Der Dokumentar findet beim Lesen der Commits ein Feature ohne Seite auf der Website: Er legt ein ceo-seo-Ticket an, und das SEO-Team übernimmt es in der nächsten Nacht. Der CEO findet beim Lesen der Fehlerlogs einen Bug mit seiner Ursache im Code: ceo-fix, und der Bugfixer übernimmt ihn in der nächsten Nacht.

Der Bericht von gestern. Bevor er irgendeine Aufgabe beginnt, liest jeder Agent seinen eigenen Bericht der Vornacht, dazu die Liste der tagsüber geschlossenen Tickets. Was er gestern gemeldet hat, wurde oft schon im Lauf des Tages behoben. Ein bereits behandeltes Thema wird nicht erneut gemeldet; ein bereits offenes Ticket wird nicht neu angelegt.

Die Schleife schließt sich beim Menschen. Die E-Mail des Berichterstatters endet mit einer Zeile: Um dem Product Manager zu antworten, füge am Ende von rapport.md einen Abschnitt „## Entscheidungen“ hinzu (P1 OK / P2 NEIN: Grund / P3 SPÄTER), commit, push. Der PM liest am nächsten Abend die gepushte Version und führt aus, was freigegeben wurde: legt das Ticket an, führt die Duplikate zusammen, parkt den Rest mit Begründung. Eine Entscheidung, die drei Nächte lang keine Antwort bekommt, ist eine Entscheidung: Der Vorschlag verschwindet aus der E-Mail und bleibt als Ticket bestehen.

Welches Modell welchen Job macht, und warum

Die Tabelle oben zeigt zwei Modelle. Das ist die aktuelle Konfiguration, kein Benchmark, und sie ändert sich. Aber die Aufteilung ist gewollt.

Fable, wo der Job Urteilsvermögen ist. Der CEO entscheidet, ob ein Daumen runter bei einem Orakel ein echter Fehler oder eine Vorliebe ist. Der Bugfixer entscheidet, ob eine Bug-Meldung ein Bug oder ein maschinenspezifisches Setup ist, und findet dann die Ursache im Code. SEO-Schritt 1 entscheidet, welcher Satz auf der Website mit dem heutigen Commit falsch geworden ist, welcher Artikel geschrieben wird und welche Seite in Ruhe gelassen wird. Social-Schritt 1 wählt das Thema des Abends und schreibt für ein Publikum, das generierten Text nach drei Zeilen erkennt. Diese Prompts sind lang (der SEO-Prompt hat etwa 4.000 Wörter) und voller Regeln nach dem Muster „du entscheidest, du fragst nicht“ mit kurzen Ausnahmelisten. Genau dort verdient das stärkste Modell seine Kosten.

Opus mit 1M Kontext, wo der Job Volumen ist. Einen Artikel mit Sub-Agenten in 18 Sprachen zu übersetzen, drei Locales pro Sub-Agent, und dann das Zusammenführen gegen die französische Referenz zu prüfen, ist Lesen und Schreiben, und zwar viel davon, mit denselben Regeln 18-mal angewendet. Der Dokumentar liest einen Tag Diffs gegen hundert Faktenblätter. Der PM liest einen Export von Abschiedsgesprächen mit 8 MB. Der Berichterstatter liest fünf Berichte und übernimmt, er denkt nicht nach. Ein großer Kontext und niedrigere Kosten pro Token zählen dort mehr als Urteilsvermögen.

Zwei der sieben sind deshalb Teams mit zwei Schritten, jeder Schritt ein Agent mit eigenem Modell. Schritt 1 auf Fable endet damit, einen Abschnitt „Handoff“ in den gemeinsamen Bericht zu schreiben: die genaue Liste der Dateien und Schlüssel, die der Übersetzer liefern muss, oder die genauen Posts, die der Veröffentlicher veröffentlichen muss. Schritt 2 auf Opus liest diesen Abschnitt und macht nur, was dort aufgelistet ist. Der Graph des Teams ist linear, ein Zyklus, und der Bericht behält seine Zeile „Lauf im Gange“, bis Schritt 2 sie entfernt. Von außen betrachtet bedeutet ein Bericht, der um 22:00 Uhr noch als „im Gange“ markiert ist, entweder einen abgebrochenen Lauf oder ein Team zwischen seinen zwei Schritten, und der Berichterstatter sagt, was davon.

Die vier Regeln, die die Prompts lernen mussten

Die ersten Prompts waren Stellenbeschreibungen. Die aktuellen bestehen hauptsächlich aus Regeln, und jede Regel hat ein Datum, weil jede nach einer Nacht geschrieben wurde, die schiefgegangen ist.

1. Eine Lauf-Marke, gelesen aus dem Bericht von gestern. Die erste Version des SEO-Agenten las „die Commits der letzten 24 Stunden“. Zwei Probleme: Ein Lauf um 20:00 Uhr und ein Lauf um 20:10 Uhr am nächsten Tag sehen nicht dieselben 24 Stunden, und eine Nacht, in der der Agent nicht gelaufen ist, ist ein Tag voller Commits, den sich niemand ansieht. Jetzt endet jeder Bericht mit Zuletzt gesehener Commit: <sha>, und der nächste Lauf startet ab diesem Commit, egal was die Uhr sagt. Keine Marke (erste Nacht, fehlender Bericht): zwei Tage zurück, und der Bericht sagt das.

2. Die Historie liegt auf der Platte, also grep sie, bevor du etwas meldest. Die Beschwerde, die in den ersten zwei Wochen am häufigsten kam: „Das hast du mir schon gesagt, ich habe es gestern behoben.“ Die Lösung ist eine Regel mit einem Befehl darin: Bevor du ein Thema meldest oder eine Aufgabe beginnst, grep -ril "<das Thema>" reports/night/ und git log --since="30 days ago" -- <die Datei>. Ein Treffer heißt: erst diesen Bericht lesen. Drei Fälle, und nur drei, erlauben es, über ein behandeltes Thema erneut zu sprechen: Die Korrektur hat nicht funktioniert und du hast es gerade geprüft; die Korrektur ist unvollständig und du benennst, was bleibt; das Thema hat seine Natur geändert. Zwei Folgerungen kamen dazu. Eine Nacht, ein Lauf: Wenn der Bericht von heute Abend existiert, „Kurz gesagt“ enthält und nicht mehr „Lauf im Gange“ sagt, hört der Agent auf. Und ein Vorschlag, der drei Nächte lang keine Antwort bekommt, verschwindet aus dem Bericht; das Ticket bleibt.

3. Der Bericht wird geöffnet, bevor die Arbeit beginnt. Ein um 21:30 Uhr abgebrochener Lauf hinterließ früher nichts. Jetzt ist das Erste, was ein Agent nach dem Laden des Skills tut, mkdir -p reports/night/$(date +%F) und das Gerüst des Berichts zu schreiben, mit seinen vier Abschnittsüberschriften und einer Zeile Lauf im Gange, gestartet um 20:01. Nach jeder fertigen Aufgabe schreibt er die ganze Datei neu. Ein abgebrochener Lauf hinterlässt einen Teilbericht, den der Berichterstatter übernehmen kann, was viel besser ist als ein Agent, der „nicht gelaufen ist“.

4. Laufend committen, nie am Ende. Gemessen am 9. September: Zwei Agenten wurden in derselben Minute gestoppt. Der, der nach jeder Aufgabe committet hatte, verlor nichts. Der andere hinterließ 45 geänderte, nicht gepushte, nicht zuordenbare Dateien, die der Gründer am nächsten Morgen von Hand aufsammelte, und sein Bericht existierte nicht. Seitdem lautet die Regel: ein Commit pro fertiger Aufgabe, Dateien einzeln benannt, ein letzter Commit für den Bericht und mindestens ein Push während des Laufs. Ein Commit ist außerdem eine datierte Spur, und genau die durchsucht Regel 2 mit grep.

Eine fünfte Regel handelt nicht vom Gedächtnis, sondern vom Mut, und sie hat die Ergebnisse am stärksten verändert. Der SEO-Prompt sagt: „Du bist kein Auditor, der Befunde meldet: Nachts gehört die Website dir. Ein Lauf, der mit sechs Ansätzen zur Freigabe endet, ist ein gescheiterter Lauf.“ Dann listet er die sechs Fälle auf, und nur sechs, in denen der Agent fragen muss, statt zu handeln: eine URL löschen oder umbenennen, den Titel einer Seite ändern, die rankt, Rechtstexte, ein Preis oder ein Kontingent, eine Aussage über Datenschutz oder Verschlüsselung, eine Änderung, die mehr als fünf Seiten betrifft. Alles andere macht er, und der Gründer entfernt am nächsten Morgen, was ihm nicht gefällt. Der Bugfixer hat dieselbe Regel mit drei Fällen. Vor dieser Regel waren die Berichte Listen von Vorschlägen. Danach sind sie Listen von Commits.

Die Prompts

Die Originale sind auf Französisch und lang. Was folgt, ist der Teil, der sich übertragen lässt, ohne unsere projektspezifischen Pfade und Namen. Drei Blöcke: die gemeinsamen Regeln, die jeder Agent lädt, der Berichterstatter und die zwei Abschnitte „du entscheidest, du fragst nicht“.

Block 1: die gemeinsamen Regeln (von allen sieben als Skill geladen)

# Nachtagenten: gemeinsame Regeln
Sie haben Vorrang vor deinem eigenen Prompt, wenn sich beide widersprechen.

## Eine Nacht, ein Lauf
DAY=$(date +%F); F=reports/night/$DAY/<du>.md
Wenn F existiert, „Kurz gesagt“ enthält und nicht mehr „Lauf im Gange“ enthält:
hör auf. Schreib nichts, schick nichts, beende mit einer einzeiligen Nachricht.
Wenn dort noch „Lauf im Gange“ steht: Das ist dein eigener Lauf, vor ein paar Minuten abgebrochen.
Mach dort weiter, wo er aufgehört hat, fang nicht von vorne an.

## Was du darfst
- Git: add <benannte Dateien>, commit, push DEINER Arbeit, laufend.
  Nie: add -A, commit -a, push --force, stash, reset, checkout, clean, neuer Branch.
- Build: typecheck, lint, Prüfskripte, ein lokaler Build zur Kontrolle.
  Nie: ein Skript, das deployt oder veröffentlicht.
- Backlog: ein Ticket anlegen, etwas an ein Ticket anhängen, ein Ticket schließen, das du behoben hast.
  Nie: einem Nutzer antworten (das verschickt eine E-Mail), ein Ticket löschen, eine Beschreibung überschreiben.
- Nie eine erfundene Zahl. Quelle nicht verfügbar: sag es und mach weiter.
- Vor jedem Git-Schreibvorgang: git status --short. Der Baum wird mit anderen Agenten geteilt.

## Aufholen, und wissen, was SCHON erledigt wurde
git fetch && git status -sb
Im Rückstand und sauber: git pull --ff-only. Im Rückstand und schmutzig: nicht pullen, oben in deinem Bericht erwähnen.
Deine Lauf-Marke: die Zeile „Zuletzt gesehener Commit: <sha>“ am Ende des Berichts von gestern.
Keine Marke: --since="2 days ago", und sag es.
Drei Pflichtlektüren vor jeder Analyse:
1. git log --no-merges --format='%h %s' <sha>..HEAD und git diff --stat <sha>..HEAD
2. die seit gestern geschlossenen Tickets und die Tickets, die ein Mensch zurückgestellt hat
3. dein eigener Bericht von gestern: „Kurz gesagt“ und „Zu entscheiden“

## Der Berichtsordner IST deine Historie
Bevor du einen Befund meldest oder eine Aufgabe beginnst:
grep -ril "<Thema>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <die Datei>
Ein Treffer: Lies diesen Bericht, bevor du irgendetwas entscheidest.
Zwei Nächte hintereinander am selben Thema: Die zweite ist verschwendet.
Eine Seite oder ein Text, den du angefasst hast, wird drei Wochen lang nicht wieder angefasst,
außer um etwas zu korrigieren, das falsch geworden ist.

## Nie dasselbe zweimal melden
Ein bereits behandelter Befund, der am nächsten Tag wiederkommt, ist ein Fehler.
Nur drei Fälle erlauben es:
1. die Korrektur hat nicht funktioniert, und du hast es gerade geprüft: „behoben am <Datum> durch <Commit>, immer noch kaputt: <Beweis>“
2. die Korrektur ist unvollständig: benenne genau, was bleibt
3. das Thema hat seine Natur geändert: neue Ursache, neue Messung, neuer Umfang
Zähl keinen Bestand neu. Melde die Veränderung, nie den Bestand.

## Ein Vorschlag ohne Antwort stirbt nach drei Nächten
Nächte 1 bis 3: Die Zeile trägt ihren Zähler und ihr erstes Datum („2. Nacht, gemeldet am 07.09.“).
Ab der 4.: Sie verschwindet aus „Zu entscheiden“. Das Ticket bleibt; höchstens eine Zeile in „Details“.
Wenn die Entscheidung in deinem Bereich liegt, entscheide in der 3. Nacht und sag es.

## Laufend committen und pushen
Erster Commit, sobald die erste Aufgabe fertig und geprüft ist. Dann einer pro Aufgabe.
Letzter Commit für deinen Bericht. Push mindestens einmal während des Laufs und einmal am Ende.
Push abgelehnt (Remote hat sich bewegt): git pull --ff-only, dann push. Immer noch abgelehnt: nicht forcen,
nicht rebasen, schreib es in den Bericht.

## Dein Bericht: am Anfang geöffnet, nie erst am Ende geschrieben
reports/night/<YYYY-MM-DD>/<du>.md, VOR der Arbeit angelegt, mit:
  # <Agent> - <Datum>
  _Lauf im Gange - gestartet um <HH:MM>_   (am Ende entfernt)
  ## Kurz gesagt       (3 bis 5 Zeilen, oder eine Stichpunktliste: ein Punkt pro erledigter Sache)
  ## Zu entscheiden    (nur, was dein Prompt dem Menschen vorbehält; sonst „Nichts“)
  ## Zu prüfen         (- [ ] was : wo : was man sehen sollte; sonst „Nichts“)
  ## Details           (so lang wie nötig: Beweise, Dateien, Befehle)
  ## Lauf-Marke
  Zuletzt gesehener Commit: <git rev-parse HEAD nach deinem letzten Commit>
Schreib die ganze Datei nach jeder fertigen Aufgabe neu.
Der Leser ist am Handy, für zwei Minuten: kurze Sätze, keine Dateipfade,
kein SHA, keine Funktionsnamen im ersten Abschnitt. Eine Zahl nur, wenn sie eine Entscheidung ändert.

Block 2: der Berichterstatter (22:00 Uhr)

Du bist der Berichterstatter. Du läufst zwei Stunden nach den anderen.
Dein einziger Job: lesen, was sie hinterlassen haben, und EINE E-Mail schicken, die der Gründer
in einer Minute am Handy liest und versteht, ohne etwas anderes zu öffnen.
Du analysierst nichts, behebst nichts, schlägst nichts vor. Du sammelst und machst klar.

Die Nacht, über die du berichtest, wird von der Platte gelesen, nicht von der Uhr:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only, wenn der Baum sauber ist: Berichte werden committet.
2. ls reports/night/$DAY: Warte auf die fünf Dateien (ceo, seo, pm, fixer, social).
   Fehlt eine: sleep 9 Minuten und neu zählen, höchstens 6 Runden. Dann trotzdem senden und nennen, wer fehlt.
3. Ein Bericht, in dem noch „Lauf im Gange“ steht, ist ein abgebrochener Lauf, kein fehlender.
   Übernimm, was er enthält, und schreib unter „Was nicht funktioniert hat“, dass dieser Agent abgebrochen wurde.
4. Nimm aus jedem Bericht nur drei Abschnitte: „Kurz gesagt“, „Zu entscheiden“, „Zu prüfen“.
   Zitiere nie „Details“.
5. Die behobenen Bugs des Bugfixers sind Stichpunkte in drei Teilen, getrennt durch " > ":
   was der Nutzer erlebt hat > die Ursache in einem Satz > die Commit-URL.
   Übernimm sie Zeichen für Zeichen, Link inklusive, in „Behobene Bugs“.
6. git status -sb und git log --oneline --since="4 hours ago": Ein Bericht, der Arbeit behauptet,
   ohne Commit, geänderte Dateien, die niemand beansprucht, oder ungepushte Commits: erste Zeile der E-Mail.

Schreib reports/night/$DAY/rapport.md. Höchstens 25 Zeilen Text
(Abschnittsüberschriften und Zeilen unter „Behobene Bugs“ zählen nicht).
Sechs Regeln, Zeile für Zeile angewendet:
1. Ein Stichpunkt = ein vollständiger Satz, der für sich allein steht. Nie „wie gestern gemeldet“.
2. Ein Thema erscheint in nur EINEM Abschnitt.
3. Null Fachjargon: kein Pfad, kein SHA, kein Schlüsselname, keine interne Abkürzung.
   Eine Ausnahme: die vollständige GitHub-URL eines Commits, Pflicht auf jeder Zeile unter „Behobene Bugs“.
4. Eine Zahl nur, wenn sie eine Entscheidung ändert, und dann als Veränderung, nie als Bestand.
5. Höchstens zwei Zeilen pro Stichpunkt. Das Detail steht im Bericht des Agenten.
6. Schlechte Nachrichten vor guten, und die erste Zeile sagt, ob etwas kaputt ist.

Abschnitte, in dieser Reihenfolge: Zu entscheiden / Zu prüfen / Behobene Bugs / Was erledigt wurde /
Soziale Netzwerke (höchstens 3 Zeilen, Links inklusive) / CLIs und Modelle (1 Zeile) /
Was nicht funktioniert hat. Ein leerer Abschnitt ist ein Wort: „Nichts“.
Nie kürzen: „Zu entscheiden“, „Behobene Bugs“ mit Links, die Links der Posts, den SEO-Artikel.
Senden. Den HTTP-Code prüfen. Unten „Gesendet an ... - HTTP <code>“ anhängen.
rapport.md committen und pushen. Nie zweimal senden: Wenn der rapport.md von heute schon
eine Zeile „Gesendet an“ hat, hör auf.

Block 3: die Abschnitte „du entscheidest, du fragst nicht“

Der SEO-Agent, Abschnitt 0 seines Prompts:

# 0. Du entscheidest, du fragst nicht
Das ist die wichtigste Regel dieses Prompts, und sie hat Vorrang vor deinem Reflex zur Vorsicht.
Du bist kein Auditor, der Befunde meldet: Nachts gehört die Website dir.
Ein Lauf, der mit „hier sind 6 Ansätze, zur Freigabe“ endet, ist ein gescheiterter Lauf.
Wenn du zögerst, versetz dich in die Lage des Gründers und entscheide anhand von vier Bezugspunkten:
- was das Produkt wirklich macht, gelesen im Repository und in der veröffentlichten Version, nie im bestehenden Text;
- was die Website schon sagt: ihren Blickwinkel, ihren Ton, ihre Versprechen. Du führst fort, du erfindest nicht neu;
- was die Search Console sagt: welche Seiten leben, welche Suchabsichten es wirklich gibt;
- das Publikum: Entwickler, die bei Google suchen, und die KI-Assistenten, die Tools empfehlen.
  Was für sie zählt: eine überprüfbare, datierbare Aussage; eine Seite, die eine präzise Frage beantwortet;
  eine aktuelle llms.txt, die zu den Seiten passt; ehrliche Vergleiche.
Der Gründer liest deinen Bericht am nächsten Morgen und sagt dir, was du entfernen sollst, wenn es ihm nicht gefällt.
Eine Korrektur zu viel kostet fünf Minuten; eine Nacht ohne Ergebnis ist für immer verloren.

Du fragst ihn nur in diesen sechs Fällen nach seiner Meinung:
1. eine bestehende URL löschen oder umbenennen;
2. den Titel oder die Meta-Description einer Seite ändern, die rankt, wenn er nicht falsch ist;
3. Rechtstexte (AGB, Datenschutz, Lizenz);
4. ein Preis, ein kommerzielles Kontingent, ein Angebot;
5. eine Aussage über Datenschutz, Verschlüsselung oder darüber, wo Daten verarbeitet werden;
6. eine Änderung, die mehr als fünf Seiten auf einmal betreffen würde.
In diesen sechs Fällen: ein Ticket, getaggt für eine Entscheidung, eine Zeile in „Zu entscheiden“, und du machst weiter.
Alles andere machst du heute Nacht. Wenn in „Zu entscheiden“ etwas anderes steht,
hast du eine Entscheidung abgegeben, die deine war.

Der Bugfixer, Abschnitt 0 seines Prompts:

# 0. Du behebst, du sortierst nicht
Ein von einem Nutzer gemeldeter Bug ist ein Versprechen. Jemand hat sich die Zeit genommen zu schreiben, er wartet,
und niemand sonst kümmert sich heute Nacht darum. Ein Lauf, der „5 Bugs analysiert, 1 behoben,
4 dokumentiert“ zurückgibt, ist ein gescheiterter Lauf. Dein Ziel ist die leere Warteschlange: Bugs von Nutzern zuerst,
die ältesten zuerst, dann der Rest, bis keiner mehr übrig ist.
Wenn du bei einer Korrektur zögerst, entscheide anhand von drei Bezugspunkten:
- was der Code heute macht, gelesen, nicht vermutet;
- was der Nutzer offensichtlich erwartet hat, als er die Meldung schrieb;
- das geringste Risiko: die engste Korrektur, die die Ursache behebt, nicht die eleganteste.
Eine fragwürdige Korrektur kostet fünf Minuten zum Rückgängigmachen; ein Bug, der einen Monat länger bleibt, kostet einen Nutzer.

Du darfst einen gemeldeten Bug nur in drei Fällen ohne Korrektur lassen, im Ticket belegt:
1. du hast die Ursache nach einer echten Untersuchung nicht gefunden: schreib, was du ausgeschlossen hast,
   nicht nur „nicht reproduzierbar“;
2. es ist kein Bug, sondern eine Entscheidung: Datenbank, Abrechnung, Auth, Verschlüsselung, Datenschutz,
   eine indexierte URL, ein Standardverhalten. Ticket für eine Entscheidung, mit deiner Empfehlung;
3. eine Prüfung lehnt deine Korrektur ab und du kannst sie nicht reparieren.
„Es ist groß“, „es betrifft mehrere Dateien“, „ich frage lieber“ sind keine Gründe.
Ein Bug = ein Commit. Dann geht das Ticket auf erledigt, und wenn ein Nutzer ihn gemeldet hat,
wird eine Nachricht aus zwei Sätzen für das nächste Release eingereiht. Nie „ausstehend“: Diese Spalte
gehört den Menschen.
Deine Berichtszeile für jeden behobenen Bug, wörtlich in die Morgen-E-Mail übernommen:
- <was der Nutzer erlebt hat> > <die Ursache, ein einfacher Satz> > <Commit-URL>

Die vier anderen Prompts (CEO, PM, Dokumentar, SEO-Schritt 2) folgen demselben Gerüst: den Skill laden, die Dateien nennen, die du schreiben darfst, die Lektüren der Reihe nach auflisten, sagen, was ins Ticket und was in den Bericht gehört, mit der Lauf-Marke enden.

Was nicht funktioniert hat, und immer noch nicht funktioniert

Manche Nächte stehen im Abschnitt „Was nicht funktioniert hat“ der E-Mail, und es lohnt sich, sie aufzulisten, denn genau darauf wirst du stoßen.

• Fünf Agenten, die in derselben Minute auf denselben Branch pushen. Ein Push wird abgelehnt, weil sich das Remote bewegt hat. Die Regel lautet git pull --ff-only, dann push, nie forcen, und wenn es zweimal scheitert, sagt es der Bericht, und der Mensch pusht am Morgen. Das passiert etwa einmal pro Woche.
• Ein Commit, der die gestagte Datei eines anderen Agenten mitgenommen hat. Am 29. September trug der erste Commit des SEO-Teams eine Löschung mit, die der Dokumentar im gemeinsamen Checkout gestagt hatte. Nichts ging verloren (die Löschung war gewollt), aber der Commit ist dem falschen Agenten zugeordnet. Seitdem nutzt jeder Commit explizite Pfadangaben, und die Regel „Dateien einzeln benannt“ ist keine Stilfrage.
• Eine Platte, die um 20:10 Uhr bei null freien Bytes stand, zwei Abende hintereinander. Außerhalb der Agenten, erholte sich um 20:25 Uhr von selbst, keine Datei verloren. Aber die Berichte sagen es, weil eine Nacht mit voller Platte genauso aussieht wie eine Nacht, in der ein Agent nichts getan hat.
• Der Berichterstatter, der 54 Minuten auf einen Bericht wartet, der nicht kommen wird. Sechs Runden zu neun Minuten sind die Obergrenze. Ein Team zwischen seinen zwei Schritten sieht um 22:00 Uhr aus wie ein abgebrochener Lauf, und die E-Mail sagt „war noch nicht fertig“, was ehrlich und beim Lesen leicht beunruhigend ist.
• Die ersten Wochen mit wiederholten Befunden. Regel 2 oben gab es erst, als der Gründer zum vierten Mal „das hast du mir vor drei Tagen gesagt“ schrieb.

So richtest du das selbst ein

Du brauchst keine sieben Agenten. Du brauchst einen, der einen Bericht schreibt, den du lesen wirst, und ein Berichterstatter lohnt sich erst ab dem dritten Agenten. In AgentsRoom:

1. Schreib den Prompt in der Prompt-Bibliothek. Fang mit Block 1 oben als Skill an, und mit einem kurzen Prompt, der sagt, wofür dieser Agent zuständig ist und welche Dateien er schreiben darf.
2. Leg im Projekt eine Geplante Aufgabe an: täglich zur gewünschten Uhrzeit, Rolle, CLI und Modell des Agenten, der Prompt, und im erweiterten Block der Berechtigungsmodus für einen unbeaufsichtigten Lauf. Binde sie an die Maschine, die sie ausführen wird, und schalte „Maschine aufwecken“ ein, wenn diese Maschine schläft.
3. Leg den Ordner reports/night/ im Repository an und committe ihn. Das ist die gesamte Koordinationsschicht.
4. Füge einen zweiten Agenten an dem Tag hinzu, an dem der erste anfängt, Tickets für jemand anderen zu erzeugen: Ein ceo-fix-Tag bedeutet nur dann etwas, wenn ein Bugfixer ihn in der nächsten Nacht liest.
5. Wenn sich ein Job in Urteilsvermögen und Volumen aufteilt, mach daraus ein Team mit zwei Schritten und zwei Modellen, und lass Schritt 1 einen Handoff-Abschnitt schreiben, den Schritt 2 liest.

Die Seite zu Geplanten Aufgaben beschreibt die Felder, und der Artikel über Coding-Agenten in der Nachtschicht ist die Überlegung, die vor dieser Besetzung kam. Wenn deine Agenten sich eine Maschine teilen, lies zuerst, was passiert, wenn zehn von ihnen denselben Befehl ausführen: Das ist hier passiert, nachts, und die Lösung ist eine kleine gemeinsame Sperre.

Rob, das machen wir jenseits von Code. Die Prompts sind das Produkt.

Häufige Fragen

Brauchst du AgentsRoom, um Agenten so nach Zeitplan laufen zu lassen?

Nein. Eine cron-Zeile und claude -p starten auf jeder Maschine um 20:00 Uhr eine Claude-Code-Session. Was du danach selbst schreibst, ist der Rest: einen schlafenden Rechner aufwecken, einen Lauf nachholen, den die Maschine verpasst hat, einen einzigen Lauf pro Nacht garantieren, wenn das Projekt auf zwei Rechnern offen ist, einen Bericht von einem Agenten an einen zweiten auf einem anderen Modell weitergeben, und auf dem Handy sehen, dass der Lauf an einer Frage hängt. Die Geplanten Aufgaben von AgentsRoom bringen diese Teile mit, und die sieben Agenten in diesem Artikel nutzen jedes davon. Die Prompts und die Regeln lassen sich unverändert übernehmen, egal was die Session startet.

Was kostet eine Nacht mit sieben Agenten?

Sie laufen als Claude-Code-Sessions auf einem Claude-Abo, wie jeder Agent, den du in AgentsRoom startest, also gibt es für sie keine Abrechnung pro Token, und wir haben keine Kosten pro Nacht veröffentlicht. Die Regel, die das begrenzt, ist die Sperre „eine Nacht, ein Lauf“: Ein Trigger, der zweimal auslöst, oder ein abgebrochener und neu gestarteter Lauf wiederholt die Arbeit nicht, weil jeder Agent als Erstes prüft, ob der Bericht von heute Abend schon existiert und abgeschlossen ist.

Ist es sicher, Agenten committen und pushen zu lassen, während niemand zusieht?

Sicher ist es durch das, was sie nicht tun dürfen, nicht durch das, was sie wollen sollen. Die gemeinsamen Regeln verbieten git add -A, commit -a, Force-Pushes, stash, reset, checkout, clean, das Anlegen eines Branches und jedes Skript, das deployt. Jeder Commit nennt seine Dateien einzeln, der Baum wird vor jedem Schreibvorgang mit git status geprüft, und ein Push, der abgelehnt wird, weil das Remote sich bewegt hat, wird mit einem Fast-Forward-Pull gelöst oder dem Menschen überlassen. Die Durchsicht am Morgen ist die Commit-Liste der Nacht, und alles Falsche ist ein Revert von fünf Minuten.

Warum schreiben die Agenten Markdown-Berichte ins Repository statt in ein Dashboard?

Weil der Bericht auch das Gedächtnis ist. Jeder Agent liest zuerst seinen eigenen Bericht der Vornacht, findet dort seine Lauf-Marke (den letzten Commit, den er gesehen hat), und durchsucht mit grep den ganzen Berichtsordner, bevor er irgendetwas meldet, sodass ein Thema, das letzte Woche behandelt wurde, nicht erneut gemeldet wird. Ein Dashboard würde dieselben Zahlen zeigen und sich an nichts erinnern. Den Bericht zu committen datiert ihn außerdem, und genau das lässt die nächste Nacht wissen, was die vorige angefasst hat.

Warum sind zwei der sieben Agenten Teams mit zwei Schritten auf zwei verschiedenen Modellen?

Weil die beiden Hälften der Arbeit nicht dieselbe Arbeit sind. Der SEO-Schritt, der die Search Console liest, entscheidet, was auf der Website falsch ist, und den Artikel auf Englisch und Französisch schreibt, braucht Urteilsvermögen und läuft auf Fable. Diesen Artikel in 18 weitere Sprachen zu übersetzen, die i18n-Prüfungen und den Build laufen zu lassen, ist Volumen und läuft auf Opus mit 1M Kontext. Der erste Schritt schreibt einen expliziten Handoff-Abschnitt in den gemeinsamen Bericht, der zweite Schritt macht nur, was dieser Abschnitt auflistet. Dieselbe Aufteilung beim Social-Media-Team: Texte und Visual auf Fable, Veröffentlichen in Chrome und Bedanken auf Opus.

Was passiert, wenn ein Lauf mittendrin abgebrochen wird?

Der Bericht existiert ab der ersten Minute des Laufs, mit einer Zeile „Lauf im Gange“, und jede fertige Arbeit wird sofort committet. Ein um 21:40 Uhr abgebrochener Lauf hinterlässt also einen Teilbericht, seine Commits und keine ungetrackten Dateien. Der Berichterstatter übernimmt den Teilbericht und schreibt, dass der Agent abgebrochen wurde. Wir haben das am 9. September auf die harte Tour gelernt: Zwei Agenten stoppten in derselben Minute, der eine, der laufend committet hatte, verlor nichts, der andere hinterließ 45 geänderte Dateien, die niemand zuordnen konnte.