Zeven AI-agents draaien onze nachten: geplande agents buiten het coderen, met de prompts

Op 23 september schreef een gebruiker die Rob heet op onze openbare backlog: ‘would love to get examples of how you guys are doing stuff beyond coding’. Terechte vraag. Alles op deze site gaat over coding-agents, en wat we echt elke avond laten draaien, is grotendeels geen code.

Sinds 28 augustus starten zeven agents om 20.00 uur op een Mac mini. Ze lezen de commits van de dag, de Search Console, de admin-dashboards, de backlog, de feedback die mensen stuurden, de rapporten van de vorige nacht. Ze lossen bugs op, corrigeren de website, schrijven en vertalen elke drie dagen een blogartikel, posten op drie sociale netwerken, werken een productkennisbank bij, en om 22.00 uur leest de zevende wat de zes anderen hebben achtergelaten en stuurt een mail van 25 regels. Niemand kijkt. De oprichter leest de mail de volgende ochtend op zijn telefoon.

Dit artikel is het antwoord aan Rob. Wat er draait, hoe het in elkaar zit, hoe de agents werk aan elkaar doorgeven zonder ooit met elkaar te praten, welk model welk werk doet en waarom, de vier regels die hun prompts op de harde manier moesten leren, en de prompts zelf, samengevat in blokken die je kunt kopiëren. Elk cijfer hieronder komt uit de repository: de rapporten worden daar gecommit, nacht na nacht.

Wat 33 nachten hebben opgeleverd

De rapportenmap in de repository bevat 33 gedateerde mappen, van 28 augustus tot 30 september. Als je ze leest, kom je hierop uit:

• 31 ochtendmails verstuurd door de rapporteur.
• 51 bugs opgelost door de bugfixer, elk met een commitlink in de regel van zijn rapport. Een aantal was door gebruikers gemeld op de openbare backlog en kreeg bij de volgende release een antwoord.
• 7 blogartikelen geschreven door het SEO-team sinds 10 september, één elke drie dagen, elk eerst in het Engels en het Frans, daarna dezelfde nacht in 18 andere talen.
• 29 dagen socialmediajournaal: drie netwerken en vijf Facebookgroepen per avond, plus een bedankreactie onder elke post waarin een gebruiker AgentsRoom deelde.
• Een productkennisbank van ongeveer honderd factsheets, synchroon gehouden met de commits van de dag, die de assistent in de app leest en die de site aanbiedt als llms-full.txt.

Niets hiervan had na 20.00 uur een mens nodig. Een deel had om 8.00 uur een mens nodig, en daar dient de laatste agent voor.

De bezetting: wie er om 20.00 uur draait

Elke agent is een Geplande taak in AgentsRoom: een prompt, een agent (rol, CLI, model), een machine en een tijdstip. Alle zeven draaien op Claude Code. Twee ervan zijn geen losse agents maar teams met twee stappen, en we komen erop terug waarom.

De .md-bestanden in de laatste kolom staan allemaal in reports/night/<date>/, gecommit en gepusht. Die map is het hele coördinatiesysteem, en de volgende sectie legt uit waarom.

Hoe het in elkaar zit

Elk van de zeven is een Geplande taak met dezelfde vorm:

• Gaat dagelijks af om 20.00 uur (22.00 uur voor de rapporteur). Geen cron-expressie; de frequentie kies je in de editor.
• Vastgezet op één machine. Het project staat open op meerdere computers, en een trigger gaat af op elke machine die hem heeft, tenzij je hem beperkt. De onze zijn beperkt tot de Mac mini, dus een laptop die om 20.05 uur wordt opengeklapt, start geen tweede CEO.
• Wekt de machine. De Mac mini slaapt. De taak heeft een optie ‘de machine wekken’, die een paar seconden voor de run een wekmoment plant met het eigen hulpmiddel van het besturingssysteem (pmset op macOS, Taakplanner met wekken om uit te voeren op Windows, rtcwake op Linux). Zonder die optie mist een slapende machine de run gewoon.
• Inhalen aan of uit, per taak. Als de machine om 20.00 uur uit stond, gaat een taak met inhalen aan af bij de volgende start. De CEO, de PM en de rapporteur hebben het aan. De taken SEO, bugfixer, social en documentalist hebben het uit: een run die de volgende ochtend om 11.00 uur start, zou in dezelfde checkout botsen met het werk van de dag.
• De permissiemodus staat op de taak, niet op de provider. Een onbewaakte run kan om 3 uur 's nachts niet blijven hangen op een goedkeuringsvraag, dus de taak draait zonder, terwijl de agents die de oprichter met de hand bestuurt op dezelfde CLI eerst blijven vragen.
• De console sluit na 60 minuten inactiviteit. Een agent die klaar is, blijft niet in de zijbalk staan tot iemand hem sluit.
• De prompt is het eerste bericht. De tekst van elke prompt staat in de Promptbibliotheek en is dezelfde tekst als het promptveld van de trigger, dus wie de ene aanpast, past beide aan. De prompts zijn in het Frans, omdat de oprichter de rapporten in het Frans leest. Al het andere, van commitberichten tot de kennisbank, is in het Engels.

