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 vragen, de verouderde documentatie, de onbetrouwbare tools, 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 wrijving die ertoe deed — het korte sjabloon dat de reikwijdte onduidelijk laat, het advertentieaccount waarvan de structuur elke sessie in de weg staat — is er nog steeds, omdat geen enkele kleine 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 notitie 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 opgelost, vertonen een dalende trend.

Het verschil zit niet in de nauwkeurigheid van de registratie. Beide teams hebben hun gegevens geregistreerd. Het verschil betreft een vraag over de route die het eerste team nooit heeft gesteld.

De belangrijkste beweging: wrijvingspunten op hoogte

Wanneer een door AI ondersteunde sessie vastloopt, 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 afstemming op de doelstelling 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. Te hoge doelstellingen (een nieuwe vaardigheid voor een eenmalige taak, nog een alinea in een toch al overvol contextbestand) vormen een onderhoudslast voor het artefact; het vakgebied heeft de antipatronen nauwkeurig benoemd: vaardigheidsverspreiding (16→48 vaardigheden in 15 dagen: “Vaardigheden toevoegen is eenvoudig. … Het beheer is het moeilijke deel.”) en een opgeblazen contextbestand (“een geheugenbestand dat niet meer wordt gelezen”, volgens deze veldnotitie). De leveranciers zijn vanuit de andere richting tot dezelfde gradatie gekomen — het tijdelijke geheugen naar de achtergrond verplaatsen en duurzaam leren via versiebeheer bevorderen: Windsurf/Devin (“schrijf het op als een regel of voeg het toe aan AGENTS.md… in plaats van te vertrouwen op automatisch gegenereerde herinneringen”, documentatie), OpenAI Codex (“wanneer Codex dezelfde fout twee keer maakt, vraag het dan om een retrospective en werk AGENTS.md bij”, best practices), de bewuste vervaldatum van 28 dagen van het 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, archiefbestand
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, leveranciersticket
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 — een ontwerpkeuze, geen 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).

Let goed op watwork-material-frictionhieronder valt, 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 de 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 kern is het materiaal zelf: de herstructurering waar de wrijving steeds op wijst. 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 ‘emergent’? Omdat de taxonomie voor een team een coördinatie-instrument is, en geen classificatieoefening. “Dezelfde wrijving gedurende acht sessies is een procesprobleem” klopt alleen als alle acht sessies dit op dezelfde manier hebben aangemerkt; 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. Emergent gecodeerde 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 grondige toets 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 voor het doel waarvoor ze zijn bedoeld.

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 en is ontwikkeld voor onderzoek en benchmarking — qua vakgebied het dichtst bij het onze, maar met een ander doel: wij classificeren de oorzaken van wrijving in de samenwerking tussen mens en agent.

De foutenanalyseschool, de evaluatiemethodologie van Husain & Shankar (evals FAQ, januari 2026), stelt het tegenovergestelde van een vaste lijst: categorieën “moeten voortkomen uit waargenomen foutpatronen… niet uit vooraf vastgestelde classificaties van zoekopdrachten,” en een open interpretatie van uw eigen traces is “de belangrijkste activiteit bij evaluaties.” Wij zijn van mening dat zij gelijk hebben op individuele schaal, maar 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 in welke laag van de stack een storing is opgetreden, waarbij slechts ~9,9% van de storingen wordt toegeschreven aan de redenering van het model: de meeste storingen zijn problemen met het harnas (het harnas is de steiger rondom het model), en daarom is onsagent-errorlabel een residu, dat alleen wordt gebruikt wanneer de invoer adequaat was (de ‘harnas-engineering’-school verwerpt expliciet de standaardaanpak waarbij de agent de schuld krijgt — repareer het harnas, niet 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 — dat is 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 op zichzelf staand (één ontwikkelaar en diens agent, of één leverancier en zijn portfolio). En uit de eigen cijfers van de sector blijkt dat de kostbare stap niet het monitoren is: ongeveer 90% van de teams registreert agenttraces, maar slechts ongeveer 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, en wel om twee redenen.

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

De hoogste niveaus zijn voorbehouden aan 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 alleen kan nemen. Dit is ook de reden waarom wij van mening zijn dat er altijd een menselijke rol in de synthese zal blijven bestaan, 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 beoordelingsvermogen toe en dragen de verantwoordelijkheid.

Als uw team al een bijeenkomst voor continue verbetering organiseert, past dit daar prima in: het totaalbeeld van de wrijvingspunten wordt gepresenteerd, het team vraagt „waar wordt elke oplossing toegepast?“, en elk patroon krijgt een prioriteitsniveau en een verantwoordelijke toegewezen. Geen nieuw ritueel — een retrospective met betere input. ML-ingenieurs noemen dit de analyse van leesfouten; 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 aanpast.
• Ontbrekende modi. Wrijving tussen agenten (verlies bij de overdracht tussen subagenten, storingen in de coördinatie) valt momenteel onder environment-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 vastleggen. Kunnen drukbezette teams de oorzaken direct op dat moment labelen, of moet het labelen pas tijdens de evaluatie plaatsvinden? Teams die dit in de praktijk uitproberen, zouden hier sneller uitsluitsel over geven dan wij met 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 goed functioneert. Vooral als u ons een wrijvingspatroon kunt laten zien dat helemaal niet naar een hoogte wijst: ai-discussion@teamretro.com.

---

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