Het overzicht: feedbacklussen, hulpmiddelen en benaderingen voor agenten

TeamRetro is geïnteresseerd in elke cyclus van voortdurende verbetering die teams doorlopen; AI-ondersteund werk is een nieuw gebied dat wij vanuit het perspectief van retrospectives nader onderzoeken. Deze pagina dient als naslagwerk bij deze gids: het gehele onderwerp wordt hier systematisch uiteengezet. Mocht u liever met het verhaal beginnen, begin dan bij het begin van de gids en kom daarna terug.

Waar gaat deze pagina over?

Drie zaken, in volgorde: de levenscyclus die een enkel probleem doorloopt vanaf het moment dat het zich voordoet totdat het is opgelost; de benoemde cycli die het vakgebied heeft ontwikkeld om die levenscyclus te doorlopen, gesorteerd op het niveau waarop ze functioneren; en de classificatiesystemen die worden gebruikt om te benoemen wat er mis is gegaan. Lees het van boven naar beneden om uw team te lokaliseren: welke fasen uw tools al bestrijken, welke cyclus u al onder een andere naam uitvoert, en welke terminologie u zou gebruiken om bevindingen te benoemen. Alles hier staat op zichzelf: niets vereist dat u onze werkwijze, onze benamingen of ons product overneemt.

De levenscyclus: zeven fasen, van wrijving tot oplossing

Wanneer een medewerker die daadwerkelijk werk verricht op weerstand stuit (een ontbrekend document, een dubbelzinnige instructie, een onbetrouwbaar hulpmiddel), is dat signaal van korte duur: de medewerker zoekt een oplossing, de sessie eindigt en bij de volgende sessie stuit men opnieuw op dezelfde hindernis. De wrijvingspatronen van Rahul Garg geven de kosten van de eerste orde weer (de frustratiecyclus van genereren → beoordelen → past niet → opnieuw genereren); de onderstaande levenscyclus brengt het probleem van de tweede orde in kaart: wat er moet gebeuren om wrijving op het juiste niveau op te lossen. De kloof is meetbaar: circa 90% van de teams registreert de activiteiten van agenten, maar slechts circa 37–52% evalueert deze systematisch (LangChain, juni 2026). De meeste teams kunnen wrijving waarnemen; veel minder teams zetten deze om in oplossingen.

Podium	De vraag waarop het antwoord geeft	Opties	Term voor beroepsbeoefenaars
0 · Hosting	Waar wordt de agent uitgevoerd?	lokaal CLI · web · IDE · CI/headless · gepland	n.v.t.
1 · Detectie	Hoe wordt wrijving waargenomen?	zelfcontrole · beoordeling door een tweede persoon · correctie door een mens · telemetrie	trace-beoordeling, foutanalyse
2 · Instrumentatie	Hoe weet de agent dat hij dit moet volgen?	vaardigheid · haak · conventie · opdracht	n.v.t.
3 · Opname	Hoe wordt dit vastgelegd, en waar?	geheugen · MCP-opslag · logbestanden/traces · tickets · gemarkeerde commits	open codering, episodisch geheugen
4 · Oogsten	Hoe kunt u gegevens verzamelen die verder gaan dan één sessie?	trace-mining versus artefact-aggregatie · sweep versus gebeurtenis · deduplicatie	n.v.t.
5 · Synthese en doelgerichtheid	Ruwe gegevens → patronen → in hoeverre moet dit worden gecorrigeerd?	cluster + score, vervolgens indelen op basis van hoogte	axiale codering, taxonomie van storingen
6 · De cirkel rond maken	Heeft de oplossing toekomstige wrijving verminderd?	de trend meten	Feedback-vliegwiel, compounding-techniek

Fase 0: Hosting

Alles wat daarna volgt, hangt af van de plek waar de agent wordt uitgevoerd. Een lokale CLI-agent slaat een transcript op schijf op en kan geheugenbestanden schrijven; een CI- of headless-agent kan van voorbijgaande aard zijn, waarbij het enige spoor bestaat uit wat er is gelogd voordat de container werd beëindigd; een web- of IDE-agent bewaart een server-side geschiedenis die u kunt opvragen, maar niet kunt doorzoeken met grep; een geplande agent draait zonder menselijk toezicht. De hostingomgeving bepaalt de mogelijkheden voor elke volgende fase: wat er waarneembaar is, waar de status kan worden bewaard en wie (of wat) deze kan inzien. De afweging: uitgebreidere lokale waarneembaarheid versus de reproduceerbaarheid en centrale opslag van gehoste uitvoeringen.

