Waar moet de oplossing worden doorgevoerd?

Twee teams, dezelfde wrijving, een ander kwart

Twee teams beginnen allebei met het bijhouden van de problemen waarmee hun AI-agenten te maken krijgen: de onduidelijke verzoeken, de verouderde documentatie, de onbetrouwbare tools en de herhalingen.

Het eerste team lost alles op het meest voor de hand liggende niveau op. Elke terugkerende ergernis leidt tot een snelle aanpassing of een notitie ter herinnering; alles wat omvangrijker is, wordt een nieuwe alinea in het contextbestand. Drie maanden later draaien hun agents op omvangrijke instructies die niemand van begin tot eind doorleest, en de frictie die ertoe deed (het korte sjabloon dat de reikwijdte onbepaald laat, het advertentieaccount waarvan de structuur elke sessie in de weg staat) is er nog steeds, omdat geen enkele snelle aanpassing dit kan verhelpen.

Het tweede team stelt per patroon één extra vraag: waar hoort deze oplossing eigenlijk thuis? De cluster „agenten blijven gissen naar onze doelgroep” leidt tot een aanpassing in de manier waarop opdrachten worden uitgelegd: een procesverbetering, overeengekomen tijdens een teamvergadering. De cluster „verouderd runbook“ leidt tot een aanpassing in de documentatie met een verantwoordelijke. De eenmalige eigenaardigheid wordt een aantekening ter herinnering en niets meer dan dat. Drie maanden later zijn hun instructiedocumenten korter dan toen zij begonnen, en de categorieën van knelpunten die zij hebben verholpen, vertonen een dalende trend.

Het verschil zit hem niet in de discipline bij het bijhouden van gegevens. Beide teams hebben gegevens bijgehouden. Het verschil is een vraag over de route die het eerste team nooit heeft gesteld.

De belangrijkste beweging: wrijvingspunten op hoogte

Wanneer een door AI ondersteunde sessie op weerstand stuit, wijst de onderliggende oorzaak naar een niveau waarop de duurzame oplossing te vinden is. Wij noemen dit de hoogte van de oplossing; de beschikbare hoogtes variëren van tijdelijk tot structureel:

geheugen → vaardigheid/aanwijzing → omgeving en configuratie → documentatie → het werkmateriaal zelf → proces/werkstroom → toeleveringsproduct of leverancier

Door het probleem concreet te benoemen, verandert een klacht in een oplosbare kwestie. „De medewerker heeft de biedstrategie weer verkeerd toegepast” is een klacht. „De beslissing over de biedstrategie is nergens vastgelegd waar de medewerker deze kon vinden: een aanpassing in de documentatie, en hier is het runbook waarin deze thuishoort” is een werkitem met een duidelijk aandachtspunt.

Een verkeerde inschatting van de reikwijdte leidt tot problemen op twee fronten. Under-targeting, een persoonlijke notitie die in feite een ontbrekend teamdocument vervangt, betekent dat de wrijving zich herhaalt voor iedereen behalve uzelf: een herhalingslast voor de rest van het team. Notities die op die manier al verloren zijn gegaan, kunnen worden teruggewonnen door middel van een ‘geheugenoogst’ binnen het hele team. **Over-targeting (een nieuwe vaardigheid voor een eenmalige taak, nog een alinea in een reeds overvol contextbestand) vormt een onderhoudslast voor het artefact; het vakgebied heeft de anti-patronen treffend benoemd: vaardigheidsverspreiding (16→48 vaardigheden in 15 dagen: “Vaardigheden toevoegen is eenvoudig. … Het beheer is het moeilijke deel.”) en contextbestand-opblazing (“een geheugenbestand dat niet meer wordt gelezen”, volgens deze veldnotitie). De leveranciers zijn vanuit de andere richting tot dezelfde ontwikkeling gekomen: het belang van kortstondige geheugens verminderen en duurzaam leren bevorderen via versiebeheer: Windsurf/Devin („schrijf het op als een regel of voeg het toe aan AGENTS.md… in plaats van te vertrouwen op automatisch gegenereerde Memories”, documentatie), OpenAI Codex (“wanneer Codex tweemaal dezelfde fout maakt, vraag het dan om een retrospectieve evaluatie en werk AGENTS.md bij”, best practices), de opzettelijke vervaltermijn van 28 dagen voor Copilot-geheugen.

