Hoe een goed wrijvingsrecord eruitziet

Waarom documenten, en geen herinneringen?

Wrijving tijdens één sessie is slechts ruis. Dezelfde wrijving gedurende acht sessies vormt een patroon dat uw team kan verhelpen — maar alleen als die acht sessies gegevens hebben opgeleverd die u daadwerkelijk samen kunt bestuderen: consistent (hetzelfde schema, zodat ze vergelijkbaar zijn) en betrouwbaar (op bewijsmateriaal gebaseerde observaties, geen vage indrukken).

Geen van beide gebeurt standaard. Het moment waarop wrijving optreedt, is het moment waarop de informatie daarover het meest volledig is — de exacte verouderde regel in het runbook, de exacte parameter die in de instructie open werd gelaten. Die informatie vervaagt snel. De agent normaliseert zijn eigen tijdelijke oplossing binnen enkele beurtcycli, en aan het einde van de sessie is het signaal verdwenen, tenzij iemand het heeft opgeschreven; wat een subagent ook ontdekt, „verdwijnt op het moment dat het wordt geretourneerd“ (Hindsight, mei 2026). Dit hoofdstuk gaat over het opschrijven.

Hoe wrijving wordt opgemerkt

Voordat er iets kan worden vastgelegd, moet het eerst worden opgemerkt. Vier kanalen, en elk ziet iets anders:

De agent merkt dat hij moeite heeft. Herhalingslussen, terugkoppelen, hetzelfde bestand opnieuw inlezen of dezelfde analyseweergave opnieuw opvragen – een gok die wordt gedwongen door een leemte in de opdrachtomschrijving. Productieplatforms zijn in wezen tot deze lijst met gedragssignalen gekomen (Factory Signals, januari 2026). Het goedkoopste kanaal, met twee duidelijke beperkingen: het is blind voor afwezige zaken (een herhalingslus wordt waargenomen; een document dat nooit heeft bestaan, produceert geen signaal), en zelfobservatie gaat sneller dan zelfdiagnose — modellen kunnen hun eigen agentfouten slecht lokaliseren, zelfs bij zorgvuldig geselecteerde sporen (~11%, TRAIL). De taak tijdens de sessie is dus om symptomen waar te nemen en bewijs aan te voeren, waarbij de diagnose losjes wordt gehanteerd.

Een tweede medewerker controleert het transcript. Een onbevooroordeelde controleur merkt op wat de uitvoerende medewerker als normaal heeft beschouwd. Dit is objectiever; het vergt echter een tweede controle en brengt zijn eigen beoordelingsfouten met zich mee.

Een mens corrigeert de agent. Nog steeds de dominante sensor: uit een productieonderzoek van acht weken bleek dat ongeveer 70% van de stille storingen bij agents voor het eerst werd opgemerkt door een persoon die merkte dat er iets niet klopte — niet door unit-tests, gezondheidscontroles of governance-audits (arXiv 2606.14589). Elke correctie (zoals het „nee, ik bedoelde…“ van een beoordelaar of een belanghebbende die de opdracht halverwege de audit opnieuw uitlegt) geeft precies aan waar de context afweek van de bedoeling, en de agent kan dit op dat moment vastleggen zonder extra proceskosten.

Telemetrie. Foutpercentages bij tools, geweigerde machtigingen, aantal herhalingen, lange doorlooptijden. Automatisch en objectief, maar oppervlakkig: het weet dat er iets is gebeurd, maar niet waarom.

De meest effectieve werkwijzen vormen een driehoek: telemetrie geeft aan waar u moet zoeken, een controlebeurt legt uit waarom, en handmatige correctie vult de categorie problemen aan die geen enkel automatisch signaal kan opsporen. Welke combinatie u ook toepast, het resultaat zou altijd hetzelfde moeten zijn: een record.

Wat zorgt ervoor dat de agent dit vastlegt?

