Er zijn AI-agenten aan uw team toegevoegd. Uw verbeteringscyclus heeft dit nog niet opgemerkt.

Deze gids gaat over het toepassen van iets wat teams al kennen, namelijk de cyclus van voortdurende verbetering, op iets nieuws: het werk dat uw team nu verricht met AI-agenten. Wij ontwikkelen software voor retrospectieven, dus deze benadering kennen wij het beste; de cyclus die hierin wordt beschreven, werkt met alle tools en werkwijzen die u al gebruikt.

Wilt u eerst de verkorte versie van 10 minuten? Begin dan met het artikel ‘Snel aan de slag’, feedback verzamelen van AI-agenten, en kom daarna hier terug voor het volledige overzicht.

De oudste truc bij het werken in teamverband

Elke methode die uw team hanteert om beter te worden, is een variant op één cyclus: voer het werk uit, bekijk hoe het is verlopen, breng een wijziging aan, controleer of de wijziging heeft geholpen. Deming introduceerde dit in de productiesector als Plan–Do–Check–Act; Toyota maakte er een cultuur van en noemde het kaizen; in de softwarewereld werd het een ritueel. Norm Kerths Project Retrospectives (2001) maakte de retrospective populair onder softwareteams, en het agile Manifesto legde het vast als een principe: „Met regelmatige tussenpozen reflecteert het team op hoe het effectiever kan worden, waarna het zijn gedrag dienovereenkomstig bijstemt en aanpast“ (principe 12). Bij ‘blameless postmortems’ wordt dezelfde cyclus doorlopen voor incidenten; de campagne-evaluatie van een mediateam en de triage-evaluatie van een ondersteuningsteam volgen deze cyclus zonder ooit het woord ‘agile’ te gebruiken.

De cyclus werkt op basis van één uitgangspunt: werk levert inzichten op over hoe het werk moet veranderen. Teams die deze inzichten benutten, versterken het effect: elke cyclus maakt de volgende beter. Teams die dat niet doen, blijven in een vicieuze cirkel hangen.

Zeventig jaar lang kwam de informatie van mensen. Mensen merkten de wrijving op, klaagden erover tijdens de lunch en brachten het ter sprake in de retro. De sensoren van de lus waren mensen.

Een nieuw soort werknemer

Ergens in de afgelopen twee jaar is uw team begonnen met het delegeren van daadwerkelijk werk aan een nieuw soort medewerker. AI-agenten schrijven en controleren nu code, voeren controles uit op advertentieaccounts, stellen antwoorden op voor de klantenservice op, stellen rapporten op en migreren inhoud. En deze medewerker heeft een merkwaardig profiel: onvermoeibaar, snel, bekwaam en verstoken van context. De omschrijving van Rahul Garg is de gangbare formulering in het vakgebied geworden: „AI-assistenten zijn als juniorontwikkelaars met oneindig veel energie maar zonder enige context”, en dat is de reden waarom „de tijd die wordt bespaard door door AI gegenereerde code vaak weer wordt opgeslokt door de inspanning die nodig is om deze te corrigeren” (Patterns for Reducing Friction in AI-Assisted Development).

Die correctiekosten zijn wrijving, en het werk van medewerkers veroorzaakt deze voortdurend: de dubbelzinnige opdracht die tot giswerk dwong, het document dat niet bestond, de accountstructuur die bij elke sessie voor problemen zorgt, de tool die een time-out gaf, de vereiste die halverwege de taak veranderde. Dit is niets nieuws. Menselijk werk leidt tot dezelfde lijst. Twee aspecten hieraan zijn echter nieuw.

De nieuwe medewerker klaagt niet tijdens de lunch. Een medewerker stuit op een hindernis, zoekt een oplossing en gaat verder. Hij raakt niet zo gefrustreerd dat hij het probleem tijdens de terugblik op vrijdag ter sprake brengt. Het signaal waarop uw verbeteringscyclus altijd heeft vertrouwd (iemand die de wrijving in de gaten houdt totdat deze tijdens een bijeenkomst aan de orde wordt gesteld) wordt niet afgegeven.

En het bewijsmateriaal verdwijnt als sneeuw voor de zon. Wanneer de sessie afloopt, verdwijnt de context van de wrijving daarmee. De volgende sessie (volgende persoon, dezelfde medewerker) stuit opnieuw op dezelfde hindernis. U kunt geen verbeteringen aanbrengen op basis van bewijsmateriaal dat u nooit hebt vastgelegd; de cyclus sterft stilletjes uit, terwijl het werk op het eerste gezicht prima lijkt.

De situatie is dus als volgt, in alle eenvoud: een steeds groter deel van het werk van uw team levert nu bewijsmateriaal op voor verbeteringen dat uw verbeteringscyclus nooit was ontworpen om te verzamelen.

Het veld merkte dit op en heeft de lus zelfstandig hersteld