Fase 1: Opsporing

Vier kanalen, zelden exclusief. Zelfdetectie (de agent herkent zijn eigen herpogingen en terugkeren) is het goedkoopst, maar het meest bevooroordeeld: de agent weet niet wat hij niet weet. Beoordeling door een tweede agent, waarbij een andere agent het transcript achteraf doorneemt, is objectiever maar vereist een tweede doorloop. Menselijke correctie levert het signaal van de hoogste kwaliteit op en is nog steeds de dominante methode: uit een acht weken durend productieonderzoek bleek dat ongeveer 70% van de stille fouten voor het eerst werd opgemerkt door een mens die merkte dat er iets niet klopte (arXiv 2606.14589). Telemetrie (foutpercentages van tools, geweigerde toestemmingen, aantal herhalingen) is automatisch maar oppervlakkig: het weet dat, niet waarom. De sterkste opstellingen maken gebruik van een drievoudige controle: telemetrie geeft aan waar u moet kijken, een beoordelingsronde verklaart waarom.

Fase 2: Instrumentatie

Een agent registreert geen wrijving tenzij er iets is dat deze veroorzaakt. De opties, afhankelijk van de mate waarin zij steunen op het geheugen van het model: een vaardigheid (een expliciete, overdraagbare procedure die bij een stopmoment wordt aangeroepen: duidelijk, maar moet daadwerkelijk worden geactiveerd), een hook (wordt automatisch geactiveerd bij het starten of stoppen van een sessie: betrouwbaar, maar grof), een conventie (een instructie in een contextbestand: geen infrastructuur, op vertrouwen gebaseerd) of een commando (door een mens geactiveerd: weloverwogen, maar afhankelijk van menselijke tussenkomst). Dit is de fase die het vaakst wordt overgeslagen, en dat is de reden waarom zoveel wrijving onopgemerkt blijft: niemand heeft de agent opgedragen om hiernaar te kijken.

Fase 3: Opname

Twee vragen: wat een goed document bevat en waar het wordt bewaard. Een bruikbaar document bevat onderbouwde gegevens (wat er is gebeurd, wat het heeft gekost), is voorzien van één label uit een vast vocabulaire zodat documenten later vergelijkbaar zijn, en eindigt met een voorstel voor de volgende stap. Wat betreft de opslaglocatie: elk optie brengt een reële afweging met zich mee: geheugenbestanden (duurzaam en soepel, maar privé en losjes gestructureerd), een MCP-opslag (gedeeld en doorzoekbaar, maar vereist een server), logs/traces (automatisch en volledig, maar de informatie gaat schuil in ruis), tickets (actiegericht en zichtbaar voor het team, maar omvangrijk per item), of getagde commits en PR’s, bijvoorbeeld een labelwork-material-friction dat de weerstand koppelt aan de exacte wijziging, hoewel dit alleen geldt wanneer het werk in versiebeheer terechtkomt. Niets hiervan is codespecifiek: het accountlogboek van een mediateam of de geannoteerde geschiedenis van een supportwachtrij zijn eveneens registratiesubstraten. Een waarschuwing die geldt voor alle onderliggende elementen waarop agenten later vertrouwen: door agenten geschreven geheugen vormt een bekend aanvals- en driftoppervlak (OWASP Agentic Top 10, ASI06), een argument voor op bewijs gebaseerde, gecontroleerde schrijfbewerkingen.

Fase 4: Oogsten

Wrijving tijdens één sessie is ruis; dezelfde wrijving gedurende acht sessies is een procesprobleem. De strategische keuze is trace-mining (het opnieuw doorlezen van ruwe transcripties: volledig, maar kostbaar en met grote gevolgen voor de privacy) versus artifact-aggregatie (het doorzoeken van bewust opgestelde documenten: goedkoop, maar slechts zo goed als de discipline in fase 3); echte pijplijnen combineren beide. Vervolgens is er de cadans (een geplande doorloop versus het verzamelen aan het einde van een sessie) en het weinig glamoureuze werk van het ontdubbelen: dezelfde wrijving, op vijf verschillende manieren verwoord door vijf personen, moet worden teruggebracht tot één patroon met een eerlijke telling. Bij het verzamelen komt de waarde naar voren, omdat aggregatie de prioriteiten opnieuw weegt: een ergernis van vijf minuten die niemand afzonderlijk zou verhelpen, vormt in totaal een belangrijke kostenpost voor het team. Voor een concreet voorbeeld van verzamelen over meerdere personen heen in plaats van per sessie, kunt u bekijken hoe vijf van ons onze persoonlijke herinneringen aan de Claude-code hebben gebundeld tot gedeelde regels.