Nog één onderdeel delen alle zeven: een skill met de naam ‘nachtagents, gedeelde regels’. Elke prompt begint met ‘laad deze skill en pas hem toe’, en de skill bevat alles wat voor iedereen geldt: wie waarvoor verantwoordelijk is, de bewaking ‘één nacht, één run’, de git-rechten, het rapportformaat, de backlogregels en het mailformaat voor de rapporteur. Als een regel verandert, verandert hij op één plek.

Hoe ze werk doorgeven zonder te praten

De zeven agents sturen elkaar nooit berichten. Dat zou kunnen, AgentsRoom heeft een postvak voor agents, maar een bericht is de volgende ochtend onzichtbaar en je kunt er niet met grep in zoeken. Alles loopt via drie dingen die de nacht overleven:

De repository. Elke agent schrijft reports/night/<date>/<agent>.md, opent het in de eerste minuut van zijn run, herschrijft het na elk afgerond stuk werk, commit en pusht het. Het rapport heeft vier vaste secties: ‘In het kort’ (een lijst met opsommingstekens, één punt per gedaan ding), ‘Te beslissen’ (alleen wat de prompt voor de mens reserveert), ‘Te controleren’ (een lokale URL of een scherm om te openen), ‘Details’ (zo lang als nodig). Het eindigt met een runmarkering: de laatste commit die de agent zag.

De backlog. Een agent die werk vindt voor een andere agent, doet dat werk niet. Hij opent een ticket met een tag: ceo-fix voor een geverifieerde, kleine bug die de bugfixer oppakt; ceo-seo voor een contentklus met de beoogde zoekopdracht; ceo-decision voor alles wat de mens nodig heeft (database, facturatie, auth, versleuteling, prijzen, een geïndexeerde URL, een standaardgedrag). De documentalist vindt bij het lezen van de commits een feature zonder pagina op de site: hij maakt een ceo-seo-ticket aan, en de SEO pakt het de volgende nacht op. De CEO vindt bij het lezen van de foutlogs een bug met zijn oorzaak in de code: ceo-fix, en de bugfixer pakt het de volgende nacht op.

Het rapport van gisteren. Voordat hij aan welke klus dan ook begint, leest elke agent zijn eigen rapport van de vorige nacht, plus de lijst met tickets die overdag zijn gesloten. Wat hij gisteren meldde, is vaak overdag al opgelost. Een onderwerp dat al behandeld is, wordt niet opnieuw aangekaart; een ticket dat al open staat, wordt niet opnieuw aangemaakt.

De lus sluit bij de mens. De mail van de rapporteur eindigt met één regel: om de productmanager te antwoorden, voeg je een sectie ‘## Beslissingen’ toe aan het einde van rapport.md (P1 OK / P2 NEE: reden / P3 LATER), commit, push. De PM leest de volgende avond de gepushte versie en voert uit wat is goedgekeurd: maakt het ticket aan, voegt de dubbele samen, parkeert de rest met de reden. Een beslissing die drie nachten geen antwoord krijgt, is een beslissing: het voorstel verdwijnt uit de mail en blijft staan als ticket.

Welk model welk werk doet, en waarom

De tabel hierboven toont twee modellen. Dit is de huidige configuratie, geen benchmark, en die verandert. Maar de verdeling is bewust.

Fable waar het werk oordeelsvermogen is. De CEO beslist of een duimpje omlaag op een orakel een echte fout is of een voorkeur. De bugfixer beslist of een bugmelding een bug is of een machinespecifieke setup, en vindt dan de oorzaak in de code. SEO-stap 1 beslist welke zin op de site door de commit van vandaag onjuist is geworden, welk artikel er geschreven wordt en welke pagina met rust wordt gelaten. Social-stap 1 kiest het onderwerp van de avond en schrijft voor een publiek dat gegenereerde tekst in drie regels herkent. Deze prompts zijn lang (die van de SEO telt ongeveer 4.000 woorden) en vol regels in de trant van ‘jij beslist, jij vraagt niet’ met korte lijsten van uitzonderingen. Daar verdient het sterkste model zijn kosten terug.

