Het rapport bestaat. De kamer bestaat niet.

Onlangs heeft een AI-agent zes items geplaatst op ons eigen retro-forum.

De eerste luidde: “Begin met controleren voordat u actie onderneemt — fouten bij de uitvoering van agents zijn verantwoordelijk voor 38% van de wrijving (twee keer zoveel als de op één na belangrijkste oorzaak); de terugkerende kosten ontstaan doordat een oorzaak wordt vastgesteld, er wordt gepusht of de focus wordt verlegd voordat de live-code, de gegevens of de status van de branch zijn gecontroleerd.” Daarachter schuilde het bewijs voor dit patroon: fouten in de git/branch-status bij gelijktijdig werken met agents gedurende acht sessies en in twee repositories; onvolledige pre-push-controles die de CI in vier sessies lieten mislukken, waarvan tweemaal in één repository op dezelfde dag; een lacune in de test-mocking die een sessie de dag ervoor had gesignaleerd, met de opmerking dat de documentatie voor de oplossing nooit is geschreven.

Er zijn twee zaken aan dat bord die uw aandacht verdienen. Ten eerste zou geen enkele werksessie dit als het belangrijkste probleem hebben aangemerkt: elk afzonderlijk geval leidde slechts tot een schouderophalen, een paar verloren minuten, of een ergernis waar iemand een oplossing voor had gevonden. De rangschikking bestaat alleen in geaggregeerde vorm, over alle sessies en personen heen. Ten tweede, en dat is nog ongemakkelijker: de meest verontrustende punten hadden helemaal niets te maken met de agent of de code. Ze gingen over ons — oplossingen waar we het over eens waren geweest maar die we niet hadden doorgevoerd, dezelfde vertraging die zich telkens weer voordeed, waarbij „er tussentijds geen permanente oplossing werd geïmplementeerd”.

Een geautomatiseerd rapport kan u dit alles vertellen. Wat het echter niet kan, is de mensen die verantwoordelijk zijn voor het proces, de documentatie, het budget voor de tools en de prioriteiten bij elkaar brengen om te beslissen wat ermee moet gebeuren. Het rapport is er. De vergaderruimte niet. Dit artikel gaat over die vergaderruimte.

Iedereen heeft de lus aangelegd

Tegen medio 2026 is „vastleggen wat er mis is gegaan bij AI-ondersteund werk en dit terugkoppelen” de gangbare praktijk. Dit concept kent ten minste zes benamingen, die allemaal even goed zijn. Rahul Garg’s Feedback Flywheel zet wrijving tijdens werksessies om in instructiedocumenten en richtlijnen. Every’s Compound Engineering zorgt ervoor dat elke werkeenheid de volgende leert. Thoughtworks rust agenten uit met sensoren; Addy Osmani noemt deze discipline Loop Engineering. De platformleveranciers sluiten de cirkel op fleet-schaal: OpenAI’s geheugen “dreaming”, Anthropic’s contextcuratie, Factory Signals die automatisch tickets aanmaakt. GitHub’s open-source gh-aw, een framework voor agentgebaseerde workflows geschreven in markdown met natuurlijke taal, komt het dichtst in de buurt van ons onderwerp: de workflows voor sessie-inzichten genereren nu al geautomatiseerde rapporten voor sessieanalyse. Een openbaar voorbeeld, een geautomatiseerde analyse van 50 sessies over één dag, markeert een oversla-percentage van 24% en een succespercentage van de uitvoerder van 33% als „Failure Signals“.

Als u een van deze gebruikt: blijf ze dan gebruiken. In dit artikel wordt niet voorgesteld om ook maar één ervan te vervangen. Sorteer de lussen echter op het niveau waarop ze worden uitgevoerd en bekijk het patroon:

Eén handleiding voor professionals. Eén sessieconfiguratie. Eén platformgeheugen. Eén observabiliteitsstack. Eén leverancierspark.