Fase 5: Synthese en doelgerichtheid

Twee stappen. Clusteren en scoren: groepeer bevindingen in patronen, gerangschikt op basis van frequentie × kosten; hiervoor zijn de onderstaande classificatieschema’s bedoeld. Richt u op het juiste niveau: leid elk patroon naar het juiste niveau van oplossing, van tijdelijk tot structureel (geheugen → vaardigheid/aanwijzing → omgeving & configuratie → documentatie → het werkmateriaal zelf → proces → upstream-tool of leverancier). Als u te laag mikt (een persoonlijke geheugennotitie voor wat in feite een ontbrekend teamdocument is), ontstaat er opnieuw wrijving voor alle anderen; als u te hoog mikt (een nieuwe vaardigheid voor een eenmalige situatie), blaast u een artefact zo op dat het uiteindelijk niet meer wordt gelezen. Het vakgebied kwam onafhankelijk van elkaar tot dezelfde gradatie: verlaag het belang van vluchtige herinneringen, bevorder duurzaam leren via versiebeheer. In de documentatie van Windsurf/Devin staat dat terugkerende lessen moeten worden omgezet in regels of in AGENTS.md (het bestand met permanente instructies dat agenten lezen) in plaats van te vertrouwen op automatische herinneringen, de Codex-richtlijnen van OpenAI stellen dat het tweemaal maken van dezelfde fout aanleiding geeft tot een update van AGENTS.md, en het geheugen van Copilot verloopt per ontwerp na 28 dagen: niet-gepromoveerd geheugen dient te verdwijnen. Eén samenvattend oordeel is gemakkelijk over het hoofd te zien: niet alle wrijving is verspilling. Een deel ervan vormt het stuurvlak: „wrijving is wat nodig is… om te sturen“ (een samenvatting van Ronachers toespraak op AIE Europe), dus bij het triageren gaat het om behouden of verwijderen, niet alleen om repareren.

Fase 6: De cirkel rond maken

De echte test voor de gehele levenscyclus: neemt dit soort wrijving in de loop van volgende sessies af? Een oplossing die weliswaar wordt ingediend maar nooit wordt geïmplementeerd, of wel wordt geïmplementeerd maar niets verandert, is slechts schijn. Dit is de ‘Feedback Flywheel’-toestand van Garg en het uitgangspunt van compounding engineering: elke oplossing maakt de volgende werkeenheid eenvoudiger, mits de kringloop daadwerkelijk wordt gesloten.

De benoemde lussen, per bedrijfsniveau

Binnen dit vakgebied wordt deze levenscyclus onder minstens een half dozijn verschillende benamingen aangeduid. Ze zijn allemaal even goed; niets op deze pagina vervangt een van deze benamingen. De enige manier waarop deze tabel is gesorteerd, is op het niveau waarop elke lus functioneert, en het volgende valt op zodra de tabel is gesorteerd:

Lus	Loopt van	Sluit de cirkel door
Loop Engineering / Composiettechniek	één beoefenaar	persoonlijke regels, aanwijzingen, draaiboeken
continuous-learning-v2 (Everything Claude Code)	één beoefenaar	een op de achtergrond draaiende agent die logbestanden van tool-aanroepen omzet in regels met een betrouwbaarheidsscore, die bij het begin van de sessie worden geladen
agent-retro	één sessie	aanpassingen aan instellingen en configuraties per sessie op basis van het transcript
Sensoren voor kabelboomontwerp (Thoughtworks)	het ondersteuningssysteem van één codebase (de structuur rondom het model)	het integreren van ingebouwde feedbackinstrumenten (tests, linters, CI) in de lus van de agent
Dreaming (Anthropic, OpenAI)	het geheugen van één platform	het tijdens inactieve periodes verzamelen van sessiegeschiedenis in gated memory diffs, voor de gehele vloot
LangSmith-motor / Braintrust-onderwerpen	één observabiliteitsstack	productiestoringen groeperen in problemen, PR’s en evaluaties opstellen
Fabriekssignalen	één platform voor makelaars	het herkennen van patronen van sessieproblemen en het automatisch aanmaken van tickets
Inzichten uit de gh-aw-sessie (GitHub)	de sessies van één platform	geautomatiseerde rapporten voor sessieanalyse over de gehele looptijd van agentgebaseerde workflows (voorbeeld met 50 sessies)
Feedback-vliegwiel (Garg)	de artefacten van één team	de opgedane kennis verwerken in voorbereidende documenten, opdrachten, draaiboeken en richtlijnen