Opus met een context van 1M waar het werk volume is. Een artikel met subagents naar 18 talen vertalen, drie locales per subagent, en daarna de samenvoeging controleren tegen de Franse referentie, is lezen en schrijven, heel veel, met dezelfde regels 18 keer toegepast. De documentalist leest een dag aan diffs tegen honderd factsheets. De PM leest een export van 8 MB aan vertrekgesprekken. De rapporteur leest vijf rapporten en neemt over, hij denkt niet na. Een grote context en lagere kosten per token tellen daar zwaarder dan oordeelsvermogen.

Twee van de zeven zijn daarom teams met twee stappen, elke stap een agent met zijn eigen model. Stap 1 op Fable eindigt met het schrijven van een sectie ‘Overdracht’ in het gedeelde rapport: de exacte lijst met bestanden en sleutels die de vertaler moet opleveren, of de exacte posts die de publicist moet publiceren. Stap 2 op Opus leest die sectie en doet alleen wat daarin staat. De graaf van het team is lineair, één cyclus, en het rapport houdt zijn regel ‘run bezig’ tot stap 2 hem weghaalt. Van buitenaf gezien betekent een rapport dat om 22.00 uur nog op ‘bezig’ staat ofwel een afgebroken run, ofwel een team tussen zijn twee stappen, en de rapporteur zegt welke van de twee.

De vier regels die de prompts moesten leren

De eerste prompts waren functieomschrijvingen. De huidige zijn vooral regels, en elke regel heeft een datum, omdat elke regel is geschreven na een nacht die misging.

1. Een runmarkering, gelezen uit het rapport van gisteren. De eerste versie van de SEO-agent las ‘de commits van de afgelopen 24 uur’. Twee problemen: een run om 20.00 uur en een run om 20.10 uur de volgende dag zien niet dezelfde 24 uur, en een nacht waarin de agent niet draaide, is een dag aan commits waar niemand naar kijkt. Nu eindigt elk rapport met Laatst geziene commit: <sha>, en de volgende run start vanaf die commit, wat de klok ook zegt. Geen markering (eerste nacht, ontbrekend rapport): twee dagen terug, en het rapport zegt dat.

2. De geschiedenis staat op schijf, dus grep erin voordat je iets aankaart. De klacht die de eerste twee weken het vaakst terugkwam: ‘dat heb je me al verteld, ik heb het gisteren opgelost’. De oplossing is een regel met een commando erin: voordat je een onderwerp meldt of een klus opent, grep -ril "<het onderwerp>" reports/night/ en git log --since="30 days ago" -- <het bestand>. Een treffer betekent: lees eerst dat rapport. Drie gevallen, en alleen drie, maken het toegestaan om opnieuw over een behandeld onderwerp te beginnen: de fix werkte niet en je hebt dat net gecontroleerd; de fix is gedeeltelijk en je benoemt wat overblijft; het onderwerp is van aard veranderd. Er kwamen twee gevolgen mee. Eén nacht, één run: als het rapport van vanavond bestaat, ‘In het kort’ bevat en niet meer ‘run bezig’ zegt, stopt de agent. En een voorstel dat drie nachten geen antwoord krijgt, verdwijnt uit het rapport; het ticket blijft.

3. Het rapport wordt geopend voordat het werk begint. Een run die om 21.30 uur werd afgebroken, liet vroeger niets achter. Nu is het eerste wat een agent doet na het laden van de skill mkdir -p reports/night/$(date +%F) en het skelet van het rapport schrijven, met de vier sectietitels en een regel run bezig, gestart om 20:01. Na elke afgeronde klus herschrijft hij het hele bestand. Een afgebroken run laat een gedeeltelijk rapport achter dat de rapporteur kan overnemen, wat veel beter is dan een agent die ‘niet gedraaid heeft’.

