Retrospective over AI-agenten: een praktische gids

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 versie van 10 minuten lezen? 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 teamwork

Elke methode die uw team gebruikt om zich te verbeteren, is een variant op één cyclus: voer het werk uit, bekijk hoe het is gegaan, breng een verandering aan, controleer of de verandering 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 er een ritueel van gemaakt. Norm Kerths Project Retrospectives (2001) maakte de retrospective populair onder softwareteams, en het agile Manifesto legde dit vast als een principe: „Met regelmatige tussenpozen reflecteert het team op hoe het effectiever kan worden, waarna het zijn gedrag dienovereenkomstig bijstelt 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 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 term in het vakgebied geworden: „AI-assistenten zijn als juniorontwikkelaars met oneindig veel energie, maar zonder enig begrip van de context”, en daarom „wordt de tijd die wordt bespaard door door AI gegenereerde code vaak weer 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 genereert 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. Hieraan 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 obstakel, 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 ten einde loopt, verdwijnt de context van de wrijving mee. 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 te verlopen.

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

De spelers merkten het op — en herstelden de lus in hun eentje

Degenen die het meest betrokken waren bij het werk met agenten zagen dit al vroeg in, en tegen medio 2026 was „het in kaart brengen van wrijving bij agenten en het terugkoppelen daarvan” een algemeen aanvaarde praktijk geworden, bekend 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 naar het woord „retro”: 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).

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

Ten eerste de praktijkkloof: toekijken leidt niet tot verbetering. Ongeveer 90% van de teams registreert de traces 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 lus in het veld is een soloproject. Eén beoefenaar die zijn persoonlijke draaiboek afstemt, één platform dat het geheugen van zijn vloot beheert, één observability-stack die zijn eigen traces clustert. Zeventig jaar van voortdurende verbetering leert ons dat de synergie plaatsvindt op teamniveau — waar het totaalbeeld tot stand komt, waar prioriteiten opnieuw worden afgewogen, waar processen, documentatie en budgetten eigenaren hebben. Juist die laag is het onderdeel dat nog door niemand opnieuw is opgebouwd. De rapporten zijn er; de vergaderruimte is nog niet gereserveerd.

Afzonderlijk is elke opmerking over wrijving te onbeduidend om het de moeite waard te maken deze op te lossen. Samengevoegd op het bord van het team vormen deze opmerkingen echter een van de grootste kostenposten: de herweging die alleen het team kan inzien.

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 één enkel wrijvingspunt moet afleggen:

Podium	De vraag
Hosting	Waar wordt de agent uitgevoerd — en wat is daardoor waarneembaar?
Detectie	Hoe wordt wrijving opgemerkt? (Zelfdetectie, 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 opgeslagen?
Oogsten	Hoe worden de gegevens van vele sessies en vele mensen 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 bruikbare melding beschrijft het moment, noemt één hoofdoorzaak uit een beperkte, vaste woordenlijst en stelt een oplossing ter grootte van een ticket voor. Dankzij vaste labels kunnen meldingen worden samengevoegd: „de documentatie was verwarrend” kan niet worden geteld; achtmissing-documentationmeldingen wel. (Hoofdstuk: Hoe een goed ‘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 voor alle anderen terugkeren; 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. Een zekere mate van wrijving is bewust aangebracht: de beoordelingsfase die iemand als controlepunt heeft gekozen (een samenvatting van Ronachers toespraak op AIE Europe: „wrijving is noodzakelijk… om te sturen”; Thoughtworks waarschuwt nu voor de cognitieve schuld die ontstaat door 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 bij elkaar 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 stilte, en voor licht gebruik van het systeem kan dat voldoende zijn. De rest van deze handleiding gaat over wat u kunt toevoegen wanneer dat gesprek zich steeds weer herhaalt.

De hoofdstukken

Deze pagina: waarom AI-ondersteund werk de werkwijze nodig heeft die uw team al hanteert.
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 classificatieschema’s die in gebruik zijn. Begin hier als u top-down denkt.
Hoe een goed frictierapport eruitziet: vastleggen op het moment zelf, de labels voor de onderliggende oorzaken, de regels voor wat nooit mag worden geregistreerd.
Waar moet de correctie worden aangebracht? Het hoogteprobleem en de routeringstabel.
Het rapport bestaat. De ruimte niet. Waarom synthese een teamceremonie is, die zich onderscheidt van de concurrentie.
De AI-samenwerkingsretro uitvoeren: de handleiding voor de begeleider, met het agendapunt van 15 minuten, het sjabloon en de promptkaarten.
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 we dit zelf hebben uitgevoerd, onze AI-teamgenoten namen deel aan onze retro.

Wij hebben liever dat men met ons in discussie gaat dan dat men het beleefd met ons eens is — elk hoofdstuk eindigt met wat ons van gedachten zou doen veranderen.