Lees de middelste kolom nogmaals: één beoefenaar, één sessie, één platform, één stack. Vrijwel elke cyclus in het veld verloopt op individueel of vlootniveau: een persoon en zijn of haar agent, of een leverancier en zijn gehele installatiebestand. Alleen het vliegwiel van Garg richt zich op het team, en zijn cadanslijst noemt de locatie (een agendapunt in de bestaande sprint-retrospective) zonder dit operationeel te maken. Dat is onze interpretatie van dit soort zaken, en het is het enige punt waarop de eigen invalshoek van deze gids naar voren komt: het teamniveau is de open laag (veel mensen, veel agents, meer dan één tool, waarbij de fix-eigenaren deel uitmaken van hetzelfde gesprek). Als u een van de bovenstaande cycli uitvoert, blijf deze dan uitvoeren; de teamlaag maakt gebruik van de output ervan, maar concurreert er niet mee.

Everything Claude Code (ECC), een project onder MIT-licentie, is het duidelijkste voorbeeld op de kaart van een lokale lus waarin de agent zijn eigen regels opstelt. De vaardigheid „continuous-learning-v2” (ECC 2.2.3 op het moment van schrijven) registreert aanroepen van tools via een Claude Code-hook. Een op de achtergrond draaiende observer-agent op Haiku leest dat logboek periodiek en schrijft „instincten“ op: korte trigger-en-actie-regels, elk met een betrouwbaarheidsscore die stijgt wanneer het patroon opnieuw wordt waargenomen en week na week afneemt wanneer dat niet het geval is. Bij het begin van een sessie worden standaard maximaal zes instincten met een betrouwbaarheidsscore van 0,7 of hoger direct in de context van de agent opgenomen, zonder dat er een beoordelingsstap plaatsvindt. De observer is standaard uitgeschakeld, dus het inschakelen ervan is een bewuste keuze. Voor de opstelling van één persoon vormt dit een volledige lus. Voor een context waarop een heel team vertrouwt, zouden we de schrijfbewerkingen in plaats daarvan filteren: bewijsmateriaal komt vrij binnen, regels worden via een beoordeling uitgesloten.

De classificatiesystemen

Om wrijving te clusteren hebt u categorieën nodig, en de schema’s van het vakgebied classificeren verschillende zaken; het zijn niet zozeer rivalen als wel instrumenten die op verschillende vraagstukken zijn gericht:

Schema	Wat eronder valt	Vorm	Betrouwbaarheid / herkomst
MAST	hoe multi-agent systemen falen	14 modi / 3 categorieën	150 door deskundigen beoordeelde sporen, gevalideerd op meer dan 1600; κ-coëfficiënt tussen annotatoren = 0,88
De school van de foutanalyse (Husain/Shankar)	wat uw eigen sporen ook mogen onthullen	open; de categorieën komen uit uw gegevens naar voren	methodologie, geen vaststaand geheel; het bestuderen van uw traces is „de belangrijkste activiteit bij evaluaties”
Vierlaags (Greyling)	welke laag van de stack is uitgevallen	4 lagen	samenvatting van storingsmeldingen uit de praktijk; ~9,9% van de storingen wordt toegeschreven aan modelredeneringen
TraceProbe	acties voor foutafhandeling in traces	9 maatregelen	geautomatiseerde sporenanalyse
Fabriekssignalen	welk symptoom van wrijving tijdens een sessie zich voordoet	7 signaaltypen	productiesessies met coderingsagenten
Onze terminologie inzake de onderliggende oorzaken	waarom er wrijving ontstond bij de samenwerking	10 labels / 5 groepen; de groep geeft de vaste hoogte aan	werksessies, zowel voor ontwikkelaars als voor niet-ontwikkelaars; de interbeoordelaarsbetrouwbaarheid is nog niet gemeten: het experiment is momenteel aan de gang en de woordenschat is voorzien van versienummers en kan worden herzien