Degenen die het dichtst bij het werk van agenten stonden, zagen dit al vroeg, en tegen medio 2026 is „het in kaart brengen van wrijving bij agenten en het terugkoppelen daarvan” een gangbare praktijk geworden onder ten minste een half dozijn benamingen: Garg’s Feedback Flywheel, Every’s Compound Engineering, Osmani’s Loop Engineering, Thoughtworks’ sensor-instrumented harness engineering, de op vlootschaal werkende geheugenlussen van de platformleveranciers (OpenAI’s „dreaming“, Factory Signals), en GitHub’s gh-aw, waarvan de workflows voor sessie-inzichten reeds geautomatiseerde rapporten voor sessieanalyse genereren. Zelfs de leveranciers grijpen terug op het woord „retro”: in de Codex-richtlijnen van OpenAI staat „wanneer Codex tweemaal dezelfde fout maakt, vraag het dan om een retrospectieve en werk AGENTS.md bij” (best practices).

Deze loops zijn goed. Als uw team een van deze gebruikt, behoud deze dan; alles in deze handleiding bouwt hierop voort in plaats van ze te vervangen. Let echter op twee hiaten.

Ten eerste de praktijkkloof: toekijken leidt niet tot verbetering. Ongeveer 90 % van de teams registreert de activiteit van hun agents; slechts ongeveer 37–52 % evalueert systematisch wat er wordt vastgelegd (LangChain, juni 2026). De meeste teams beschikken over het dashboard. Veel minder teams hebben de feedbackloop.

Ten tweede, de vormkloof: bijna elke cyclus in het veld verloopt afzonderlijk. Eén beoefenaar die zijn persoonlijke draaiboek afstemt, één platform dat het geheugen van zijn vloot beheert, één observabiliteitsstack die zijn eigen traces groepeert. Zeventig jaar van voortdurende verbetering leert ons dat de synergie plaatsvindt op teamniveau: daar waar het totaalbeeld tot stand komt, waar prioriteiten opnieuw worden afgewogen, waar processen, documentatie en budgetten een verantwoordelijke hebben. Juist die laag is het onderdeel dat nog door niemand opnieuw is opgebouwd. De rapporten zijn er; de vergaderruimte is nog niet gereserveerd.

De opbouw van de lus

Wanneer uw team besluit dit aan te sluiten, blijkt de lus uit meer bewegende onderdelen te bestaan dan op het eerste gezicht lijkt. De weg die een enkel wrijvingspunt moet afleggen:

Podium	De vraag
Hosting	Waar wordt de agent uitgevoerd, en wat is daardoor waarneembaar?
Detectie	Hoe wordt wrijving opgemerkt? (Zelfwaarneming, een controle-instantie, telemetrie en menselijke correctie, die nog steeds de belangrijkste sensor is: ~70% van de stille storingen wordt eerst door een persoon opgemerkt)
Instrumentatie	Wat zorgt ervoor dat de medewerker dit vastlegt? (Niemand registreert problemen waarnaar hem of haar niet is gevraagd te zoeken)
Opname	Wat bevat een bruikbaar record en waar wordt het bewaard?
Oogsten	Hoe worden de gegevens uit talrijke sessies en van talrijke personen samengevoegd?
Samenvatting	Welke patronen zijn van belang, en op welk niveau hoort elke oplossing thuis?
De kringloop sluiten	Heeft de aanpassing de wrijving daadwerkelijk verminderd, of was het slechts schijn?

Drie aspecten maken het verschil tussen een ‘loop’ en een dagboek, en elk daarvan krijgt een eigen hoofdstuk in deze gids:

• Verslagen, geen indrukken. Een nuttige vermelding beschrijft het moment, noemt één hoofdoorzaak uit een beperkte, vaste woordenschat en stelt een oplossing ter grootte van een ticket voor. Dankzij vaste labels kunnen vermeldingen worden samengevoegd: „de documentatie was verwarrend” kan niet worden geteld; acht vermeldingenmissing-documentation wel. (Hoofdstuk: Hoe een goede ‘friction record’ eruitziet)
• De kwestie van het niveau. Elk terugkerend patroon wordt op een bepaald niveau verholpen: in een notitie, een prompt, de configuratie, de documentatie, het werkmateriaal zelf, het proces of stroomopwaarts bij een leverancier. Als u de oplossing op een te laag niveau doorvoert, blijft het probleem zich bij alle anderen voordoen; op een te hoog niveau zorgt u ervoor dat een document dat niemand leest, onnodig omvangrijk wordt. (Hoofdstuk: Waar moet de oplossing worden doorgevoerd?)
• Beoordeling binnen een ruimte. Sommige wrijving is opzettelijk: de beoordelingsfase die iemand als controlepunt heeft gekozen (een samenvatting van Ronachers lezing op AIE Europe: „wrijving is wat nodig is… om te sturen”; Thoughtworks waarschuwt nu voor de cognitieve schuld die ontstaat bij te soepel verlopend werk van agents). Beslissingen over behouden of schrappen, prioriteiten en oplossingen waarbij meerdere eigenaren betrokken zijn, zijn onderhandelingen, geen berekeningen. Hiervoor moeten de verantwoordelijken voor de oplossing in één gesprek bijeen zijn. (Hoofdstuk: Het rapport bestaat. De ruimte niet.)

Hoe het verhaal verdergaat