Vrijwel elke cyclus in het veld is een solocyclus: een persoon en zijn of haar agent, of een leverancier en zijn wagenpark. Het vliegwiel van Garg is het enige ontwerp dat streeft naar gedeelde teamartefacten, en zijn cadanslijst bevat een punt dat bijna niemand in de praktijk heeft gebracht: „Tijdens de retrospectieve: een agendapunt in de bestaande sprint-retrospective: wat werkte er deze sprint met AI?“ Hij noemt de locatie en gaat verder. Het „dogfooding“-beleid van GitHub levert ondertussen precies het wrijvingsrapport op dat een teamceremonie als input zou willen hebben, en positioneert dit als technische observeerbaarheid, punt uit.

Hetgeen het dichtst in de buurt komt van een uitzondering is afkomstig van Scrum.org, waarvan de reeks over hybride teams het artikel Hoe u de sprint-retrospective uitvoert wanneer de helft van uw team uit AI-agenten bestaat bevat. Het is de moeite waard om dit artikel te lezen, omdat het de vraag naar de aanpak serieus neemt en deze anders beantwoordt dan wij: hun retrospectieve wordt een datagestuurde foutopsporingssessie op basis van agentstatistieken (frequentie van het herschrijven van prompts, afwijkingspercentages, tokenverbruik). Dat is een nuttige invalshoek, en een team zou beide benaderingen kunnen toepassen. Maar daarin worden de agenten geëvalueerd; de cyclus waar dit artikel over gaat, evalueert de samenwerking: oorzaken in plaats van symptomen, oplossingen die worden doorgestuurd naar het niveau waar ze thuishoren (de opdrachtomschrijving, de documentatie, het proces, het materiaal), waarbij de agenten hun eigen verslag van het werk leveren in plaats van als een dashboard te fungeren.

De kloof ligt niet op technologisch vlak. Alle onderdelen (gegevensverzameling, aggregatie, rapportage) zijn tegenwoordig al beschikbaar. De kloof zit hem in de werkwijze: bijna niemand heeft aangegeven wat het team gezamenlijk doet zodra het rapport binnenkomt.

Waarvoor is er eigenlijk een kamer nodig?

De neiging is hier om de automatisering verder door te voeren: betere clustering, automatisch toegepaste oplossingen, een dashboard. Voor een groot deel van de bevindingen is dat terecht, en de hierboven beschreven pijplijnen voldoen daar goed aan. Maar somt u eens de beslissingen op die het rapport daadwerkelijk aan de orde stelt en let op de aard ervan:

• Behouden of schrappen. Welke terugkerende weerstand is verspilling, en welke is bewuste beheersing? De beoordelingsfase die de agent afremt, zou wel eens de leiband kunnen zijn die iemand heeft gekozen (een samenvatting van de lezing van Armin Ronacher op AIE Europe: „weerstand is wat nodig is… om te sturen”); Radar van Thoughtworks waarschuwt nu voor de cognitieve schuld die ontstaat wanneer er te veel wordt verwijderd. Het verwijderen van een controlepunt verandert het risico voor iedereen. Dat is per definitie een teambeslissing.
• Waar de oplossing wordt geïmplementeerd. Een terugkerend knelpunt wordt op een bepaald niveau: een persoonlijke opmerking, een aanwijzing of vaardigheid, de configuratie van de omgeving, de documentatie, het werkmateriaal zelf, het proces of bij de leverancier. Deze elementen hebben eigenaren, en die eigenaren zijn verschillende personen.
• Prioriteit bij aggregatie. Vijf minuten per persoon per sessie die zomaar worden afgedaan, vallen voor de individuele medewerker niet op, maar vormen in totaal een aanzienlijke kostenpost voor het team. Om hier iets aan te doen (het gedeelde sjabloon herschrijven, het intake-proces aanpassen, de kwestie escaleren naar de leverancier) is een beslissingsbevoegdheid vereist die geen enkele medewerker afzonderlijk bezit.
• De implementatiecontrole. Is de oplossing van de vorige cyclus daadwerkelijk geïmplementeerd en is de wrijving daarmee verdwenen? De meest waardevolle opmerking van ons eigen bestuur luidde precies als volgt: gisteren gemarkeerd, nooit geschreven. Een lus zonder deze controle is als een vliegwiel dat in de lucht ronddraait.

