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 continue verbetering die teams doorlopen; AI-ondersteund werk is een nieuw gebied dat wij vanuit het perspectief van onze retrospective benadering nader 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 gids en kom daarna terug.
Waar deze pagina over gaat
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 classificatieschema’s 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 lus u al onder een andere naam uitvoert, en welke terminologie u zou gebruiken om bevindingen te benoemen. Alles hier staat op zichzelf: niets ervan vereist dat u onze werkwijze, onze benamingen of ons product overneemt.
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 onbetrouwbare tool), is dat signaal van korte duur: 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 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 | — |
| 1 · Detectie | Hoe wordt wrijving waargenomen? | zelfcontrole · beoordeling door een tweede persoon · correctie door een medewerker · telemetrie | trace-beoordeling, foutanalyse |
| 2 · Instrumentatie | Hoe weet de agent dat hij dit moet volgen? | vaardigheid · haak · conventie · opdracht | — |
| 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 | — |
| 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 omgeving waarin de agent wordt uitgevoerd. Een lokale CLI-agent slaat een transcript op de 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 lussen) 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 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 ze afhankelijk zijn van het geheugen van het model: een vaardigheid (een expliciete, overdraagbare procedure die op 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 weinig genuanceerd), een conventie (een instructie in een contextbestand: geen infrastructuur vereist, 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 verwijzingen naar bewijsmateriaal (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 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 ruis), tickets (actiegericht en zichtbaar voor het team, maar omvangrijk per item), of getagde commits en PR’s, bijvoorbeeld eenwork-material-frictionlabel 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 systemen waarop agenten later vertrouwen: door agenten geschreven geheugen vormt een benoemd 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. Het verzamelen is waar de waarde naar voren komt, 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 — Windsurf/Devin’s documentatie adviseert om terugkerende lessen om te zetten in regels of 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 lezing 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 toets 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 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 wordt deze levenscyclus onder minstens een half dozijn verschillende benamingen gebruikt. Ze zijn allemaal even goed; niets op deze pagina is bedoeld ter vervanging van 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 / Compound 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 ondersteunende 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 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 agent-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 nog eens: éé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 daadwerkelijk in praktijk te brengen. 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.
De classificatiesystemen
Om wrijving te clusteren hebt u categorieën nodig, en de schema’s van de verschillende vakgebieden classificeren verschillende zaken; het zijn niet zozeer concurrenten als wel instrumenten die gericht zijn op verschillende vraagstukken:
| 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 analyseren van uw traces is „de belangrijkste activiteit bij evaluaties” |
| Vierlaags (Grijling) | welke laag van de stack is uitgevallen | 4 lagen | samenvatting van storingsmeldingen uit de praktijk; ~9,9% van de storingen wordt toegeschreven aan de redenering van het model |
| 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 met betrekking tot 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 versies en kan worden herzien |
agent-errorTwee opmerkingen bij de tekst. 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 oorzakenvocabulaire geeft aan waarom, en dat is wat een label in staat stelt om de oplossing gedeeltelijk zelf te sturen (eenwork-material-frictionbevinding wijst op het materiaal zelf — technische schuld in de code, of een verwarde rekening, 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 bij het toekennen van labels (MAST’s κ = 0,88 is de maatstaf), terwijl emergente categorieën aansluiten bij uw daadwerkelijke verdeling van mislukkingen. 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 -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 afdoet met „wachten op de volgende versie“; repareer in plaats daarvan het harnas (Osmani, Agent Harness Engineering). De vierlagenanalyse schrijft slechts ~9,9% van de mislukkingen toe aan de redenering van het model.
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 Dreaming-stijl, 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 daarbij 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 de oplossingen terechtkomen, en zorg ervoor dat de niet-code-gerelateerde zaken net zo natuurlijk worden doorgestuurd als de code-gerelateerde zaken.
In de rest van deze handleiding worden de verschillende lagen één voor één behandeld: de opener 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 — het vastleggen van het moment, de labels voor de onderliggende oorzaken en de regels voor wat nooit mag worden geregistreerd.