De sector is dus op de hoogte van beide storingsvormen. Wat tot nu toe ontbrak, was een instrument voor het omleiden van het verkeer.

Een vaste woordenschat die de weg wijst

Ons werkvoorstel: koppel aan elke vastgestelde wrijving precies één onderliggende oorzaak uit een vaste lijst van tien termen, verdeeld over vijf groepen: klein genoeg om in het hoofd te onthouden, gericht op oorzaken in plaats van symptomen, en bewust onafhankelijk van specifieke instrumenten en vakgebieden:

• Briefing: ambiguous-instruction, missing-context, incorrect-context, changed-requirements
• Documentatie: missing-documentation, incorrect-documentation
• Werkmateriaal: work-material-friction
• Gereedschap: missing-access-or-tool, environment-friction
• Agent: agent-error

De groep fungeert als routeringssleutel. Zodra een bevinding is gelabeld, is deze al voor de helft gerouteerd:

Groepsdominant	De oplossing bevindt zich doorgaans op	Typische artefacten
Informatiebijeenkomst	proces (de wijze waarop opdrachten worden doorgegeven) of een blijvend geheugen	sjabloon voor een korte samenvatting, checklist voor de startbijeenkomst, archiefmap
Documentatie	documenten	README, runbook/SOP, contextbestand, specificatie
Werkmateriaal	het materiaal zelf	code: de herstructurering waar de wrijving steeds op wijst; niet-code: de herstructurering van het account, het forum of de sjabloon
Gereedschap	environment/config, of upstream	instellingen, MCP-configuratie, toegangsvergunning, leveranciersbon
Agent	aanwijzing, vaardigheid of veiligheidsmaatregel	vaardigheid bewerken, koppelen, evalueren

Eerst even een opmerking ter verduidelijking: de groepen zijn vernoemd naar hun fix-bestemmingen, dus de stelling dat „het label de fix gedeeltelijk bepaalt” is per definitie waar; het gaat hier om een ontwerpkeuze en niet om een empirische bevinding. De onderliggende empirische bewering is dat labels op het moment van vastlegging nauwkeurig en consistent zijn, en dat is precies wat wij nog niet hebben gemeten (meer hierover hieronder).

De tabel wijst een oplossing een eerste adres toe, en herhaling kan deze verplaatsen. Wanneer er na een aanpassing in de documentatie of het contextbestand opnieuw problemen optreden, werkt de tekst waarschijnlijk niet. Verplaats de correctie naar een vangrail: een hook of een CI-controle, die ervoor zorgt dat de correctie wordt doorgevoerd, ongeacht of iemand deze leest of niet. Dit is dezelfde redenering als bij het kiezen van een capture-trigger: een conventieregel is afhankelijk van het feit of iemand deze onthoudt, terwijl een hook dat niet is.

Let goed op wat hieronder valtwork-material-friction, want juist hier ontleent de terminologie haar claim dat zij vakgebiedonafhankelijk is. In code gaat het om technische schuld: de module waar elke sessie over struikelt. Buiten de code is het net zo reëel. Stelt u zich een marketingteam voor waarvan de medewerker een Google Ads-account controleert dat door opeenstapeling is gegroeid: drie generaties naamgevingsconventies, gepauzeerde campagnes die niemand durft te verwijderen, zoekwoorden die in overlappende advertentiegroepen zijn gedupliceerd. Elke sessie besteedt de medewerker zijn eerste tijd aan het reconstrueren welke campagne wat omvat, en elke aanbeveling gaat gepaard met een voorbehoud. Geen enkele snelle oplossing lost dit op; geen enkele notitie biedt uitkomst voor de volgende persoon. Het label is work-material-friction, altijd gekoppeld aan het concrete materiaal dat wordt genoemd (dit account), en de hoogte is het materiaal zelf: de herstructurering waar de wrijving steeds naar verwijst. Hetzelfde patroon komt voor in verwarde spreadsheets, rommelige CMS-sjablonen en bibliotheken met ondersteunende macro’s; een door een programmeur gevormde lus kan deze nergens onderbrengen.

