Het overzicht: feedbacklussen, hulpmiddelen en benaderingen voor agenten
De referentiekaart voor feedbacklussen van agenten: de levenscyclus van wrijving in zeven fasen, de in het vakgebied gebruikte benamingen voor de lussen per niveau, en de gangbare classificatiesystemen.
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 onze retrospective benadering onderzoeken. Deze pagina dient als naslagwerk bij deze gids: hierin wordt het gehele onderwerp systematisch uiteengezet. Als u liever met het verhaal begint, start dan bij de inleiding van de handleiding en kom daarna terug.
Waar deze pagina over gaat
Drie zaken, in volgorde: de levenscyclus die een afzonderlijk 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 classificatieschema’s die worden gebruikt om te benoemen wat er mis is gegaan. Lees het van boven naar beneden om te bepalen waar uw team zich bevindt: welke fasen uw tools al bestrijken, welke cyclus u al onder een andere naam uitvoert, en met welke terminologie u bevindingen zou benoemen. Alles hier staat op zichzelf: u hoeft hiervoor noch onze werkwijze, noch onze benamingen, noch ons product over te nemen.
De levenscyclus: zeven fasen, van probleem 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 voorbijgaande aard: de medewerker zoekt een oplossing, de sessie wordt beëindigd 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 te verhelpen. De kloof is meetbaar: circa 90% van de teams registreert agenttrajecten, 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 secundaire medewerker · correctie door een medewerker · 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 het 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 → welke mate van correctie? | cluster + score, vervolgens rangschikken op 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 laat een transcript achter op de schijf 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 lussen) is automatisch maar oppervlakkig: het weet dat, niet waarom. De sterkste opstellingen maken gebruik van een combinatie: telemetrie geeft aan waar u moet kijken, een controlebeurt legt uit waarom.
Fase 2: Instrumentatie
Een agent registreert geen wrijving tenzij er iets is dat deze veroorzaakt. De opties, gerangschikt naar de mate waarin zij afhankelijk zijn van 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 bot), 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 zich bevindt. Een bruikbaar document bevat onderbouwde gegevens (wat er is gebeurd, wat het heeft gekost), is voorzien van één label uit een vaste terminologie zodat documenten later onderling vergelijkbaar zijn, en sluit af met een voorstel voor de volgende stap. Wat betreft de opslaglocatie: elk met een reële afweging: 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 het signaal gaat schuil in de 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 geheugengegevens vormen een benoemd aanvals- en afwijkingsoppervlak (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 records: goedkoop, maar slechts zo goed als de discipline in fase 3); echte pijplijnen combineren beide. Vervolgens is er de frequentie (een geplande doorloop versus het verzamelen aan het einde van elke 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 van de grootste kostenposten voor het team.
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 vluchtig geheugen, bevorder duurzaam leren via versiebeheer. De documentatie van Windsurf/Devin adviseert om terugkerende lessen om te zetten in regels of in AGENTS.md (het bestand met permanente instructies dat agenten lezen) in plaats van te vertrouwen op automatische geheugenopslag, 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 na 28 dagen volgens het ontwerp: niet-gepromoveerd geheugen moet 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 herstellen.
Fase 6: De cirkel rond maken
De echte toets voor de gehele levenscyclus: neemt dat soort wrijving in de loop van volgende sessies af? Een oplossing die wordt ingediend maar nooit wordt geïmplementeerd, of wel wordt geïmplementeerd maar niets verandert, is slechts schijn. Dit is de voorwaarde van Garg’s Feedback Flywheel en het uitgangspunt van compounding engineering: elke oplossing maakt de volgende werkeenheid eenvoudiger, mits de lus daadwerkelijk wordt gesloten.
De benoemde lussen, per bedrijfsniveau
Binnen dit vakgebied zijn er minstens een half dozijn benamingen voor deze levenscyclus in gebruik. Ze zijn allemaal even goed; niets op deze pagina vervangt een van deze benamingen. De enige manier waarop deze tabel is gesorteerd, is op basis van het niveau waarop elke lus functioneert, en het volgende valt op zodra de tabel is gesorteerd:
| Lus | Loopt op | Sluit de cirkel door |
|---|---|---|
| Lusengineering / Samengestelde engineering | één beoefenaar | persoonlijke regels, aanwijzingen, draaiboeken |
| agent-retro | één sessie | aanpassingen aan instellingen en configuraties per sessie op basis van het transcript |
| Sensoren voor kabelboomontwerp (Thoughtworks) | de structuur van één codebase (het raamwerk rondom het model) | het integreren van ingebouwde feedbackinstrumenten (tests, linters, CI) in de lus van de agent |
| Dromen (Anthropic, OpenAI) | het geheugen van één platform | het tijdens inactieve periodes verzamelen van sessiegeschiedenis in ‘gated memory diffs’, voor de gehele vloot |
| LangSmith Engine / Braintrust Topics | één observability-stack | 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 Flywheel (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 klantenbestand. 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 agenten, meer dan één tool, waarbij de verantwoordelijken voor de oplossingen deel uitmaken van hetzelfde gesprek). Als u een van de bovenstaande cycli uitvoert, ga daar dan mee door; de teamlaag maakt gebruik van de output daarvan, maar concurreert er niet mee.
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 tracés | 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 binnen de samenwerking | 10 labels / 5 groepen; de groep geeft de vaste hoogte aan | werksessies, voor ontwikkelaars en niet-ontwikkelaars; de interbeoordelaarsbetrouwbaarheid is nog niet gemeten: het experiment is momenteel aan de gang en de woordenschat is onderverdeeld in versies 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 mislukt is; laagschema’s (Four-Layer) geven aan waar in de stack; een oorzakenwoordenschat 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 account, dashboard of 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 van labels (MAST’s κ = 0,88 is de maatstaf), terwijl emergente categorieën aansluiten bij uw daadwerkelijke foutenverdeling. Een werkbare middenweg houdt een kleine vaste woordenschat aan voor aggregatie, met open-code 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 (observatietools, 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 ‘Synthesis’ toe op individueel niveau; 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 een overzicht maakt van de verschillende sessies, personen en hulpmiddelen, 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 beoordeling 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 de niet-code-gerelateerde zaken net zo vanzelfsprekend worden doorgestuurd als de code-gerelateerde zaken.
In de rest van deze handleiding worden de verschillende lagen één voor één behandeld: de inleiding vertelt het verhaal op verhalende wijze; in latere hoofdstukken komen het vastleggen van wrijving op het moment zelf, het verzamelen van inzichten over verschillende sessies heen, de hoogtebeslissing en hoe een teamlocatie er in de praktijk uitziet aan bod. Begin waar uw lege rij zich bevindt.
Volgend hoofdstuk: Hoe een goed wrijvingsrapport eruitziet gaat in op het vastleggen op het moment zelf, de labels voor de onderliggende oorzaken en de regels voor het niet-loggen.