Het rapport bestaat. De kamer bestaat niet.
AI-agenten stellen nu zelf hun wrijvingsrapporten op. Wat nog ontbreekt, is de ruimte: een terugkerende teambijeenkomst waarin de samengevoegde rapporten worden omgezet in concrete oplossingen.
Onlangs heeft een AI-agent zes items geplaatst op ons eigen retro-forum.
De eerste luidde als volgt: “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 hebben verstoord, waarvan tweemaal in één repository op dezelfde dag; een lacune in de test-mocking die in een sessie de dag ervoor was gesignaleerd, met de opmerking dat de documentatie voor de oplossing nooit is geschreven.
Er zijn twee zaken aan dat bord die de aandacht verdienen. Ten eerste zou geen enkele werksessie dit als het belangrijkste probleem hebben aangemerkt: elk afzonderlijk geval was een schouderophalen, een paar verloren minuten, een ergernis waar iemand een oplossing voor had gevonden. De ranglijst bestaat alleen in geaggregeerde vorm, over alle sessies en personen heen. Ten tweede, en nog ongemakkelijker: de meest vernietigende punten hadden helemaal niets te maken met de agent of de code. Ze gingen over ons: oplossingen waarover we het eens waren geworden maar die we niet hadden doorgevoerd, dezelfde vertraging die zich telkens weer voordeed, waarbij „er tussentijds geen enkele 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 hulpmiddelen en de prioriteiten ertoe brengen om samen om de tafel te gaan zitten en te beslissen wat ermee moet gebeuren. Het rapport bestaat. De vergaderruimte niet. Dit artikel gaat over die vergaderruimte.
Iedereen heeft de lus aangelegd
Tegen medio 2026 is „vaststellen wat er mis is gegaan bij AI-ondersteund werk en dit terugkoppelen” een algemeen aanvaarde werkwijze. Deze methode kent ten minste zes benamingen, die allemaal even goed zijn. Rahul Garg’s Feedback Flywheel zet de wrijving die tijdens sessies ontstaat om in voorbereidende documentatie en richtlijnen. Every’s Compound Engineering zorgt ervoor dat elke werkeenheid de volgende iets bijbrengt. Thoughtworks rust medewerkers uit met sensoren; Addy Osmani noemt deze discipline Loop Engineering. De platformleveranciers sluiten de cirkel op fleetschaal: 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 op basis van 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 overslaagpercentage 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 ze te vervangen. Sorteer de lussen echter op het niveau waarop ze worden uitgevoerd en bekijk het patroon:
Eén handleiding voor professionals. Eén configuratie voor een sessie. Eén geheugen voor een platform. Eén observabiliteitsstack. Eén machinepark van één leverancier.
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’ 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 kunt houden wanneer de helft van uw team uit AI-agenten bestaat bevat. Het is de moeite waard om te lezen, omdat het de vraag naar de locatie serieus neemt en deze anders beantwoordt dan wij: hun retro wordt een datagestuurde debugging-sessie over de statistieken van de agents (frequentie van het herschrijven van prompts, afwijkingspercentages, tokenverbruik). Dat is een nuttige invalshoek, en een team zou beide 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 in de technologie. Alle onderdelen (gegevensverzameling, aggregatie, rapportage) zijn tegenwoordig al beschikbaar. De kloof zit hem in de praktijk: bijna niemand heeft aangegeven wat het team gezamenlijk doet wanneer het rapport binnenkomt.
Waarvoor is er eigenlijk een kamer nodig?
De neiging is hier om de automatisering verder door te voeren: betere clustering, automatisch doorgevoerde oplossingen, een dashboard. Voor een groot deel van de bevindingen is dat terecht, en de hierboven genoemde pijplijnen doen dat goed. Maar som eens de beslissingen op die het rapport daadwerkelijk aan de orde stelt en let op de aard ervan:
- Behouden of afschaffen. 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 terechtkomt. Een terugkerend knelpunt wordt op een bepaalde hoogte opgelost: een persoonlijke opmerking, een aanwijzing of vaardigheid, een omgevingsconfiguratie, de documentatie, het werkmateriaal zelf, het proces of stroomopwaarts bij een leverancier. Deze elementen hebben eigenaren, en die eigenaren zijn verschillende personen.
- Prioriteit bij aggregatie. Vijf minuten per persoon per sessie die zomaar terzijde worden geschoven, 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 vastgelegd. Een lus zonder deze controle is als een vliegwiel dat in de lucht ronddraait.
Geen van deze zaken is een berekening. Het zijn stuk voor stuk onderhandelingen tussen mensen die elk een ander onderdeel van de teamwerking in handen hebben. Zelfstandige beoefenaars verwerken deze beslissingen op legitieme wijze op basis van hun intuïtie; fleet-pijplijnen stellen op legitieme wijze de machinaal leesbare subset samen op machinesnelheid. 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 de retro, of een soortgelijke ceremonie?
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 die de besluitvormingsgroep moet hebben: 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 het proces, de documentatie, de tools en de 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 de harness (Osmani, Agent Harness Engineering).
Maar de eerlijke vorm van deze bewering legt de nadruk op de concurrenten in plaats van een winnaar aan te wijzen:
- Sprintplanning heeft de meeste zeggenschap in de vergaderruimte, maar de agenda ervan is toekomstgericht en chronisch overvol; er is dan ook steevast te weinig ruimte voor retrospectieve 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 optie en volstaat voor het overgrote deel van de routinezaken. Waar het echter tekortschiet, is het nemen van beslissingen: de keuze tussen behouden of schrappen is een onderhandelingskwestie, meningsverschillen over prioriteiten overschrijden de grenzen van de verantwoordelijkheden, en het herprioriteren vereist dat de verantwoordelijken aan hetzelfde gesprek deelnemen.
- Het nulalternatief (alleen praten over AI in de retro, geen gegevens, geen labels) is gratis, past bij de huidige situatie en kan voor een klein team met beperkt gebruik van agents wellicht 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 helemaal opnieuw begint. De onderstaande werkwijze past u toe wanneer dat gesprek zich steeds blijft herhalen.
De bewering, eerlijk gezegd: de retro, of uw bestaande ceremonie van vergelijkbare aard. De maandelijkse campagne-evaluatie van een mediateam en de triage-evaluatie van een ondersteuningsteam zijn dezelfde procedure onder verschillende benamingen, en niets in deze werkwijze duidt op code: het foutenlogboek van een verward advertentieaccount of een inconsistente sjabloonbibliotheek lijkt in alle opzichten op 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 gevallen, 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 gaat niet over op de meest bekwame modelbouwer in de ruimte, net zomin als zij overgaat op de meest bekwame ingenieur in de ruimte. Het is een organisatorisch gegeven, geen tekort aan bekwaamheid.
De agent neemt dus deel op dezelfde manier als de best geïnformeerde medewerker. Hij levert bewijsmateriaal: 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 aangeboden 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 scheiding een naam: in het ACE-raamwerk is de agent de 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 vormt het team de curatoren.
Eén asymmetrie betreft de gegevensstroom. Alles wat de agent de ruimte binnenbrengt moet onbeperkt toegankelijk zijn, omdat een agent die toestemming nodig heeft om wrijving te melden, dit onvoldoende rapporteert. 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: onbeperkte toegang voor inkomende gegevens, beperkte toegang voor uitgaande schrijfbewerkingen.
De vijftien minuten
Wat wij het team eigenlijk voorstellen om deze sprint te proberen, waarbij elke lus al ongewijzigd blijft:
- 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 voorgestelde oplossing ter grootte van een ticket en het beoogde niveau waarop deze is gericht. Dit wordt samen met het werk vastgelegd, zonder enige beperking.
- Voorafgaand aan de retro worden de inbreng en opmerkingen 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 doorgevoerd, en de drie belangrijkste aanbevolen acties. Het overzicht dient als basis voor het gesprek; het is geen vervanging ervan.
- 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 menselijke beoordeling: behouden of schrappen, de prioriteiten bevestigen of bijstellen, en de drie belangrijkste punten toewijzen aan verantwoordelijken.
- 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 lus terechtkomt. Het is ook op dat punt dat 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, niets beslist; 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 overblijvende probleem; de meeste mislukkingen zijn terug te voeren op het testraamwerk 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 leverancierscyclus: de output daarvan vormt 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. Het is niet noodzakelijk voor een zelfstandige professional, 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 toetsbare deel. Indien de leverancierscycli leiden tot daadwerkelijke, tool- en persoonsoverschrijdende beoordelingen – en niet louter tot het opslaan van gegevens in het geheugen van de gehele organisatie – wordt de rol beperkt 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 zijn 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 daarin.
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 wat er is gebeurd: 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 gids voor retrospectieven met AI-agenten.