De cadanslijst van Garg voor het vliegwiel bevat een regel die bijna een uitdaging is: „een agendapunt in de bestaande sprint-retrospective: wat werkte er deze sprint met AI?” (martinfowler.com). Dat is de rode draad die deze gids volgt. Geen nieuwe ceremonie, geen door AI geleide ceremonie: de verbeteringscyclus waarop uw team al vertrouwt, uitgebreid om ook de nieuwste medewerker erin te betrekken, met de agent als deelnemer: deze levert het bewijsmateriaal aan, stelt de oplossingen op en beantwoordt vragen; het team behoudt het oordeel, omdat de oplossingen terechtkomen in processen, documenten en begrotingen waarvoor mensen verantwoordelijk zijn en verantwoording moeten afleggen.

En laten we eerlijk zijn: als uw team alleen maar het agendapunt toevoegt en erover praat (zonder verslag, zonder labels), is dat al beter dan stilzwijgen, en voor licht gebruik door medewerkers kan dat voldoende zijn. De rest van deze handleiding gaat over wat u kunt toevoegen wanneer dat gesprek zich steeds weer herhaalt.

De hoofdstukken

1. Deze pagina: waarom AI-ondersteund werk de werkwijze nodig heeft die uw team al hanteert.
2. De kaart: feedbacklussen, hulpmiddelen en benaderingen voor agenten: het referentiekader dat de levenscyclus van wrijving omvat, de benoemde lussen die binnen het vakgebied zijn ontwikkeld, en de classificatiesystemen die in gebruik zijn. Begin hier als u top-down denkt.
3. Hoe een goed ‘friction’-rapport eruitziet: vastleggen op het moment zelf, de labels voor de onderliggende oorzaken, de regels voor ‘nooit loggen’.
4. Waar moet de oplossing worden toegepast? Het hoogteprobleem en de routeringstabel.
5. Het rapport bestaat. De ruimte niet. Waarom synthese een teamactiviteit is, die qua prijs gunstig afsteekt tegen die van haar concurrenten.
6. Het AI-samenwerkingsspel ‘Retro’ spelen: de handleiding voor de begeleider, inclusief het agendapunt van 15 minuten, het sjabloon en de promptkaarten.
7. Aan de slag in tien minuten: ai-session-retro en ai-retro-brief, de opname- en synthesekant van de lus, klaar om te worden geïnstalleerd.

Liever de korte versie? Twee gerelateerde blogberichten: de snelstartgids, feedback verzamelen van AI-agenten, en het verslag van de eerste keer dat wij dit zelf hebben uitgevoerd, onze AI-teamgenoten namen deel aan onze retro.

Veelgestelde vragen

Hebben AI-agenten een eigen, afzonderlijke retrospective nodig?

Nee. De aanpak in deze handleiding vormt een uitbreiding van de verbeteringscyclus die uw team al hanteert, vaak als een afzonderlijk agendapunt tijdens de bestaande retrospective, in plaats van dat er een nieuwe ceremonie wordt toegevoegd. De medewerker neemt deel door bewijsmateriaal aan te dragen en oplossingen uit te werken; het team behoudt de beslissingsbevoegdheid.

Waarom komt wrijving met AI-agenten niet aan bod tijdens reguliere retrospectieven?

Twee redenen. Spelers klagen niet: zij lopen tegen een obstakel aan, zoeken een oplossing en gaan verder, zodat niemand het probleem meeneemt naar de volgende sessie. En het bewijsmateriaal verdwijnt: wanneer de sessie eindigt, verdwijnt de context van de wrijving mee, zodat de volgende sessie opnieuw tegen hetzelfde obstakel aanloopt.

Wij registreren onze agenttraces al. Is dat niet voldoende?

Toezicht alleen leidt niet tot verbetering. Ongeveer 90 % van de teams voert metingen uit op de traces van hun agents, maar slechts ongeveer 37–52 % evalueert systematisch wat er wordt vastgelegd. De traces vormen het ruwe materiaal; de cyclus vereist discipline bij het vastleggen, synthese en een platform op teamniveau waar degenen die verantwoordelijk zijn voor het oplossen van problemen gezamenlijk beslissingen nemen.

Moet de AI de retrospective zelf uitvoeren?

Nee. De agent is een deelnemer: hij of zij levert het bewijsmateriaal aan, stelt de oplossingen op en beantwoordt vragen. Het team behoudt de beslissingsbevoegdheid, omdat de oplossingen worden geïmplementeerd in processen, documenten en begrotingen waarvoor mensen verantwoordelijk zijn en verantwoording moeten afleggen.

Wat is de minimaal bruikbare versie van deze werkwijze?

Voeg één agendapunt toe aan uw bestaande retrospectieve (wat werkte er goed met AI deze cyclus?) en bespreek dit. Geen logboek, geen labels. Dat is al beter dan stilzwijgen, en bij licht gebruik van de agent kan dit voldoende zijn. De rest van de gids beschrijft wat u kunt toevoegen wanneer dat gesprek zich blijft herhalen.

Wij hebben liever dat men ons tegenspreekt dan dat men het beleefd met ons eens is. Elk hoofdstuk eindigt met wat ons van gedachten zou doen veranderen.