Drie skills die voorkomen dat agentic work in entropie verandert

Dit artikel bespreekt alleen herbruikbare methoden. Namen van echte tools, lokale paden, resource-identifiers, klantinformatie, accounts, infrastructuurtopologie en operationele parameters zijn bewust weggelaten.

AI-agents maakten mij sneller. Ze vergrootten ook drie oude engineeringproblemen uit.

Ten eerste stapelen code, bestanden, automatisering en tussenproducten zich op. Agents zijn goed in dingen toevoegen. Ze weten niet vanzelf wanneer iets zijn laatste echte gebruiker heeft verloren.

Ten tweede kunnen agents parallel werken, terwijl een database, poort, GPU, simulator of lokale service nog steeds maar één keer bestaat. Parallelisme wordt dan al snel onderlinge verstoring.

Ten derde gaan verklaringen schuiven wanneer systemen groeien. Een ontwerp beschrijft intentie, de runtime toont huidig gedrag en een log bewijst dat een gebeurtenis plaatsvond. Toch worden ze vaak als hetzelfde soort feit behandeld.

Ik schreef voor elk probleem één skill: Grote schoonmaak, Stoelendans en Whiteboard.

Een entiteit of systeem
→ Grote schoonmaak: hoort dit nog te bestaan?
→ Stoelendans: wie mag het nu bedienen?
→ Whiteboard: begrijpen we hetzelfde systeem?

GitHub-repository: zhaidewei/agent-skills — geschoonde, herbruikbare versies van alle drie de skills, inclusief installatie-instructies.

Grote schoonmaak: verwijder op verantwoordelijkheid, niet op leeftijd

Opschonen is geen zoektocht naar bestanden die zes maanden niet zijn gewijzigd. Oude code kan een stabiele authority zijn. Een bestand van gisteren kan al een onbeheerde kopie zijn.

De beslisketen is kort:

Heeft het een echte consumer en trigger?
→ Is het een source of truth of een projection?
→ Levert de projection unieke waarde?
→ Waardoor blijft die waarde correct?
→ behouden / waarschuwen / archiveren / verwijderen

Een source of truth neemt een beslissing. Een projection maakt die beslissing bruikbaar als index, rapport, manifest, gegenereerde configuratie of cache. Projections zijn nuttig. Gevaarlijk wordt het wanneer een projection geen unieke waarde of synchronisatiemechanisme heeft, maar er nog wel betrouwbaar uitziet.

Mijn regels:

1. Behoud een source of truth met een echte consumer, trigger en noodzakelijke verantwoordelijkheid.
2. Behoud een projection die performance, compatibiliteit, auditability of een andere consumptievorm toevoegt, zolang generatie, validatie of expiry haar correct houdt.
3. Waarschuw wanneer een projection waarde heeft maar geen betrouwbaar onderhoudsmechanisme.
4. Archiveer of verwijder iets zonder consumer, authority-rol of onderhouden unieke waarde.

Deze skill vermindert vooral valse beloften: dingen die levend lijken nadat het systeem is gestopt ze te onderhouden.

Stoelendans: gedeelde resources hebben leases nodig

Meerdere agents die documentatie lezen is meestal onschuldig. Meerdere agents die dezelfde database herbouwen, service herstarten of poort claimen is dat niet.

Bij Stoelendans krijgt een deelnemer via een gedeelde registry een lease met een eindtijd. Het model is groter dan locked/unlocked:

Resourcedefinitie + health + capaciteit
→ availability-preflight
→ atomische lease met TTL
→ operatie
→ evidence en health check
→ release

Ik onderscheid drie modi:

• read voor aantoonbaar side-effect-vrije observatie;
• write voor mutaties, task triggers en onzekere operaties;
• destroy voor stoppen, herstarten, herbouwen, verwijderen of andere acties die bestaande gebruikers onderbreken.

Een beschikbaarheidscheck reserveert niets. Tussen check en operatie kan een andere agent de resource nemen. De uiteindelijke lease moet daarom atomisch worden verkregen. Iedere lease heeft een TTL, wordt bij lang werk verlengd en bij succes, fout, annulering of handoff vrijgegeven.

Dit is coördinatie, geen beveiliging. Een lease helpt clients die zich aan de regels houden. Ze verleent geen rechten en vervangt database-autorisatie, OS-isolatie of cloud-IAM niet.

De skill verandert verborgen botsingen in zichtbare toestanden waarop kan worden gewacht en die kunnen worden uitgelegd.

Whiteboard: leg causaliteit uit, geen woordenlijst

Ik lees vaak documentatie waarin elke term is gedefinieerd, maar niemand kan zeggen welk feit wint wanneer het systeem zichzelf tegenspreekt.

De Whiteboard-skill bouwt een causaal model dat iemand anders kan navertellen:

Externe feiten
→ interne authority / source of truth
→ projection / manifest
→ runtime-executie
→ evidence / lineage / outcome
→ interpretatie door consumers

Dit is geen invuloefening; ontbrekende lagen mogen niet worden verzonnen. De uitleg moet wel beantwoorden:

1. Waar is elk object verantwoordelijk voor, en waarvoor expliciet niet?
2. Wat leest het en wie leest het?
3. Wie beslist bij conflicterende feiten?
4. Is de relatie één-op-één, één-op-veel of veel-op-veel?
5. Verklaart de huidige versie de historie, of is een exacte historische versie nodig?
6. Wat bewijst een log of evidence-item wel en niet?
7. Wat gebeurt bij nul of meerdere matches, ontbrekende evidence of drift?

“Wat zou moeten gebeuren” blijft gescheiden van “wat gebeurde”. Configuratie drukt intentie uit, runtime voert uit en logs registreren uitkomsten. Een log wordt niet vanzelf source of truth omdat het dicht bij het incident staat.

Een goede whiteboard-uitleg begint met de conclusie, tekent één causale keten, geeft 6–12 genummerde uitspraken die de lezer kan herhalen en eindigt met een paar blijvende invarianten. De lezer moet een nieuw geval kunnen beredeneren, niet alleen mijn woorden onthouden.

De drie samen

Stel dat meerdere agents een gedeelde lokale testomgeving onderhouden.

Grote schoonmaak bepaalt welke configuraties, caches en oude scripts nog consumers hebben, welke authority is en welke projections zijn. Dat verlaagt het aantal objecten dat moet worden begrepen en onderhouden.

Stoelendans bepaalt wie mag lezen, schrijven of een rebuild mag doen die anderen onderbreekt. Dat verlaagt conflicten tijdens parallelle uitvoering.

Whiteboard zet configuratie, gegenereerde artefacten, draaiende services, logs en testresultaten terug op hun juiste causale plek. Dat verlaagt verschil in begrip tussen mensen en agents.

Alle drie lossen hetzelfde hogere probleem op: laat snelheid niet sneller entropie produceren dan het team haar kan begrijpen en besturen.