Terugblik op de AI-samenwerking

Bij TeamRetro zijn wij geïnteresseerd in elke cyclus van voortdurende verbetering die een team doorloopt. AI-ondersteund werken is een nieuw gebied dat wij vanuit het perspectief van onze retrospectieven hebben onderzocht; in deze gids delen wij de conclusies die wij tot nu toe hebben getrokken. Neem deze gids ter hand, pas hem aan en pas hem toe in de tools of werkwijzen die u al gebruikt.

Deel 1 — de gids

Waarom dit thuishoort in een teamceremonie

Ergens binnen uw team heeft een AI-assistent deze maand veertig minuten besteed aan het controleren van een „defecte” advertentiecampagne die opzettelijk was gepauzeerd, omdat dit niet in de opdrachtomschrijving stond vermeld. De persoon die de sessie leidde, corrigeerde dit, haalde zijn schouders op en ging verder. Als vier collega’s op verschillende momenten tegen dezelfde lacune aanlopen, leidt dat tot uren aan onopgemerkte verspilling per maand — en niemand heeft er weet van, omdat iedereen dit in zijn eentje heeft opgevangen.

Dat is het patroon bij AI-sessieproblemen: het is chronisch en van geringe omvang, waardoor er nooit een analyse achteraf plaatsvindt, en het is van voorbijgaande aard, zodat het verdwijnt zodra de sessie eindigt. De meeste teams kunnen het al waarnemen (ongeveer 90% registreert de traces van hun agents), maar veel minder teams zetten dit om in oplossingen: slechts ongeveer 37–52% evalueert systematisch wat zij vastleggen (LangChain, juni 2026).

De verbeteringscycli die er wel zijn, zijn goed, en deze werkwijze bouwt op al deze elementen voort:AGENTS.md en updates van contextbestanden, geheugensystemen, pijplijnen voor zelfverbetering van leveranciers, foutanalyse op basis van tracegegevens (Husain & Shankar, evals FAQ). Zelfs de leveranciers grijpen terug op het begrip ‘retrospective’: 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). Maar vrijwel al deze cycli zijn individueel: één persoon en zijn of haar agent, of één platform en zijn of haar fleet. Wat het teamniveau toevoegt, is aggregatie: wrijving die per persoon neerkomt op vijf afgedane minuten, wordt pas in het totaalbeeld een belangrijke teamkost — en om hierop te reageren (de gedeelde sjabloon herschrijven, het intake-proces aanpassen, de tool aanschaffen) is een beslissingsbevoegdheid nodig die geen enkel individu afzonderlijk bezit. Rahul Garg’s ‘Feedback Flywheel’ benoemt de gelegenheid: “een agendapunt in de bestaande sprint-retrospective: wat werkte er deze sprint met AI?” (martinfowler.com), en deze handleiding is een manier om dit uit te voeren.

Eén eerlijke opmerking vooraf: wat hier nodig is, is een terugkerende, onbevooroordeelde, op feiten gebaseerde bijeenkomst waarbij de verantwoordelijken voor de verbeteringen aanwezig zijn. Voor de meeste teams is dat de retro, maar een sprintplanningssessie, een maandelijkse operationele evaluatie of een accountbeoordeling door het mediateam zijn hiervoor eveneens geschikt. De retro, of uw bestaande ceremonie van vergelijkbare aard.

Goed om te weten als facilitator: Scrum.org benadert hetzelfde onderwerp vanuit het perspectief van de statistieken; hun gids voor het houden van de sprint-retrospective wanneer de helft van uw team uit AI-agenten bestaat kadert het evenement opnieuw als een datagestuurde evaluatie van de prestaties van de agenten (herschrijvingen van prompts, afwijkingspercentages, tokenverbruik). Deze gids volgt een aanvullende benadering: het achterhalen van de onderliggende oorzaken en het vinden van oplossingen voor de gehele samenwerking, waarbij de agents hun eigen verslag van het werk bijdragen, dat via de TeamRetro MCP-server wordt ingediend indien u TeamRetro gebruikt. Teams met een groot aantal agents kunnen baat hebben bij elementen uit beide benaderingen.