Een agent registreert geen wrijving waarnaar hij niet is geïnstrueerd om te zoeken. De meeste wrijving blijft ongeregistreerd, niet omdat deze niet werd opgemerkt, maar omdat er geen aanleiding was om deze vast te leggen. Vier mechanismen, die voornamelijk verschillen in wat ervoor zorgt dat er een signaal wordt afgegeven:

• Een vaardigheid: een van een versie voorzien, schriftelijk vastgelegde procedure die de agent aan het einde van de sessie uitvoert. Bevat het schema en de integriteitsregels, zodat de uitvoering consistent is: dezelfde procedure is van toepassing op zowel een refactor als een beoordeling van een advertentieaccount. Zwak punt: de aanroep is probabilistisch; het kan gebeuren dat de procedure onopgemerkt nooit wordt geactiveerd.
• Een hook: het harnas zelf activeert of herinnert aan een gebeurtenis (een injectie bij het begin van een sessie, een trigger bij het einde van een sessie). Dit is deterministisch (de enige optie waarbij niemand iets hoeft te onthouden), maar ook nogal grof (het wordt ook geactiveerd bij een sessie van twee minuten) en platformgebonden.
• Een conventielijn: één vaste instructie in het contextbestand van de scope, of de bijbehorende niet-code-variant, een stap in de SOP van het team: „Sluit elke substantiële, door AI ondersteunde sessie af door wrijving vast te leggen.” Geen infrastructuur, maar het steunt volledig op het feit dat het model één regel uit vele naleeft, en het verliest aan kracht naarmate het bestand groeit; de genoemde faalmodus is het geheugenbestand dat “niet meer wordt gelezen” (veldnotitie over anti-patronen).
• Een opdracht: een door een mens ingevoerde/retro opdracht aan het einde van een feature-branch of een triage-dienst. Doordacht en nauwkeurig getimed; de zwakke schakel is het menselijk geheugen.

Deze elementen vormen samen het geheel; rangschik ze in lagen. Een deterministische trigger (een ‘hook’ of een SOP-stap aan het einde van een dienst), een procedurele payload (de vaardigheid) en een conventieregel die de werkwijze als norm benoemt — kies ten minste één trigger; twee is beter. Zelfs leveranciers hebben dit inzicht gekregen: in de Codex-richtlijnen van OpenAI staat „wanneer Codex tweemaal dezelfde fout maakt, vraag het dan om een retrospective en werk AGENTS.md bij” (best practices).

De opbouw van een goede inleiding

Een opname vormt de schakel tussen de sessie waarin de wrijving werd opgemerkt en alles wat daarop volgt — de kwaliteit van de synthese wordt bepaald door de kwaliteit van de opname. Vier essentiële onderdelen:

1. Een met bewijs onderbouwd moment, met de bijbehorende kosten. Wat er is gebeurd, wanneer, en het waarneembare gevolg, voldoende specifiek zodat iemand die niet bij de sessie aanwezig was, hierop zou kunnen reageren. Kosten betekenen opnieuw uitgevoerd werk, verspilde tijd, verkeerde output; een verslag zonder kosten kan later niet worden gerangschikt. Door de uitvoerder geschatte kosten zijn indicatief: noteer ze(est.) in plaats van precisie te veinzen.

2. Precies één label voor de hoofdoorzaak uit een vaste woordenschat van tien labels. Vaste woordenlijsten kunnen betrouwbaar worden gelabeld (MAST bereikte κ = 0,88 voor 14 storingsmodi; zie arXiv 2503.13657); vrij gedefinieerde categorieën verschillen per persoon en kunnen niet meer worden samengevoegd. De tien:

• ambiguous-instruction: in de vraag werd een belangrijke parameter buiten beschouwing gelaten (doelgroep, reikwijdte, definitie, tijdsbestek) en moest er dus een gok worden gedaan
• missing-context: een bekend feit waarvan het team op de hoogte is, maar dat het niet heeft gedeeld
• incorrect-context: de verstrekte informatie was onjuist
• missing-documentation: er ontbreekt documentatie die er wel zou moeten zijn (geen README, specificatie, runbook of SOP)
• incorrect-documentation: er bestaat een document, maar dit is verouderd of onjuist, en men heeft erop vertrouwd
• work-material-friction: het materiaal waarmee werd gewerkt, zorgde ervoor dat het werk traag verliep of dat er fouten werden gemaakt: technische schuld of een onoverzichtelijke structuur in de code; een verwarde boekhouding, een verwarde tabel, een verwarde spreadsheet of een verwarde sjabloon daarbuiten (noem altijd het concrete materiaal)
• missing-access-or-tool: een benodigde connector, toestemming of tool was niet beschikbaar
• agent-error: een fout van de agent zelf (verkeerde aanname, verouderde kennis, een door hem veroorzaakte fout)
• changed-requirements: de opdracht werd halverwege de sessie gewijzigd en het werk moest opnieuw worden gedaan
• environment-friction: storingen in de tooling, time-outs, problemen met de sandbox of het platform

ambiguous-instructionEén label per bevinding zorgt ervoor dat de verdelingen betrouwbaar blijven: kies de beste match, noteer de tegenstrijdigheden in het bewijsmateriaal en verzin nooit halverwege een vermelding een label. Drie grensregels verrichten het grootste deel van het werk om dubbelzinnigheden weg te nemen. De agent-kenbare-test: was het feit ergens te achterhalen waar de agent redelijkerwijs zou kunnen zoeken? Nergens aangetroffen waar het had moeten zijn → missing-documentation; pas later verstrekt, door een persoon → missing-context. Agentfout is het residu: gebruik dit alleen wanneer de input toereikend was en de agent toch een fout maakte; als de fout terug te voeren is op slechte input, label dan de input. En dubbelzinnigheid versus verschuiving: als uit de verduidelijking bleek wat altijd al bedoeld was, was het ; als het doel daadwerkelijk is verschoven, is het changed-requirements.

3. Een oplossing ter grootte van een kaartje, waarbij het niveau wordt vermeld. Het niveau is het gebied waarop de oplossing is gericht: geheugen, vaardigheden, omgeving, documentatie, het materiaal zelf, het proces of de upstream. Een melding van een probleem zonder bijbehorende oplossing is een klacht.

Hier volgt een volledig verslag van een niet-technische vergadering, namelijk de maandelijkse evaluatie van de advertentieaccounts:

- **[missing-context]** The brief didn't say the French campaigns were deliberately
  paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
  → Fix (altitude: process): add campaign-status flags to the monthly brief template

Een moment, een kostenpost met een(est.) markering, één label, een oplossing die iemand volgende week zou kunnen oppakken. Vergelijk dit met de onbruikbare versie van dezelfde opmerking: „de opdracht was verwarrend“ – geen moment, geen kosten, geen volgende stap. Vagheid is op zichzelf al een vorm van falen.

4. Het recht om niets te zeggen. „Niets noemenswaardigs” is een geldig en nuttig antwoord; een logboek dat vol staat met verzonnen bevindingen doet de echte bevindingen ten onder gaan.

Nog een ontwerppunt: het opnemen moet zonder beperkingen plaatsvinden — een agent die toestemming nodig heeft om opnames te maken, leidt tot onderrapportage. Laat het systeem vrijelijk opnames maken, en laat menselijke feedback achteraf als correctie dienen: een aanvullend signaal van de persoon die ook aan de sessie deelnam, niet een controlepunt waarop de lus moet wachten.

De regels inzake het niet-registreren

Gegevens blijven langer bestaan dan de sessies waarin ze zijn vastgelegd: ze worden opgeslagen, gedeeld en samengevoegd. Sommige gegevens worden nooit opgenomen:

• Geheimen, inloggegevens, tokens of API-sleutels, in welke vorm dan ook, zelfs gedeeltelijk.
• Klantgegevens of persoonsgegevens.
• Nog niet gepubliceerde bedrijfscijfers of vertrouwelijke gegevens — beschrijf het effect, niet de gegevens zelf.
• Bovenal: mensen. Nooit een naam, een functie of iets anders waarmee kan worden vastgesteld wie de kloof heeft veroorzaakt. Beschrijf de tekortkoming en wat deze heeft gekost: „de briefing liet het publiek in het ongewisse“, niet „de briefing van X“. Bijdragen leveren kritiek op input en systemen, niet op mensen — dezelfde discipline waarop een goede retrospective is gebaseerd, en wat ervoor zorgt dat het verslag veilig gezamenlijk kan worden gelezen.

Kritiek op de input wordt verwacht: onduidelijke opdrachten, ontbrekende context en te laat ingediende vereisten vormen doorgaans de bron van bruikbare informatie. De agent dient zichzelf met dezelfde eerlijkheid te beoordelen. Indien de knelpunten binnen een bepaald werkgebied niet kunnen worden beschreven zonder gevoelige context, dient u de gegevens van dat werkgebied privé te houden en uitsluitend de samengevatte opdracht te delen.

Waar het logboek zich bevindt

Eén logboek per beoordelingsgebied — het gebied waar correcties worden doorgevoerd. Voor het meeste ontwikkelingswerk is dat de repository: de documentatie, configuratie en conventies daarvan zijn in de repository ondergebracht, dus geldt dat ook voor het bijbehorende logboek. Buiten de code is het bereik het advertentieaccount, de support-inbox of de klantbetrokkenheid; bewaar het logboek in de documentmap van die werkruimte. Een vermelding die buiten het bereik wordt opgeslagen, zal de uiteindelijke verantwoordelijke voor de oplossing nooit vinden; een vermelding die in een tijdelijke map wordt opgeslagen, verdwijnt aan het einde van de sessie.

Wat overal identiek moet blijven, is niet de opslag maar de structuur: het schema, niet de opslag, zorgt ervoor dat gegevens later kunnen worden samengevoegd. Dat is de kern van dit hoofdstuk vanuit het perspectief van het team: vergelijkbare gegevensrecords – ongeacht de persoon, de medewerker, de sessie of de tool – maken aggregatie op teamniveau überhaupt mogelijk. Pas de opslag naar eigen inzicht aan; houd vast aan het schema.

Wat volgt er nu?

Een stapel goede aantekeningen is grondstof, geen inzicht. In de volgende hoofdstukken wordt hierop voortgebouwd: het kiezen van de hoogte van elke fix (het verschil tussen een geheugennotitie en de herstructurering waar de wrijving steeds op wijst); het samenvatten van de aantekeningen tot een overzicht van één pagina dat het team gezamenlijk kan doornemen; en de ceremonie waarin mensen en het logboek samenkomen — de retrospective, waarbij de aantekeningen van de agent als input voor de deelnemers dienen. Deze cyclus is een voorbeeld van het Feedback Flywheel: leerervaringen terugkoppelen naar de artefacten die context bieden (martinfowler.com). En de discipline achter de aantekeningen is foutanalyse, “de belangrijkste activiteit bij evaluaties” (Husain & Shankar, FAQ over evaluaties), verplaatst naar het meest kostenefficiënte moment: terwijl de sessie waarin de wrijving zich voordeed nog gaande is.

Al het bovenstaande werkt met een tekstbestand en elke geschikte agent. Als u de sjabloon liever niet zelf wilt maken, biedt de gratis ai-session-retroskill deze invoervorm van begin tot eind; in het quick-start-bericht wordt uitgelegd hoe u deze in ongeveer tien minuten kunt installeren.

Volgend hoofdstuk: Waar moet de fix terechtkomen? — het hoogteprobleem en de routeringstabel.