4. Commit onderweg, nooit aan het einde. Gemeten op 9 september: twee agents werden in dezelfde minuut gestopt. Degene die na elke klus committe, verloor niets. De andere liet 45 gewijzigde, niet gepushte, niet toe te wijzen bestanden achter die de oprichter de volgende ochtend met de hand opraapte, en zijn rapport bestond niet. Sindsdien is de regel één commit per afgeronde klus, bestanden één voor één genoemd, een laatste commit voor het rapport, en minstens één push tijdens de run. Een commit is ook een gedateerd spoor, en dat is precies wat regel 2 met grep doorzoekt.

Een vijfde regel gaat niet over geheugen maar over moed, en die heeft de output het meest veranderd. De SEO-prompt zegt: ‘Je bent geen auditor die bevindingen rapporteert: 's nachts is de site van jou. Een run die eindigt met zes voorstellen om goed te keuren, is een mislukte run.’ Daarna somt hij de zes gevallen op, en alleen zes, waarin de agent moet vragen in plaats van handelen: een URL verwijderen of hernoemen, de titel wijzigen van een pagina die rankt, juridische tekst, een prijs of een quotum, een bewering over privacy of versleuteling, een wijziging die meer dan vijf pagina's raakt. Al het andere doet hij, en de oprichter haalt de volgende ochtend weg wat hem niet bevalt. De bugfixer heeft dezelfde regel met drie gevallen. Voor die regel waren de rapporten lijsten met suggesties. Daarna zijn het lijsten met commits.

De prompts

De originelen zijn in het Frans en lang. Wat volgt, is het deel dat overdraagbaar is, zonder onze projectspecifieke paden en namen. Drie blokken: de gedeelde regels die elke agent laadt, de rapporteur, en de twee secties ‘jij beslist, jij vraagt niet’.

Blok 1: de gedeelde regels (door alle zeven geladen als skill)

# Nachtagents: gedeelde regels
Ze gaan voor je eigen prompt als die twee elkaar tegenspreken.

## Eén nacht, één run
DAY=$(date +%F); F=reports/night/$DAY/<jij>.md
Als F bestaat, ‘In het kort’ bevat en niet meer ‘run bezig’ bevat:
stop. Schrijf niets, stuur niets, eindig met een bericht van één regel.
Als er nog ‘run bezig’ staat: dat is je eigen run, een paar minuten geleden afgebroken.
Ga verder waar hij stopte, begin niet opnieuw.

## Wat je mag doen
- Git: add <genoemde bestanden>, commit, push van JOUW werk, onderweg.
  Nooit: add -A, commit -a, push --force, stash, reset, checkout, clean, nieuwe branch.
- Build: typecheck, lint, controlescripts, een lokale build om te verifiëren.
  Nooit: een script dat deployt of publiceert.
- Backlog: een ticket aanmaken, iets toevoegen aan een ticket, een ticket sluiten dat je hebt opgelost.
  Nooit: een gebruiker antwoorden (dat verstuurt een mail), een ticket verwijderen, een beschrijving overschrijven.
- Nooit een verzonnen cijfer. Bron niet beschikbaar: zeg het en ga door.
- Voor elke git-schrijfactie: git status --short. De tree wordt gedeeld met andere agents.

## Bijwerken, en weten wat er AL gedaan is
git fetch && git status -sb
Achter en schoon: git pull --ff-only. Achter en vuil: niet pullen, zeg het bovenaan je rapport.
Je runmarkering: de regel ‘Laatst geziene commit: <sha>’ aan het einde van het rapport van gisteren.
Geen markering: --since="2 days ago", en zeg het.
Drie verplichte leesbeurten voor elke analyse:
1. git log --no-merges --format='%h %s' <sha>..HEAD en git diff --stat <sha>..HEAD
2. de tickets die sinds gisteren zijn gesloten, en de tickets die een mens in de wacht heeft gezet
3. je eigen rapport van gisteren: ‘In het kort’ en ‘Te beslissen’

## De rapportenmap IS je geschiedenis
Voordat je een bevinding aankaart of een klus opent:
grep -ril "<onderwerp>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <het bestand>
Een treffer: lees dat rapport voordat je iets beslist.
Twee nachten achter elkaar op hetzelfde onderwerp: de tweede is verspild.
Een pagina of tekst die je hebt aangeraakt, wordt drie weken niet opnieuw aangeraakt,
behalve om iets te corrigeren dat onjuist is geworden.