Hoe de werkwijze in zijn geheel in zijn werk gaat

1. Verslaglegging, per sessie. Aan het einde van elke substantiële, door AI ondersteunde sessie stelt de medewerker een kort, gestructureerd verslag: wat er goed ging, wat vertraging opleverde (elk punt voorzien van een hoofdoorzaak en een voorgestelde oplossing), wat de AI had geraden, en de oplossing met de grootste impact. Eén bestand per verslag, in een gedeeld logboek.
2. Samenvatting, na circa 5 vermeldingen. Voorafgaand aan de ceremonie vat de medewerker het logboek samen tot een overzicht van één pagina: terugkerende thema’s gerangschikt op basis van frequentie × kosten, een verdeling van de onderliggende oorzaken, een controle of eerdere oplossingen zijn doorgevoerd, en de drie belangrijkste aanbevolen acties.
3. Neem binnen 15 minuten een besluit. De briefing is een agendapunt in uw bestaande retro, geen aparte vergadering. Het team maakt een prioriteitenlijst: elk knelpunt wordt beoordeeld (behouden of schrappen), er wordt vastgesteld waar elke oplossing moet worden doorgevoerd en er worden verantwoordelijken aangewezen voor de belangrijkste acties. In de briefing van de volgende cyclus wordt gerapporteerd of het knelpunt daadwerkelijk is verminderd.

De stappen voor het vastleggen en de synthese zijn geïmplementeerd als open-source-agentvaardigheden in onze TeamRetro-skills-repo, mocht u snel aan de slag willen gaan.

De agent rapporteert zonder beperkingen: een agent die toestemming nodig heeft om wrijving vast te leggen onderrapportage, en menselijke correcties achteraf vormen een aanvullend signaal, geen controlepunt waarop de lus wacht. De beslissing blijft bij het team, en dat is geen beleefdheid: de oplossingen worden verwerkt in begrotingen, documenten, processen en hulpmiddelen waarvoor mensen verantwoordelijk zijn en verantwoording moeten afleggen. De agent levert bewijsmateriaal en voorstellen aan; de vergadering beslist.

Hoe een goed artikel eruitziet

Hier volgt een concreet voorbeeld, dat bewust geen programmeersessie betreft:

# 2026-07-16 — Monthly ads account review

**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped

## Went well
- Exec summary shipped in one pass; the account structure doc from last month held up