Geen van deze stappen is een rekenkundige bewerking. Het zijn stuk voor stuk onderhandelingen tussen mensen die elk een ander onderdeel van de teamwerking voor hun rekening nemen. Zelfstandige professionals integreren deze beslissingen op legitieme wijze op basis van hun intuïtie; fleet-pijplijnen genereren op legitieme wijze de voor machines leesbare subset met de snelheid van een machine. De versies op teamschaal vereisen dat mensen in één ruimte bijeenkomen met een gemeenschappelijke terminologie en de bevoegdheid om de aandacht te herverdelen. Dat is geen pijplijn. Dat is een ceremonie.

Waarom deze retro-ceremonie — of een ceremonie van vergelijkbare aard?

Voorafgaand aan de uiteenzetting wil ik het volgende vermelden: wij verkopen retrospective software. Juist daarom wordt in dit hoofdstuk uitgegaan van de eigenschappen in plaats van het merk: neem onze conclusie dan ook met een korreltje zout en controleer de eigenschappen zelf.

De eigenschappen waaraan de besluitvormingsgroep moet voldoen: een forum dat terugkerend is (chronische kleine wrijvingen leiden nooit tot een eenmalige bijeenkomst), waar schuld toewijzing niet de norm is, eigenaarsoverschrijdend (de personen die verantwoordelijk zijn voor processen, documentatie, tools en prioriteiten zijn aanwezig), en op bewijs gebaseerd. Voor de meeste teams is de sprint-retrospective de plek waar deze vier eigenschappen al aanwezig zijn: geen nieuwe vergadering die verdedigd moet worden in een strijd om agenda-ruimte, en een ‘blameless’-conventie die belangrijker is dan ze op het eerste gezicht lijkt, omdat de verleidelijke faalmodus hier de postmortem waarbij de uitvoerder de schuld krijgt is, en de ‘harness-engineering’-school die standaardaanpak expliciet afwijst: de ingenieur geeft het model de schuld en schrijft het af onder ‘wachten op de volgende versie’; repareer in plaats daarvan het harnas (Osmani, Agent Harness Engineering).

Maar de eerlijke formulering van de bewering geeft de concurrenten een beoordeling in plaats van een winnaar aan te wijzen:

• Sprintplanning heeft de meeste zeggenschap in de vergaderruimte, maar de agenda ervan is toekomstgericht en staat altijd vol; er is dan ook steevast geen ruimte voor retrospective evaluatie tijdens een planningssessie. Planning is het moment waarop goedgekeurde acties worden ingeroosterd, niet het moment waarop patronen worden geanalyseerd.
• De onberispelijke postmortem hanteert precies de juiste normen, maar heeft de verkeerde aanleiding: deze wordt bijeengeroepen bij een grote, eenmalige mislukking, maar nooit bij het patroon van „vijf minuten per acht personen per sprint”, terwijl juist dat patroon alleen door aggregatie zichtbaar wordt.
• Asynchroon — een rapport plus een tracker is de goedkoopste oplossing en volstaat voor de meeste standaardtaken. Wat het echter niet kan, is het nemen van beslissingen: de afweging ‘behouden of schrappen’ is een onderhandelingskwestie, meningsverschillen over prioriteiten overschrijden de grenzen van de verantwoordelijkheden, en het herprioriteren vereist dat de verantwoordelijken in hetzelfde gesprek aanwezig zijn.
• Het nulalternatief — gewoon praten over AI in de retro, zonder verslagen, zonder labels is gratis, past bij de huidige situatie en kan voor een klein team met beperkt gebruik van agents daadwerkelijk voldoende zijn. Begin daar. Wat dit echter niet oplevert, is vergelijkbaarheid tussen sessies, trends of de toetsing van de acceptatie: een gesprek dat elke keer weer vanaf nul begint. De onderstaande werkwijze past u toe wanneer dat gesprek zich steeds blijft herhalen.