Waarom ‘vast’ in plaats van ‘opkomend’? Omdat de taxonomie voor een team een coördinatie-instrument is, en geen classificatieoefening. „Dezelfde wrijving gedurende acht sessies is een procesprobleem“ geldt alleen als alle acht sessies dit op dezelfde manier hebben aangeduid; beweringen over de verdeling vereisen een stabiele noemer; en trendlijnen („neemt de wrijving bij de briefing af sinds wij het briefingsjabloon hebben aangepast?“) zijn alleen houdbaar als een label in maart en juli hetzelfde betekent. Emergentie-categorieën, waarbij iedereen zijn eigen codering hanteert, zijn op zichzelf de juiste keuze, maar binnen een team verschillen ze per persoon, en er vindt geen aggregatie plaats zonder een afstemmingsstap waarvoor niemand verantwoordelijk is. Wij houden de motor voor het ontstaan van categorieën op twee plaatsen draaiende: een op bewijs gebaseerde toelichting onder elk label, en een periodieke herziening van de terminologie waarbij de verzamelde toelichtingen de labels aan een stresstest onderwerpen. De terminologie kent verschillende versies; deze is ontworpen om op basis van bewijs te veranderen, niet om verdedigd te worden.

Wat er al bestaat, eerlijk vergeleken

Wij hebben de classificatiesystemen voor mislukkingen niet bedacht, en de bestaande systemen voldoen prima aan hun doel.

MAST (arXiv 2503.13657) is de standaardtaxonomie: 14 faalmodi in 3 categorieën, afgeleid uit 150 door deskundigen onderzochte traces en gevalideerd aan de hand van een corpus van meer dan 1600 voorbeelden, met een sterke overeenstemming tussen annotatoren (κ = 0,88). Deze taxonomie classificeert de wijze waarop multi-agent systemen falen; zij is ontwikkeld voor onderzoek en benchmarking, en komt qua vakgebied het dichtst bij de onze, maar verschilt qua onderwerp: wij classificeren de oorzaken van wrijving in de samenwerking tussen mens en agent.

De foutenanalyseschool, de evaluatiemethodologie van Husain & Shankar (FAQ over evaluaties, januari 2026), stelt het tegenovergestelde van een vaste lijst: categorieën „moeten voortkomen uit waargenomen foutpatronen… niet uit vooraf vastgestelde classificaties van zoekopdrachten”, en het open interpreteren van uw eigen traces is „de belangrijkste activiteit bij evaluaties”. Wij zijn van mening dat zij gelijk hebben op individuele schaal en dat de verhouding zich omkeert op teamschaal, om de hierboven genoemde redenen van aggregatie. Hun interpretatiediscipline vormt in ons voorstel hoe dan ook de basis; dat is wat de bewijsnotities inhouden.

Rondom deze pijlers: de vierlaagse taxonomie (Greyling, mei 2026) classificeert welke laag van de stack heeft gefaald, waarbij slechts ~9,9% van de mislukkingen wordt toegeschreven aan de redenering van het model: de meeste storingen zijn problemen met de ‘harness’ (de ‘harness’ is de steiger rondom het model), en daarom is ons agent-errorlabel een residu, dat alleen wordt gebruikt wanneer de invoer adequaat was (de ‘harness-engineering’-school verwerpt expliciet de standaardpraktijk om de schuld bij de agent te leggen, en richt zich op het repareren van de ‘harness’ in plaats van de agent: Osmani, Agent Harness Engineering). TraceProbe classificeert acties voor foutafhandeling in traces. Garg’s Feedback Flywheel verzamelt vier soorten signalen in teamartefacten, het raamwerk waarin het onze is ingebed: zijn context ≈ onze briefing- en documentatiegroepen; zijn ‘failure arm’ is wat onze taxonomie ontleedt. Factory Signals classificeert symptomen van sessies in automatisch aangemaakte tickets; Braintrust Topics is het product van de emergente school, dat uw traces dagelijks opnieuw groepeert.