## Kaart nooit twee keer hetzelfde aan
Een al behandelde bevinding die de volgende dag terugkomt, is een fout.
Alleen drie gevallen staan het toe:
1. de fix werkte niet, en je hebt het net gecontroleerd: ‘opgelost op <datum> door <commit>, nog steeds kapot: <bewijs>’
2. de fix is gedeeltelijk: benoem precies wat overblijft
3. het onderwerp is van aard veranderd: nieuwe oorzaak, nieuwe meting, nieuwe reikwijdte
Tel een voorraad niet opnieuw. Meld de verandering, nooit de voorraad.

## Een voorstel zonder antwoord sterft na drie nachten
Nachten 1 tot 3: de regel draagt zijn teller en zijn eerste datum (‘2e nacht, gemeld op 07-09’).
Vanaf de 4e: hij verdwijnt uit ‘Te beslissen’. Het ticket blijft; hooguit één regel in ‘Details’.
Als de beslissing binnen jouw bereik valt, beslis dan in de 3e nacht en zeg het.

## Commit en push onderweg
Eerste commit zodra de eerste klus af en geverifieerd is. Daarna één per klus.
Laatste commit voor je rapport. Push minstens één keer tijdens de run en één keer aan het einde.
Push geweigerd (remote veranderd): git pull --ff-only, daarna push. Nog steeds geweigerd: niet forceren,
niet rebasen, schrijf het in het rapport.

## Je rapport: geopend aan het begin, nooit pas aan het einde geschreven
reports/night/<YYYY-MM-DD>/<jij>.md, aangemaakt VOOR het werk, met:
  # <Agent> - <datum>
  _run bezig - gestart om <HH:MM>_   (aan het einde weggehaald)
  ## In het kort       (3 tot 5 regels, of een lijst met opsommingstekens: één punt per gedaan ding)
  ## Te beslissen      (alleen wat je prompt voor de mens reserveert; anders ‘Niets’)
  ## Te controleren    (- [ ] wat : waar : wat je zou moeten zien; anders ‘Niets’)
  ## Details           (zo lang als nodig: bewijzen, bestanden, commando's)
  ## Runmarkering
  Laatst geziene commit: <git rev-parse HEAD na je laatste commit>
Herschrijf het hele bestand na elke afgeronde klus.
De lezer zit op een telefoon, twee minuten lang: korte zinnen, geen bestandspaden,
geen SHA, geen functienamen in de eerste sectie. Een cijfer alleen als het een beslissing verandert.

Blok 2: de rapporteur (22.00 uur)

Jij bent de rapporteur. Je draait twee uur na de anderen.
Je enige taak: lezen wat zij hebben achtergelaten en ÉÉN mail sturen die de oprichter
in één minuut op een telefoon leest en begrijpt zonder iets anders te openen.
Je analyseert niets, lost niets op, stelt niets voor. Je verzamelt en maakt duidelijk.

De nacht waarover je rapporteert, lees je van de schijf, niet van de klok:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; git pull --ff-only als de tree schoon is: rapporten worden gecommit.
2. ls reports/night/$DAY: wacht op de vijf bestanden (ceo, seo, pm, fixer, social).
   Ontbreekt er een: sleep 9 minuten en tel opnieuw, maximaal 6 rondes. Verstuur daarna toch, en noem wie ontbreekt.
3. Een rapport waarin nog ‘run bezig’ staat, is een afgebroken run, geen ontbrekende.
   Neem over wat erin staat en schrijf in ‘Wat niet werkte’ dat deze agent is afgebroken.
4. Neem uit elk rapport alleen drie secties: ‘In het kort’, ‘Te beslissen’, ‘Te controleren’.
   Citeer nooit ‘Details’.
5. De opgeloste bugs van de bugfixer zijn opsommingspunten in drie delen, gescheiden door " > ":
   wat de gebruiker ondervond > de oorzaak in één zin > de commit-URL.
   Neem ze teken voor teken over, link inbegrepen, in ‘Opgeloste bugs’.
6. git status -sb en git log --oneline --since="4 hours ago": een rapport dat werk claimt
   zonder commit, gewijzigde bestanden die niemand claimt, of niet-gepushte commits: eerste regel van de mail.

Schrijf reports/night/$DAY/rapport.md. Maximaal 25 regels tekst
(sectietitels en regels onder ‘Opgeloste bugs’ tellen niet mee).
Zes regels, regel voor regel toegepast:
1. Eén punt = één volledige zin die op zichzelf staat. Nooit ‘zoals gisteren gemeld’.
2. Een onderwerp verschijnt in maar ÉÉN sectie.
3. Nul jargon: geen pad, geen SHA, geen sleutelnaam, geen interne afkorting.
   Eén uitzondering: de volledige GitHub-URL van een commit, verplicht op elke regel onder ‘Opgeloste bugs’.