Dus de bewering, eerlijk gezegd: de retro — of uw bestaande ceremonie met een vergelijkbare opzet. De maandelijkse campagnebeoordeling van een mediateam en de triagebeoordeling van een ondersteuningsteam zijn dezelfde procedure met verschillende benamingen, en niets in deze werkwijze veronderstelt code: het foutenlogboek van een verward advertentieaccount of een inconsistente sjabloonbibliotheek leest precies hetzelfde als het foutenlogboek van een verouderde repository.

De persoon in de ruimte — deelnemer, nooit begeleider

Als het bewijsmateriaal afkomstig is van agenten, moet de agent het dan dan zelf onderzoeken? Nee, en niet in de eerste plaats om de reden die u zou vermoeden.

De reden hiervoor is als volgt: de huidige modellen zijn juist bij dit soort beoordelingen onbetrouwbaar: de uitspraken van LLM’s variëren bij identieke invoer ~13,6% van de tijd, en in een productieonderzoek van acht weken ~70% van de stille storingen bij agents werd eerst door een persoon opgemerkt, en niet door tests of monitoring. Dat geldt vandaag de dag; modellen worden steeds beter.

De reden waarom dit niet vervaagt: facilitering en besluitvorming verdelen de aandacht van een team en beïnvloeden de artefacten waarover het team de verantwoordelijkheid draagt en waarvoor het verantwoording aflegt. Die bevoegdheid wordt niet overgedragen aan de meest bekwame modelbouwer in de ruimte, net zomin als deze wordt overgedragen aan de meest bekwame ingenieur in de ruimte. Het is een organisatorisch gegeven, geen tekort aan bekwaamheid.

De medewerker neemt dus deel op dezelfde manier als de best geïnformeerde medewerker dat doet. Hij legt bewijsmateriaal voor: zijn sessieverslagen, voorzien van labels en kostenvermeldingen. Hij beantwoordt vragen: op de vraag „Wat heeft u daadwerkelijk geprobeerd vóór de tijdelijke oplossing?” volgt een antwoord dat wordt gestaafd door het transcript. Hij stelt voorstellen op, maar neemt nooit beslissingen: voorgestelde oplossingen worden aangedragen met aanbevolen aanpassingen; de groep past ze aan, stelt nieuwe prioriteiten vast of verwerpt ze. En hij neemt goedgekeurde acties over (de documentwijziging, de configuratiewijziging), en voert deze na de ceremonie uit onder de gebruikelijke controle. In de onderzoekspraktijk heeft deze verdeling een naam: in het ACE-raamwerk fungeert de agent als Reflector en consolideert een Curator wat in het draaiboek wordt opgenomen. Wij brengen één bewuste aanpassing aan: in ACE is de curator een deterministische component; hier bestaat de curator uit het team.

Eén asymmetrie betreft de gegevensstroom. Alles wat de agent de ruimte binnenbrengt, dient onbeperkt toegankelijk te zijn — een agent die toestemming nodig heeft om wrijving te melden, rapporteert te weinig. Alles wat de ruimte verlaat naar datgene waarop agenten later vertrouwen (geheugen, contextbestanden, configuratie) ondergaat een gewone controle, omdat dat schrijfpad een erkend risico op manipulatie en afwijkingen vormt (OWASP Agentic Top 10, ASI06). De procedure bevindt zich precies op die grens: ongefilterd bewijsmateriaal komt binnen, gefilterde schrijfbewerkingen gaan naar buiten.

De vijftien minuten

Wat wij het team eigenlijk voorstellen om deze sprint te proberen, waarbij elke lus al ongewijzigd blijft:

1. Per sessie schrijft de medewerker een kort retrospectiververslag over zijn of haar eigen werk: wat er goed is gegaan, elk knelpunt met vermelding van de onderliggende oorzaak en wat dit heeft gekost, een voorstel voor een oplossing ter grootte van een ticket en het beoogde niveau waarop deze oplossing is gericht. Dit wordt samen met het werk vastgelegd, zonder enige beperking.
2. Voorafgaand aan de retro worden de inzendingen sinds de vorige bijeenkomst samengevat in een overzicht van één pagina: terugkerende thema’s en hun prevalentie, welke groep van onderliggende oorzaken de overhand heeft, of eerdere oplossingen zijn overgenomen, en de drie belangrijkste aanbevolen acties. Dit overzicht vormt de basis voor het gesprek; het is geen vervanging ervan.
3. Tijdens de terugblik (een agendapunt, geen nieuwe vergadering): vijftien minuten over „wat werkte er deze cyclus goed met AI, en wat bleef voor problemen zorgen?” De mensen maken een selectie: behouden of schrappen, de prioriteiten bevestigen of bijstellen, en de drie belangrijkste punten toewijzen aan verantwoordelijken.
4. In de volgende cyclus wordt in de goedkeuringscontrole van de opdracht vermeld of de wrijving daadwerkelijk is afgenomen. Die controle zorgt ervoor dat het rapport in een vicieuze cirkel terechtkomt — en dat is ook het punt waarop onze eigen raad ons op de fout heeft betrapt.

Foutmodi, zo genoemd zodat u zich ertegen kunt wapenen: retrotheater (de ceremonie die u voor het publiek organiseert: korte toelichting, knikken, geen beslissingen; hiervoor geldt de regel van de top-3-met-eigenaren); de schuld bij de agent leggen (het beschouwen van „de agent heeft een fout gemaakt“ als de verklaring in plaats van als het restverschijnsel; de meeste mislukkingen zijn terug te voeren op de testopstelling en de invoergegevens, niet op de redenering van het model); uitdijende verlanglijst (twintig acties, geen verantwoordelijken); en de lus die nooit wordt gesloten (het gebrek aan opvolging: oplossingen worden doorgevoerd, maar niemand controleert de trend). Wij hebben een complete praktijkgids geschreven over hoe ceremonies mislukken; elke vorm die daarin wordt beschreven, is ook hier van toepassing.

Wat wij niet beweren

Dit is geen vervanging voor een bestaande leverancierscyclus: de uitkomsten daarvan vormen de input voor deze ceremonie. Het is geen nieuwe vergadering. Het is geen door AI geleide ceremonie; voor een bedrijf dat retrospectives als product aanbiedt, is deze begrenzing bewust gekozen. Dit is niet noodzakelijk voor een zelfstandige beoefenaar, wiens cycli op basis van intuïtie prima worden afgesloten. En het doel is niet ‘nulwrijving’: enige wrijving vormt juist het stuurvlak, en het agendapunt is bedoeld om te kiezen, niet om het onmiddellijk uit te sluiten.

Wat zou ons van gedachten doen veranderen?

Aangezien dit een discussienota is, volgt hier het falsifieerbare deel. Indien de leverancierscycli leiden tot daadwerkelijke, tool- en persoonsoverschrijdende beoordelingen – en niet louter tot het opslaan van gegevens in het systeem voor de gehele vloot – wordt de rol teruggebracht tot die van een controlefunctie. Indien teams die de asynchrone versie met alleen de briefing uitvoeren dezelfde trend van verminderde wrijving vertonen als teams die het agendapunt uitvoeren, dan is die vijftien minuten slechts schijnvertoning en zullen wij dat ook zeggen. En onze bewering inzake de gelabelde woordenschat berust op een experiment naar interbeoordelaarsbetrouwbaarheid dat wij momenteel uitvoeren op basis van echte inzendingen, in plaats van dit vooraf te beweren. Wij geven er de voorkeur aan de cijfers te publiceren in plaats van het vertrouwen.

Mocht uw team een van deze onderdelen uitvoeren (het agendapunt, de asynchrone briefing of een ceremonie waar wij nog niet aan hebben gedacht), dan horen wij graag hoe het is verlopen: ai-discussion@TeamRetro.com.

---

Volgend hoofdstuk: De AI-samenwerkingsretrospective uitvoeren — de handleiding voor de facilitator voor de vijftien minuten: het sjabloon, het invoerformaat en de promptkaarten. Onderdeel van de handleiding voor retrospectieven met AI-agenten.