Twee objectieve interpretaties van die vergelijking. Ten eerste classificeren de meeste van deze benaderingen symptomen, lagen of bestemmingen; de onze classificeert oorzaken, en dat is precies wat het label tot een routeringssleutel maakt, en dat is de feitelijke bewering van originaliteit, voor zover die er is. Ten tweede, en nog belangrijker: MAST heeft de betrouwbaarheid van de labels gemeten en wij niet. De interbeoordelaarsbetrouwbaarheid van onze tien labels is niet gemeten, en wij beschouwen dat als een voorwaarde, niet als een voetnoot: het experiment (waarbij onafhankelijke beoordelaars dezelfde echte inzendingen blind labelen, waarbij de mate van overeenstemming wordt gerapporteerd, ongeacht de uitkomst) is momenteel gaande met inzendingen uit onze eigen live-proef, met de κ-waarde van MAST (0,88) als maatstaf. Totdat de resultaten bekend zijn, is deze taxonomie een werkvoorstel met labels in verschillende versies, en geen gevalideerd instrument. Wij vertellen u dit liever zelf dan dat u er zelf achter komt.

Wij staan ook achter alle reeds actieve loops: Loop Engineering, Compound Engineering, agent-retro, AGENTS.md-retrospectieven, geheugensystemen van leveranciers en geautomatiseerde sessierapporten. Behoud ze allemaal; niets hier vervangt ze.

Waarom hoogte een teamkwestie is

Dit is de gemeenschappelijke tekortkoming van die bestaande processen: ze zijn vrijwel allemaal ‘solo’ (één ontwikkelaar en diens agent, of één leverancier en zijn ‘vloot’). En uit de eigen cijfers van de sector blijkt dat de kostbare stap niet het monitoren is: ~90% van de teams registreert agenttraces, maar slechts ~37–52% evalueert deze systematisch (LangChain State of Agent Engineering, juni 2026). De onbenutte laag is de synthese op teamniveau, en juist daar begint het overzichtsvermogen van belang te worden, om twee redenen.

Door aggregatie worden prioriteiten opnieuw gewogen. Wat voor de ene persoon tien minuten ergernis is, is voor anderen slechts ruis; niemand lost dit rationeel gezien op. Hetzelfde label dat in acht sessies en bij vijf personen wordt gebruikt, vormt een van de grootste kostenposten voor het team, en alleen het geaggregeerde overzicht maakt dit zichtbaar. Aggregatie is ook het resultaat van het vaste vocabulaire: de tellingen kloppen alleen als iedereen dezelfde labels heeft gebruikt.

De hoogste niveaus zijn in handen van het team. Een individu kan zijn eigen geheugen, aanwijzingen en configuratie aanpassen. Maar proceswijzigingen, afwegingen tussen verschillende tools, budgetten voor tooling en escalaties naar hogere niveaus – de niveaus waarop de grootste terugkerende wrijving zich doorgaans voordoet – zijn beslissingen die geen enkel individu in zijn eentje kan nemen. Dit is ook de reden waarom wij van mening zijn dat er bij synthese altijd plaats blijft voor menselijke inbreng, hoe goed de modellen ook worden: de aanpassingen komen terecht in artefacten waarvoor mensen verantwoordelijk zijn en verantwoording moeten afleggen: opdrachten, processen, budgetten, teamafspraken. Dat is een stelling over organisatorische bevoegdheid, niet over de capaciteiten van het model. En het is een rol in de beslissingsketen, geen poort in de pijplijn: systemen moeten vrijelijk detecteren, registreren, clusteren en ontwerpen; mensen voegen het oordeel over de verdere afhandeling toe en dragen de verantwoordelijkheid.