Twee opmerkingen bij het lezen. Ten eerste verschillen de assen daadwerkelijk van elkaar: symptoomschema’s (signalen van Factory) geven aan dat een sessie mis is gegaan; laagschema’s (Four-Layer) geven aan waar in de stack; een oorzakenvocabulaire geeft aan waarom, en dat is wat een label in staat stelt om de oplossing gedeeltelijk zelf te sturen (een work-material-frictionbevinding wijst op het materiaal zelf: technische schuld in de code, of een verwarde rekening, een verwarde tabel of een verwarde sjabloon daarbuiten; een briefinglabel wijst op het proces). Ten tweede is de spanning tussen ‘universeel’ en ‘emergent’ reëel: vaste taxonomieën bieden vergelijkbaarheid en meetbare betrouwbaarheid bij het toekennen van labels (MAST’s κ = 0,88 is de maatstaf), terwijl emergente categorieën aansluiten bij uw daadwerkelijke verdeling van storingen. Een werkbare middenweg houdt een kleine vaste woordenschat aan voor aggregatie, met open-gecodeerde bewijsnotities onder elk label. En een waarschuwing die het hele vakgebied heeft verdiend: labels in agent-error-stijl zouden het uitzondering moeten zijn, niet de standaard. De ‘harness-engineering’-school verwerpt die reflex expliciet, waarbij de ingenieur het model de schuld geeft en het onder „wachten op de volgende versie“ archiveert; repareer in plaats daarvan het harnas (Osmani, Agent Harness Engineering). De vierlagenanalyse schrijft slechts ~9,9% van de mislukkingen toe aan modelredenering.

Bepaal uw locatie

Een korte diagnose. Doorloop de stappen en geef aan wat u al hebt:

• U beschikt over traces of sessielogboeken (monitoringtools, JSONL op schijf, geschiedenis aan de serverzijde) → Detectie en registratie zijn hiermee gedekt. Uit de cijfers van LangChain blijkt dat de meeste teams het hierbij laten.
• Er is iets dat de agent eraan herinnert om wrijving te registreren (een vaardigheid, een stop-hook, een conventie in het contextbestand) → De instrumentatie is geregeld; als er niets is dat dit doet, is dat doorgaans de goedkoopste eerste oplossing.
• U werkt AGENTS.md / CLAUDE.md bij wanneer iets zich herhaalt → u past synthese toe op individueel niveau; dit is het ‘twee keer dezelfde fout’-patroon uit de Codex.
• Uw platform selecteert herinneringen voor u (consolidatie in de stijl van ‘Dreaming’, Copilot-geheugen) → verzameling en synthese op vlootniveau, binnen dat platform.
• Uw observability-stack groepeert storingen en voorlopige oplossingen (Engine, Topics, Signals) → synthese op stackniveau, voor het verkeer dat de stack waarneemt.
• Er is iemand die regelmatig de verschillende sessies, personen en hulpmiddelen doorneemt, waarna de verantwoordelijken voor de oplossingen gezamenlijk een besluit nemen → Verzamelen en samenvatten op teamniveau. Dit is de rij die de meeste teams leeg laten.

De veelvoorkomende leemte is, naar onze waarneming, die laatste rij: het totaaloverzicht over alle tools en personen heen, en de afwegingen die daaruit voortvloeien: behouden of schrappen, op welk niveau, wiens prioriteit. Let op de vraag over de reikwijdte van de evaluatie die hiermee gepaard gaat: welk werk hoort in één categorie voor één bespreking? De repository, het product, het advertentieaccount, de support-inbox, de klantbetrokkenheid? Bepaal de reikwijdte op basis van waar oplossingen terechtkomen, en zorg ervoor dat niet-code-gerelateerde zaken net zo vanzelfsprekend worden doorgestuurd als de code-gerelateerde zaken.

In het resterende deel van deze handleiding worden de verschillende lagen één voor één behandeld: in de inleiding wordt het verhaal op verhalende wijze verteld; in de volgende hoofdstukken wordt ingegaan op het vastleggen van wrijving op het moment zelf, het verzamelen van gegevens over meerdere sessies heen, de beslissing over de hoogte en hoe een locatie op teamniveau er in de praktijk uitziet. Begin waar uw lege rij zich bevindt.

Volgend hoofdstuk: Hoe een goed frictierapport eruitziet, gaat in op het vastleggen van het moment, de labels voor de onderliggende oorzaken en de regels voor het niet-registreren van bepaalde gegevens.