4. Een cijfer alleen als het een beslissing verandert, en dan als verandering, nooit als voorraad.
5. Maximaal twee regels per punt. Het detail staat in het rapport van de agent.
6. Slecht nieuws voor goed nieuws, en de eerste regel zegt of er iets kapot is.

Secties, in deze volgorde: Te beslissen / Te controleren / Opgeloste bugs / Wat er gedaan is /
Sociale netwerken (maximaal 3 regels, links inbegrepen) / CLI's en modellen (1 regel) /
Wat niet werkte. Een lege sectie is één woord: ‘Niets’.
Nooit inkorten: ‘Te beslissen’, ‘Opgeloste bugs’ met links, de links van de posts, het SEO-artikel.
Verstuur. Controleer de HTTP-code. Voeg onderaan ‘Verzonden naar ... - HTTP <code>’ toe.
Commit en push rapport.md. Verstuur nooit twee keer: als de rapport.md van vandaag al
een regel ‘Verzonden naar’ heeft, stop.

Blok 3: de secties ‘jij beslist, jij vraagt niet’

De SEO-agent, sectie 0 van zijn prompt:

# 0. Jij beslist, jij vraagt niet
Dit is de belangrijkste regel van deze prompt en hij gaat voor op je reflex om voorzichtig te zijn.
Je bent geen auditor die bevindingen rapporteert: 's nachts is de site van jou.
Een run die eindigt met ‘hier zijn 6 voorstellen, ter goedkeuring’ is een mislukte run.
Als je twijfelt, verplaats je dan in de oprichter en beslis met vier referentiepunten:
- wat het product echt doet, gelezen in de repository en de gepubliceerde versie, nooit in de bestaande teksten;
- wat de site al zegt: zijn invalshoek, zijn toon, zijn beloften. Je bouwt verder, je vindt niet opnieuw uit;
- wat de Search Console zegt: welke pagina's leven, welke zoekintenties echt bestaan;
- het publiek: developers die op Google zoeken, en de AI-assistenten die tools aanbevelen.
  Wat voor hen telt: een controleerbare, dateerbare bewering; een pagina die één precieze vraag beantwoordt;
  een actuele llms.txt die klopt met de pagina's; eerlijke vergelijkingen.
De oprichter leest je rapport de volgende ochtend en zegt je wat je moet weghalen als het hem niet bevalt.
Eén correctie te veel kost vijf minuten; een nacht zonder output is voorgoed verloren.

Je vraagt alleen in deze zes gevallen om zijn mening:
1. een bestaande URL verwijderen of hernoemen;
2. de titel of meta description wijzigen van een pagina die rankt, als die niet onjuist is;
3. juridische tekst (voorwaarden, privacy, licentie);
4. een prijs, een commercieel quotum, een aanbod;
5. een bewering over privacy, versleuteling of waar de data draait;
6. een wijziging die meer dan vijf pagina's tegelijk zou raken.
In die zes gevallen: een ticket getagd voor een beslissing, één regel in ‘Te beslissen’, en je gaat door.
Al het andere doe je vannacht. Als ‘Te beslissen’ iets anders bevat,
heb je een beslissing uitbesteed die de jouwe was.

De bugfixer, sectie 0 van zijn prompt:

# 0. Jij lost op, jij classificeert niet
Een bug die door een gebruiker is gemeld, is een belofte. Iemand heeft de tijd genomen om te schrijven, wacht af,
en niemand anders pakt het vannacht op. Een run die ‘5 bugs geanalyseerd, 1 opgelost,
4 gedocumenteerd’ oplevert, is een mislukte run. Je doel is de lege wachtrij: bugs van gebruikers eerst,
oudste eerst, daarna de rest, tot er geen meer over zijn.
Als je twijfelt over een fix, beslis met drie referentiepunten:
- wat de code vandaag doet, gelezen, niet aangenomen;
- wat de gebruiker duidelijk verwachtte toen hij de melding schreef;
- het kleinste risico: de smalste fix die de oorzaak oplost, niet de elegantste.
Een discutabele fix kost vijf minuten om terug te draaien; een bug die nog een maand blijft, kost een gebruiker.