Het vergelijken van bijdragen van verschillende personen en repositories levert ook lessen op die elkaar tegenspreken. Vervang in plaats van overschrijven: de nieuwe les wordt toegevoegd als een gedateerd bericht dat naar de oude verwijst, en de oude blijft leesbaar, zodat niemand later stilletjes opnieuw tot de verkeerde conclusie komt. Om tussen beide te kiezen, controleert u eerst de herkomst (bewijs uit de eerste hand weegt zwaarder dan een les die alleen maar is herhaald), en vervolgens de actualiteit, door de daadwerkelijke tijdstempels te bekijken. Als geen van beide uitsluitsel geeft, markeert u het paar als onopgelost in plaats van een winnaar op te dringen. Controleer ook de reikwijdte. In een van onze repositories stond een les waarin werd gezegd dat u nooit een symlink naar de werkboom mocht makennode_modules; in een andere stond dat u dit wel moest doen, anders zou de build mislukken. Beide waren waar binnen hun eigen repository. Een later gedeelde oplossing, een kopie met een harde link, werkte in beide gevallen, waardoor de les over de symlink werd vervangen.

Als uw team al een bijeenkomst voor voortdurende verbetering organiseert, past dit daar prima in: het totaalbeeld van de wrijving wordt gepresenteerd, het team vraagt zich af „waar valt elke oplossing onder?“, en elk patroon krijgt een prioriteitsniveau en een verantwoordelijke toegewezen. Het is geen nieuw ritueel, maar gewoon een retrospectieve met betere input. ML-ingenieurs noemen dit de „foutanalyse“; teams noemen de bijeenkomst een „retro“.

Wat zou ons van gedachten doen veranderen?

Aangezien dit een discussienota is, volgen hier de punten waarover wij oprecht twijfels hebben:

• Betrouwbaarheid. Indien uit het interbeoordelaarsonderzoek blijkt dat de overeenstemming onvoldoende is, zijn de grensregels (of de labels zelf) onjuist, en zullen wij deze onder het versienummer herzien in plaats van ze te verdedigen.
• Omvang. Het aantal van tien labels is overgenomen, niet afgeleid. MAST telt er 14; Four-Layer telt er 4. Onze labelverdeling na een kwart van de daadwerkelijke invoergegevens vormt het bewijs dat dit aantal handhaaft of bijstelt.
• Ontbrekende modi. Wrijving tussen agents (verlies bij de overdracht tussen subagenten, storingen in de coördinatie) wordt momenteel onder [ ] geschaardenvironment-friction; in de praktijk kunnen zich situaties voordoen die een eigen categorie vereisen.
• Reikwijdte van niet-codegerelateerde beoordelingen. Wij bepalen de reikwijdte van beoordelingen op basis van de plaats waar de aanpassingen zouden worden doorgevoerd: de repository voor het merendeel van het ontwikkelingswerk; „account”, „werkruimte” of „opdracht” daarbuiten. Deze niet-codegerelateerde afbakeningen zijn voorstellen die wij in de praktijk met echte teams willen toetsen.
• Haalbaarheid op het moment van vastlegging. Kunnen drukbezette teams oorzaken direct op dat moment labelen, of moet het labelen pas bij de evaluatie plaatsvinden? Teams die dit in de praktijk uitproberen, zouden hier sneller uitsluitsel over kunnen geven dan wij op basis van onze theorieën.

Mocht u een willekeurige versie van deze lus uitvoeren (opkomende categorieën, een leverancierspijplijn, een eenvoudige spreadsheet), dan horen wij graag waar de routeringstabel niet meer werkt. Vooral als u ons een patroon van weerstand kunt laten zien dat helemaal niet naar een hoogte wijst: ai-discussion@teamretro.com.

---

Volgend hoofdstuk: Het rapport bestaat. De ruimte niet.: waarom het doorgeven van de oplossingen een teambeslissing is, en wat het team doet wanneer het frictierapport binnenkomt. Onderdeel van de handleiding voor retrospectieven van AI-agenten.