## Friction
- **[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

## Guesses made
- Assumed the target CPA unchanged from June — unverified

## Do this first
Campaign-status flags in the brief template — kills the largest single time sink this month.

Let op de discipline. Elk wrijvingspunt vermeldt een moment en een kost (globale schattingen zijn gemarkeerd met (est.)), bevat precies één label voor de hoofdoorzaak uit een kleine, vaste woordenlijst (labels zoals ambiguous-instruction, missing-context, missing-documentation, missing-access-or-tool,agent-error , of work-material-friction, waarbij het materiaal zelf de rem was: een verwarde campagnestructuur, een verouderde spreadsheet, een module waar niemand aan wil komen — altijd met vermelding van het concrete materiaal), en eindigt met een oplossing ter grootte van een ticket waarin de altitude wordt genoemd: hoort deze oplossing thuis in een privé-geheugennotitie, een procedure, de omgeving, de documentatie, het werkmateriaal zelf, het proces of stroomopwaarts bij een leverancier? Vaste labels zorgen ervoor dat vermeldingen tussen verschillende personen en sessies onderling vergelijkbaar zijn; „de documentatie was verwarrend“ kan niet worden samengevat, maar achtmissing-documentation vermeldingen kunnen dat wel. Vagheid is de foutmodus; „niets opmerkelijks“ is een geldige vermelding.

Een goede brief bestaat uit één pagina: thema’s die vaak voorkomen („4 van de 9 sessies”) en voorbeelden met datumvermelding, een duidelijke vermelding van welke groep onderliggende oorzaken de overhand heeft (briefing, documentatie, werkmateriaal, hulpmiddelen of medewerker; daar moet de aandacht van het team naar uitgaan), de controle op de implementatie van eerdere suggesties, en drie actiepunten waaraan een verantwoordelijke kan worden toegewezen. Het vormt de basis voor het gesprek; het vervangt dit niet.

Toepassingsgebied: één logboek per beoordelingsgebied

Houd één logboek bij per beoordelingsgebied: het gebied waar de aanpassingen terechtkomen. Voor ontwikkelingswerk is dat doorgaans de repository, omdat de documentatie, configuratie en conventies daar zijn ondergebracht. Voor niet-codeerwerk is dat het advertentieaccount, de support-inbox of de klantrelatie; het logboek wordt bewaard in de documentmap van die werkruimte. Een vermelding die buiten het toepassingsgebied wordt opgeslagen, wordt nooit gevonden door degene die uiteindelijk verantwoordelijk is voor de oplossing. Het schema blijft overal identiek; het schema, en niet de opslaglocatie, zorgt ervoor dat vermeldingen kunnen worden samengevoegd.

De regels inzake het niet-registreren

Bijdragen worden vastgelegd, gedeeld en blijven langer bestaan dan hun context, dus bepaalde zaken mogen nooit in een ‘friction’ worden opgenomen: geheimen, inloggegevens of sleutels in welke vorm dan ook; klantgegevens of persoonlijke informatie; nog niet gepubliceerde bedrijfscijfers; en, het belangrijkste voor de retrocultuur, namen, functies of alles waarmee een persoon kan worden geïdentificeerd. Beschrijf de tekortkoming en wat deze heeft gekost, maar nooit wie deze heeft veroorzaakt: „de opdracht liet het publiek in het ongewisse“, niet „de opdracht van X“. Frictiepunten hebben betrekking op input en systemen, niet op personen. Indien de frictie binnen een bepaald werkterrein niet kan worden beschreven zonder gevoelige context, houd die vermeldingen dan privé en deel uitsluitend de samengevatte opdracht.

Deel 2 — de sjabloon „AI Collaboration Retro“

Een kant-en-klaar format: vijf vragen, gebaseerd op het entry-schema, die kunnen worden uitgevoerd in TeamRetro of op elk willekeurig whiteboard:

Rubriek	Vraag	Korte opmerking
Het is goed verlopen	Wat is er deze cyclus sneller of beter verlopen dankzij AI-ondersteund werk?	Alleen overwinningen op basis van aangevoerd bewijs: wat beschermd en herhaald moet worden, geen overdrijving van lof.
Wrijving, met de oorzaak	Waar trad de vertraging op, en wat was de onderliggende oorzaak daarvan?	Op elke kaart staan het moment, de geschatte kosten en één term uit de vaste woordenschat van het team vermeld.
Veronderstellingen die wij voorlopig laten staan	Wat heeft de agent (of wij) aangenomen zonder over voldoende informatie te beschikken?	Latente wrijving die tot nu toe nog geen schade heeft veroorzaakt; markeer alles wat nog niet is geverifieerd.
Behouden of afschaffen	Welke van deze wrijvingen hebben wij bewust gekozen?	Beoordelingsfasen en goedkeuringsstappen kunnen bewuste controlepunten zijn (samenvatting van de lezing van Ronacher op AIE Europe); het schrappen van een dergelijke stap is een beslissing van het team.
Doe dit eerst	Van alles wat hier te vinden is, welke aanpassing levert het meeste voordeel op, en op welke hoogte?	Maximaal drie, elk met een eigenaar en het niveau waarop het valt: documenten, omgeving, proces, materiaal of upstream.

Deel 3 — Vraagkaarten voor de begeleider

Vragen die u kunt stellen wanneer een team een AI-retro-opdracht meebrengt naar de bijeenkomst. Eén vraag per kaart; gebruik de vragen die voor het gesprek van belang zijn.

1. “Uit welke sessie stamt dit, en wat waren de kosten?” Voor claims met betrekking tot patronen is bewijsmateriaal met een datum vereist; een kaart zonder tijdstip en kosten kan niet worden beoordeeld.
2. “Is deze wrijving een controlepunt dat wij zelf hebben gekozen?” Eerst de afweging: een zekere mate van wrijving is de sturing (samenvatting van Ronachers lezing op AIE Europe), en wrijvingsloos is niet gratis; Thoughtworks waarschuwt voor de cognitieve schuld die hierdoor ontstaat (aankondiging).
3. “We hebben deze oplossing de vorige keer al voorgesteld. Waarom is er niets mee gedaan?” Niet-overgenomen herhaalde suggesties vormen het belangrijkste signaal in elke briefing; zonder deze vraag is het hele proces slechts schijn.
4. “Dit kostte ieder van u tien minuten — wat kost het het team per maand?” Aggregatie is het belangrijkste voordeel van de teamlaag; stel deze vraag telkens wanneer er een kaart wordt genegeerd.
5. “Hoort deze oplossing thuis in de documentatie, de omgeving of in de manier waarop wij de opdracht omschrijven?” De hamvraag. Als u te laag mikt, keert de weerstand terug; als u te hoog mikt, maakt u het verkeerde artefact te omvangrijk.
6. “Van wie is het voorwerp waarin deze reparatie terechtkomt?” Een handeling zonder eigenaar is een item op de verlanglijst. Als de eigenaar niet in de kamer aanwezig is, is dat eveneens een vondst.
7. “Voordat we dit een fout van de agent noemen, moeten we ons afvragen of de invoer wel toereikend was?”agent-error is het residuele label, niet de standaard; de standaard die moet worden verworpen, is het de agent de schuld geven terwijl het probleem bij de harness of de opdracht lag — los in plaats daarvan het probleem met de harness op (Osmani, Agent Harness Engineering).
8. “Welke groep onderliggende oorzaken domineert de verdeling, en gaat onze aandacht daar naartoe?” Uit de cijfers in het rapport blijkt of het probleem ligt bij de instructies, de documentatie, het werkmateriaal, de hulpmiddelen of de instellingen van de agent. De aandacht moet worden gericht op de gegevens.
9. “Heeft een persoon dit opgemerkt, of was het de sensor?” Menselijke controle blijft de belangrijkste sensor: uit een productieonderzoek bleek dat ongeveer 70% van de stille storingen voor het eerst werd opgemerkt door een persoon die merkte dat er iets niet klopte (arXiv 2606.14589). Beschouw deze ontdekkingen als bewijs van de hoogste orde, niet als onderbrekingen.
10. “Houdt dit verband met de reikwijdte van ons team, of met die van een ander team?” Oplossingen vallen onder de reikwijdte van hun eigen beoordelingsproces; een kaart die betrekking heeft op de gedeelde sjabloon of het proces van een ander team dient te worden doorgestuurd, en niet te worden opgenomen.
11. “Is dit een bespreking of een registratie?” De voor de hand liggende correcties worden direct in de tracker opgenomen; besteed die vijftien minuten uitsluitend aan de omstreden beslissingen: behouden of schrappen, meningsverschillen over hoogte, prioriteiten.
12. “Ligt deze beslissing boven het bevoegdheidsniveau van een van ons?” Het aanschaffen van een hulpmiddel, het aanpassen van de invoer, het doorverwijzen naar een leverancier — de herziene prioriteitenlijst overschrijdt vaak de beslissingsbevoegdheid van een individu. Juist daarom is dit punt überhaupt ter sprake gebracht.

---

Volgend hoofdstuk: Aan de slag in tien minuten. Installeer de vaardigheden en voer uw eerste registratie uit, of pas het bovenstaande sjabloon toe op het bord dat uw team al gebruikt. Onderdeel van de handleiding voor retrospectieven met AI-agenten.