Vier weken lang gooide mijn agent-vloot mijn akkoorden weg
Vijf autonome agents draaien elk kwartier op de Mac Mini en leggen hun voorstellen aan mij voor. Toen bleek dat een filter met een NULL-waarde elk beantwoord besluit stil weggooide.
Het probleem
Ik heb vijf autonome agents naast de engineer: een onderzoeker, een schrijver, een analist, een coordinator en een delivery-PM. Ze draaien elk kwartier op hun eigen cron-minuut, pakken taken op uit hun eigen baan, en leveren voorstellen op. Geen van hen publiceert of pusht iets. Ze stellen voor, ik beslis.
Die beslissing loopt via een reviewpagina op mijn dashboard: open beslissingen met een aanbevolen optie voorgeselecteerd, akkoord of afwijzen, of terug naar de maker met een instructie. En precies daar ging het mis, zonder dat iets een fout gaf.
Wat ik gebouwd heb
Vijf banen, vijf caps: elke agent heeft een eigen taakbaan, een dagelijkse limiet en een eigen uitvoermap. Voorstellen alleen, geen mutaties in de wachtrij.
Maker-checker per baan: een aparte beoordelaar scoort het werk en geeft maximaal een revisieronde. Vlaggen, niet blokkeren: het stuk landt altijd, slecht werk landt gemarkeerd.
Reviewbrug: mijn antwoorden op de reviewpagina worden opgepikt door een consument die de instructie terugschrijft en de taak opnieuw laat draaien.
Kosten per geaccepteerde wijziging: elke run schrijft kosten en tokens weg, zodat ik per baan zie wat een geaccepteerd stuk werk kost.
Waakhond: staat een beantwoord besluit langer dan zes uur stil, dan krijgt mijn dagmail een rode banner en een ander onderwerp.
Wat ik geleerd heb
Een filter dat rijen uitsluit op basis van een reden werkt niet op rijen zonder reden. In SQL is "geen reden" niet hetzelfde als "niet deze reden": de vergelijking levert NULL op, en NULL is niet waar. Elke rij van een detector viel zo door de mand.
Vier weken lang signaleerden de agents correct, tikte ik akkoord, en gebeurde er niets. Dezelfde foutmelding kwam elke dag terug, want de oplossing werd stil weggegooid. Stil falen is erger dan hard falen.
Ik maakte dezelfde fout opnieuw in de waakhond die ik in diezelfde sessie bouwde. Dit is dus geen eenmalige uitglijder maar een valkuil die je actief moet afvinken.
Een terugtoets loont: de waakhond zou bij deze storing na een dag hebben gepiept in plaats van na vier weken.
Resultaat
Acht liggende beslissingen zijn alsnog verwerkt, binnen vier minuten opgepakt door de juiste baan. De brug heeft nu een waakhond die mij waarschuwt als mijn antwoorden blijven liggen, en elke filterregel op een veld dat leeg kan zijn krijgt er expliciet de lege waarde bij.