Je mag een gemelde bug alleen in drie gevallen zonder fix laten, aangetoond in het ticket:
1. je hebt de oorzaak na echt onderzoek niet gevonden: schrijf op wat je hebt uitgesloten,
   niet alleen ‘niet reproduceerbaar’;
2. het is geen bug, het is een beslissing: database, facturatie, auth, versleuteling, privacy,
   een geïndexeerde URL, een standaardgedrag. Ticket voor een beslissing, met je aanbeveling;
3. een controle weigert je fix en je kunt die niet repareren.
‘Het is groot’, ‘het raakt meerdere bestanden’, ‘ik vraag het liever’ zijn geen redenen.
Eén bug = één commit. Daarna gaat het ticket naar klaar, en als een gebruiker het meldde,
wordt een bericht van twee zinnen klaargezet voor de volgende release. Nooit ‘in afwachting’: die kolom
is van de mensen.
Je rapportregel voor elke opgeloste bug, letterlijk overgenomen in de ochtendmail:
- <wat de gebruiker ondervond> > <de oorzaak, één eenvoudige zin> > <commit-URL>

De vier andere prompts (CEO, PM, documentalist, SEO-stap 2) volgen hetzelfde skelet: laad de skill, noem de bestanden die je mag schrijven, som de leesbeurten op in volgorde, zeg wat in het ticket komt en wat in het rapport, eindig met de runmarkering.

Wat niet werkte, en nog steeds niet werkt

Sommige nachten staan in de sectie ‘Wat niet werkte’ van de mail, en die zijn het waard om op te sommen, want daar ga jij ook tegenaan lopen.

• Vijf agents die in dezelfde minuut naar dezelfde branch pushen. Een push wordt geweigerd omdat de remote is veranderd. De regel is git pull --ff-only en dan push, nooit forceren, en als het twee keer mislukt, zegt het rapport dat en pusht de mens in de ochtend. Dat gebeurt ongeveer één keer per week.
• Een commit die een gestaged bestand van een andere agent meenam. Op 29 september nam de eerste commit van de SEO een verwijdering mee die de documentalist in de gedeelde checkout had gestaged. Er ging niets verloren (de verwijdering was bedoeld), maar de commit staat op naam van de verkeerde agent. Sindsdien gebruikt elke commit expliciete pathspecs, en de regel ‘bestanden één voor één genoemd’ is geen stijlvoorkeur.
• Een schijf die om 20.10 uur op nul bytes vrij stond, twee avonden achter elkaar. Buiten de agents om, om 20.25 uur vanzelf hersteld, geen bestand verloren. Maar de rapporten zeggen het, omdat een nacht met een volle schijf er precies zo uitziet als een nacht waarin een agent niets heeft gedaan.
• De rapporteur die 54 minuten wacht op een rapport dat niet komt. Zes rondes van negen minuten is het maximum. Een team tussen zijn twee stappen ziet er om 22.00 uur uit als een afgebroken run, en de mail zegt ‘was nog niet klaar’, wat eerlijk is en een beetje verontrustend om te lezen.
• De eerste weken met herhaalde bevindingen. Regel 2 hierboven bestond pas toen de oprichter voor de vierde keer ‘dat heb je me drie dagen geleden al verteld’ schreef.

Zo zet je dit zelf op

Je hebt geen zeven agents nodig. Je hebt er één nodig die een rapport schrijft dat je gaat lezen, en een rapporteur is pas nuttig vanaf de derde agent. In AgentsRoom:

1. Schrijf de prompt in de Promptbibliotheek. Begin met blok 1 hierboven als skill, en een korte prompt die zegt waar deze agent verantwoordelijk voor is en welke bestanden hij mag schrijven.
2. Maak een Geplande taak aan op het project: dagelijks op het uur dat je wilt, de rol, de CLI en het model van de agent, de prompt, en in het geavanceerde blok de permissiemodus voor een onbewaakte run. Zet hem vast op de machine die hem gaat draaien, en zet ‘de machine wekken’ aan als die machine slaapt.
3. Maak de map reports/night/ aan in de repository en commit hem. Dat is de hele coördinatielaag.
4. Voeg een tweede agent toe op de dag dat de eerste tickets begint te maken voor iemand anders: een ceo-fix-tag betekent pas iets als een bugfixer hem de volgende nacht leest.
5. Als één klus uiteenvalt in oordeelsvermogen en volume, maak er dan een team van twee stappen met twee modellen van, en laat stap 1 een overdrachtssectie schrijven die stap 2 leest.

