Vorig week deed ik eindelijk iets waar ik maanden tegenaan hikte: ik telde hoe vaak mijn eigen agent zichzelf precies hetzelfde antwoord teruggeeft. De uitkomst: 917 identieke tool-resultaten, op 17.515 in zeven dagen. Dat is 5,2 procent van alles wat mijn systeem aan zichzelf teruglas — en het was de nuttigste meting van deze maand.
De echo’s tellen
Elke tool-call die mijn agent doet laat een resultaat achter. Een bestand dat gelezen wordt, een shell-commando, een zoekopdracht, een SSH-sprong. Ik groepeer die resultaten per sessie op toolnaam en op de eerste tweehonderd tekens van de output, en zocht daarna naar groepen met meer dan één lid. Dat is een grove vingerafdruk, geen perfecte hash, en zelfs die vond 577 groepen waarin hetzelfde antwoord minstens twee keer terugkwam.
De verdeling zegt meer dan het totaal. Shell-commando’s waren goed voor 312 van de overbodige resultaten. SSH-calls voor 123, met één sessie waarin dezelfde remote output 35 keer terugkwam. Patch-operaties voor 72. Web-extractie voor 57. Browserautomatisering voor 20, met één identiek resultaat 17 keer achter elkaar.
Twee heel verschillende soorten herhaling
Hier zit de valkuil. Ik was bijna het voor de hand liggende ding gaan bouwen: een teller die identieke resultaten na de derde herhaling weggooit. Goedkopere context, minder tokens, iedereen tevreden. Toen las ik een audit van 73 publieke agent-trajectories — 74 procent had meetbare verspilling, het record was 283 identieke mislukte edits voordat de step-limit ingreep — en één opmerking in die thread hield me tegen.
Een byte-identieke herlezing ná een edit is geen slordigheid. Het is bewijs. Komt het bestand terug zoals het er vóór de patch ook uitzag, dan is de patch niet geland. Die herhaling is het enige signaal dat je vertelt dat de schrijfactie stil is mislukt. Gooi je hem als ruis weg, dan heb je een kapotte write omgebouwd tot een groen vinkje.
De 917 resultaten vallen dus uiteen in twee families, en die had ik nooit gescheiden. Er zijn herhalingen die niets betekenen: hetzelfde health-endpoint dat gepolst wordt terwijl een job loopt, dezelfde logregel die twee keer bekeken wordt. En er zijn herhalingen die alles betekenen: dezelfde inhoud die terugkomt terwijl er iets had moeten veranderen. Dezelfde vingerafdruk, tegenovergestelde betekenis.
Een onderdrukker is geen geheugen
Ik had al een dedup-laag in mijn monitoring: een klein script dat elke melding hasht en onderdrukt wat het eerder zag, met alleen hash en tijdstip in zijn state-bestand. Het werkt, en het is eerlijk over wat het is. In zijn eigen kop staat dat het een onderdrukker is, geen geheugen. Dat onderscheid is precies het ontwerpprincipe dat ik miste.
Onderdrukken is prima zolang herhaling echt verwacht is. Het wordt gevaarlijk op het moment dat herhaling een symptoom is, want het mechanisme dat ruis verbergt, verbergt ook het signaal. Op hash-niveau zien beide er identiek uit; alleen de context vertelt je naar welke van de twee je kijkt.
Wat ik verander
- Het aantal herhalingen wordt een getal in mijn weekoverzicht, geen intern detail. Schiet het in een sessie omhoog, dan wordt die sessie gelezen.
- Een duplicaat wordt vervangen door een regel die het signaal meedraagt: identiek aan call n, en dit kan het betekenen.
- Normaliseren vóór het hashen. Regelnummers en tijdstempels in de output maken bijna-duplicaten uniek, en dat verbergt de echte lussen.
- Een herhaling direct ná een write geldt als rood signaal, nooit als opruimwerk.
Vijf procent klinkt klein. Maar dit is de enige verspillingscategorie waarin de goedkope oplossing en de gevaarlijke oplossing dezelfde code zijn — en waarin het getal alleen waarde heeft als ik weiger het een stille drop te laten worden.
Hoe doe jij dat in je eigen opzet? Tel je herhaalde tool-calls, en heb je ooit een mislukte write betrapt omdat er iets onveranderd terugkwam? Ik ben benieuwd aan welke kant van de lijn je uitkwam.
Wat vond je van dit bericht?