De pagina over Geplande taken beschrijft de velden, en het artikel over coding-agents in de nachtploeg is de redenering die aan deze bezetting voorafging. Als je agents een machine delen, lees dan eerst wat er gebeurt als tien van hen hetzelfde commando draaien: het is hier gebeurd, 's nachts, en de oplossing is een kleine gedeelde lock.

Rob, dat is wat we doen buiten het coderen. De prompts zijn het product.

Veelgestelde vragen

Heb je AgentsRoom nodig om agents zo volgens schema te laten draaien?

Nee. Een cron-regel en claude -p starten om 20.00 uur op elke machine een Claude Code-sessie. Wat je daarna zelf schrijft, is de rest: een slapende computer wekken, een run inhalen die de machine heeft gemist, één run per nacht houden als het project op twee computers open staat, een rapport van de ene agent doorgeven aan een tweede op een ander model, en op je telefoon zien dat de run vastzit op een vraag. De Geplande taken van AgentsRoom leveren die onderdelen, en de zeven agents in dit artikel gebruiken ze allemaal. De prompts en de regels zijn één op één over te nemen, wat de sessie ook start.

Wat kost een nacht met zeven agents?

Ze draaien als Claude Code-sessies op een Claude-abonnement, zoals elke agent die je in AgentsRoom start, dus er is geen factuur per token voor, en we hebben geen kosten per nacht gepubliceerd. De regel die het begrensd houdt, is de bewaking ‘één nacht, één run’: een trigger die twee keer afgaat, of een run die wordt afgebroken en opnieuw gestart, doet het werk niet nog eens, want het eerste wat elke agent doet is controleren of het rapport van vanavond al bestaat en is afgesloten.

Is het veilig om agents te laten committen en pushen terwijl niemand kijkt?

Het is veilig door wat ze niet mogen doen, niet door wat ze volgens hun opdracht moeten willen. De gedeelde regels verbieden git add -A, commit -a, force pushes, stash, reset, checkout, clean, een branch aanmaken en elk script dat deployt. Elke commit noemt zijn bestanden één voor één, de tree wordt voor elke schrijfactie met git status bekeken, en een push die wordt geweigerd omdat de remote is veranderd, wordt opgelost met een fast-forward pull of aan de mens overgelaten. De controle in de ochtend is de commitlijst van de nacht, en alles wat fout is, is een revert van vijf minuten.

Waarom schrijven de agents Markdown-rapporten in de repository in plaats van een dashboard?

Omdat het rapport ook het geheugen is. Elke agent begint met het lezen van zijn eigen rapport van de vorige nacht, vindt daar zijn runmarkering (de laatste commit die hij zag), en doorzoekt met grep de hele rapportenmap voordat hij iets aankaart, zodat een onderwerp dat vorige week is behandeld niet opnieuw wordt aangekaart. Een dashboard zou dezelfde cijfers tonen en niets onthouden. Het rapport committen geeft het ook een datum, en dat laat de volgende nacht precies weten wat de vorige heeft aangeraakt.

Waarom zijn twee van de zeven agents teams met twee stappen op twee verschillende modellen?

Omdat de twee helften van het werk niet hetzelfde werk zijn. De SEO-stap die de Search Console leest, beslist wat er op de site niet klopt en het artikel in het Engels en het Frans schrijft, vraagt om oordeelsvermogen en draait op Fable. Dat artikel naar 18 andere talen vertalen, de i18n-controles en de build draaien, is volume en draait op Opus met een context van 1M. De eerste stap schrijft een expliciete overdrachtssectie in het gedeelde rapport, de tweede stap doet alleen wat die sectie opsomt. Dezelfde verdeling voor het socialmediateam: schrijven en de visual op Fable, publiceren in Chrome en mensen bedanken op Opus.

Wat gebeurt er als een run halverwege wordt afgebroken?

Het rapport bestaat vanaf de eerste minuut van de run, met een regel die zegt ‘run bezig’, en elk afgerond stuk werk wordt meteen gecommit. Een run die om 21.40 uur wordt afgebroken, laat dus een gedeeltelijk rapport achter, zijn commits en geen niet-gevolgde bestanden. De rapporteur neemt het gedeeltelijke rapport over en schrijft dat de agent is afgebroken. We hebben dit op 9 september op de harde manier geleerd: twee agents stopten in dezelfde minuut, degene die onderweg committe verloor niets, de andere liet 45 gewijzigde bestanden achter die niemand kon toewijzen.