# Drift: de afstand tussen wat je getoetst hebt en wat er draait Drift is de afstand tussen wat je ooit getoetst hebt en wat er nu draait. Zeven soorten in AI-systemen, wat ze delen, en hoe je die afstand meetbaar en kleiner maakt. - Bron: https://koenholman.nl/onderzoek/drift-is-een-afstand/ - Auteur: Koen Holman - Rubriek: Agents & pijplijnen - Gepubliceerd: 3 september 2026 ## In het kort - Drift is de afstand tussen wat je ooit getoetst hebt en wat er nu draait, en die afstand ontstaat zonder dat iemand iets verandert aan wat je zelf beheert. - De term komt uit het leren op datastromen, maar hetzelfde patroon zit in een model achter een API, in een agent die lang doorwerkt, in instructiebestanden en in de pijplijn eromheen. - In elke variant ontbreekt hetzelfde: een bewaard vertrekpunt, een meting van de afstand, en een signaal dat rood wordt terwijl alles gewoon blijft werken. - Remmen begint niet met minder verandering maar met verandering die langs een poort gaat: pin op inhoud, meet tegen een vaste referentie, en laat elke kopie een datum dragen. --- **Figuur.** Een tijdlijn van links naar rechts. Links een vast punt met het label 'getoetst', waar een horizontale streeplijn uit vertrekt: wat ooit is vastgesteld. Vanuit datzelfde punt loopt een tweede, doorgetrokken lijn die langzaam omhoog wegbuigt: wat er nu draait. Rechts, bij het label 'nu', staat tussen de twee lijnen een verticale balk met het woord 'drift' — de afstand die zonder eigen wijziging is ontstaan. Onder de tijdlijn staan vier dozen die benoemen waar die tweede lijn vandaan kan komen: de data die binnenkomt, het model achter de API, de opdracht en de instructies die een agent leest, en de machinerie eromheen met haar afhankelijkheden. Drift is geen gebeurtenis maar een afstand: het verschil tussen het punt waarop iets is getoetst en de staat waarin het nu draait. Die afstand groeit zonder dat er in de eigen repo iets verandert, en is alleen te zien als het vertrekpunt bewaard is gebleven. Het woord *drift* duikt in AI-werk op in steeds nieuwe combinaties: datadrift, conceptdrift, modeldrift, promptdrift, goal drift, configuratiedrift. Dat zijn geen zeven verschijnselen die toevallig hetzelfde woord kregen. Het is één verschijnsel op zeven plekken, en wie het één keer scherp heeft, herkent het overal: iets waarvan jouw systeem afhangt is verschoven, jouw eigen code is niet veranderd, en niets is rood geworden. Dit stuk doet drie dingen. Het haalt de term terug naar waar hij vandaan komt, loopt de soorten langs met per soort één bron en één gemeten geval, en zegt daarna wat ik zou doen om drift zichtbaar en kleiner te maken. Dat laatste is nadrukkelijk mijn interpretatie, en die staat apart gemarkeerd. Drift is geen fout die iemand maakt maar een afstand die ontstaat — en je kunt hem alleen meten als je het vertrekpunt hebt bewaard. ## Waar het woord vandaan komt De term is ouder dan taalmodellen. In het leren op datastromen heet het *concept drift*, en het overzichtsartikel van [Gama en collega's (2014)](https://mpechen.win.tue.nl/publications/pubs/Gama_ACMCS_AdaptationCD_accepted.pdf) geeft er een definitie aan die weinig ruimte laat: er is drift tussen twee tijdstippen als de gezamenlijke verdeling van invoer en doelvariabele op het ene tijdstip niet gelijk is aan die op het andere. In hun notatie: `p_t0(X, y) ≠ p_t1(X, y)`. Meer is het niet. Geen fout, geen bug, geen schuldige — een ongelijkheid tussen toen en nu. Het artikel splitst dat in tweeën, en die splitsing is de nuttigste die er is. **Echte drift** (*real concept drift*) is een verandering in de relatie tussen invoer en uitkomst: dezelfde invoer betekent nu iets anders. **Virtuele drift** is een verandering in de invoer zelf, terwijl de relatie hetzelfde blijft: er komen andere gevallen binnen, maar wat ze betekenen is niet verschoven. Het verschil doet ertoe voor de meting. Virtuele drift is te zien zonder ooit een echte uitkomst te kennen — je vergelijkt alleen invoerverdelingen. Echte drift niet: daar heb je de ware labels voor nodig, en die komen in de praktijk met vertraging of helemaal niet. De auteurs benoemen die vertraging expliciet als een variant van de opzet, geen randgeval. Ze tekenen ook hoe drift zich in de tijd gedraagt: plotseling, geleidelijk in kleine stappen, met een overgangsperiode waarin oud en nieuw door elkaar lopen, of terugkerend. En één ding dat expres *geen* drift is: een uitschieter. Eén afwijkend punt is geen verschuiving. Dat onderscheid is de reden dat drift zo lastig te vangen is met een gewone alarmdrempel — een drempel vuurt op één slecht geval, drift zit in de trend. Een jaar later beschreven [Sculley en collega's (2015)](https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf) vanuit Google waarom dit in productie zo duur is. Hun observatie is kort: de buitenwereld is zelden stabiel, en die achtergrondsnelheid van verandering is een doorlopende onderhoudskost. Ze noemen daarbij twee mechanismen die in de rest van dit stuk steeds terugkomen. *Onstabiele data-afhankelijkheden*: een signaal dat je als invoer gebruikt en dat door een ander systeem wordt geproduceerd, kan van gedrag veranderen zonder dat jij iets doet — zeker als het uit een ander model komt dat zelf bijgewerkt wordt. En *configuratieschuld*: configuratie wordt behandeld als bijzaak, wordt niet getest, en kan in een volwassen systeem meer regels beslaan dan de code zelf. ## Zeven plekken, één patroon Hieronder de soorten drift zoals ze in AI-systemen voorkomen. Per soort staat wat er verschuift, wie het beheert, en één gemeten geval uit een primaire bron. De volgorde loopt van de klassieke betekenis naar de plekken waar het woord de laatste twee jaar is gaan opduiken. ### 1. Datadrift — de invoer verandert De virtuele drift van Gama: de verdeling van wat er binnenkomt verschuift. Andere gebruikers, een ander seizoen, een sensor die vervangen is. Het model is niet slechter geworden; het krijgt vragen waar het niet op getoetst is. Dit is de best meetbare soort, want je hebt er geen uitkomsten voor nodig — een vergelijking van de invoerverdeling van nu met die van het toetsmoment volstaat, mits die van het toetsmoment bewaard is. ### 2. Conceptdrift — de betekenis verandert De echte drift: dezelfde invoer hoort nu bij een andere uitkomst. Het voorbeeld dat Gama gebruikt is een lezer van een nieuwsstroom wiens interesses verschuiven terwijl de stroom zelf hetzelfde blijft. In een handelssysteem is het een signaal dat vroeger iets voorspelde en nu niet meer. Dit is de moeilijkste soort om te zien, om de reden hierboven: je ziet hem pas als de ware uitkomsten binnen zijn, en die komen laat. ### 3. Modeldrift — het model achter de naam verandert Hier begint het deel dat specifiek is voor wie een model van een ander gebruikt. [Chen, Zaharia en Zou (2023)](https://arxiv.org/abs/2307.09009) vergeleken de versies van GPT-4 van maart en juni 2023 op dezelfde taken. Op het herkennen van priemgetallen ging de nauwkeurigheid van 84% naar 51%. Dezelfde naam, dezelfde API, dezelfde prompt — een ander antwoord. De auteurs merken op dat wanneer en hoe die modellen bijgewerkt worden, niet transparant is, en dat is de kern: het vertrekpunt lag niet bij de gebruiker. - **84% → 51%** — nauwkeurigheid van GPT-4 op priemgetallen, maart tegenover juni 2023, zelfde vragen - **60 dagen** — minimale aankondigingstermijn vóór Anthropic een model terugtrekt; daarna faalt elk verzoek eraan Of dat je kan overkomen, hangt af van waar de naam naar wijst. Anthropic beschrijft dat in z'n [documentatie over model-ID's](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions) met een onderscheid dat het lezen waard is. Een model-ID is een gepinde momentopname: de gewichten achter dat ID veranderen niet zolang het bestaat, en een nieuwe versie krijgt een nieuw ID. Maar voor oudere generaties bestaan er ook *aliassen*, kortere namen die naar de meest recente gedateerde momentopname wijzen — en die kunnen dus verschuiven. En zelfs bij een gepind ID, schrijft dezelfde pagina, kan de infrastructuur eromheen (routering, classificatie, bemonstering) veranderen en kleine verschillen in waarneembaar gedrag geven terwijl de gewichten gelijk bleven. Het vertrekpunt is dus preciezer te bewaren dan bij Chen's meting, maar niet volledig. En er is een harde variant: het model verdwijnt. Volgens de [deprecatiepagina](https://platform.claude.com/docs/en/about-claude/model-deprecations) krijgt een klant minstens zestig dagen bericht vóór een model wordt teruggetrokken, en falen verzoeken aan een teruggetrokken model daarna. Dat is geen stille drift maar een luide — met een aanloop waarin de gebruikelijke reactie is om naar de aanbevolen opvolger te gaan, en dat is precies het moment waarop drift van soort 3 opnieuw begint, nu bewust. ### 4. Semantische drift — binnen één antwoord Drift kan ook binnen één generatie optreden. [Spataru en collega's (2024)](https://arxiv.org/abs/2404.05411) laten zien dat moderne taalmodellen bij het schrijven van biografieën eerst juiste feiten produceren en daarna wegdrijven naar onjuiste. Ze bouwen een score voor de mate waarin correcte en incorrecte feiten in een tekst van elkaar gescheiden zijn, en vinden dat eerder stoppen de feitelijkheid flink verbetert. De afstand groeit hier niet over weken maar over alinea's, en het vertrekpunt is het begin van hetzelfde antwoord. ### 5. Doeldrift — de agent verliest z'n opdracht Bij agents die lang zelfstandig werken krijgt drift een eigen naam: *goal drift*. [Arike en collega's (2025)](https://arxiv.org/abs/2505.02709) definiëren het als de neiging van een agent om in de tijd af te wijken van het doel dat hij oorspronkelijk kreeg, en meten het door een agent een doel in z'n systeemprompt te geven en hem daarna aan concurrerende druk uit de omgeving bloot te stellen. Hun beste agent hield het doel vrijwel volledig vast over meer dan honderdduizend tokens, maar elk geëvalueerd model vertoonde enige drift — en die nam toe naarmate de context langer werd, samen met de neiging om op patronen te reageren in plaats van op de opdracht. Een verwante meting in gesprekken: [Laban en collega's (2025)](https://arxiv.org/abs/2505.06120) vergeleken dezelfde taken in één beurt en verspreid over meerdere beurten, in ruim tweehonderdduizend gesimuleerde gesprekken. Gemiddeld presteerden de modellen 39% slechter in de meerbeurtige variant. De ontleding is het interessante deel: een klein verlies aan vermogen en een grote toename in onbetrouwbaarheid. Modellen doen vroeg aannames, proberen te vroeg een eindantwoord, en leunen daarna op dat antwoord. Wie eenmaal een verkeerde afslag neemt, komt niet terug. Dat is drift in z'n kleinste vorm: het vertrekpunt is de opdracht van beurt één, en die wordt in beurt vijf niet meer gelezen. ### 6. Instructiedrift — wat het systeem leest, klopt niet meer Dit is de soort die geen eigen paper heeft, en toch de meest voorkomende in werk met agents. Een instructiebestand, een prompt, een grondwet, een lijst met grenzen: tekst die een model leest vóór het iets doet. Die tekst beschrijft het systeem zoals het was toen de tekst geschreven werd. Het systeem beweegt, de tekst niet, en het model volgt de tekst. Sculley beschreef precies dit mechanisme voor configuratie: het wordt als bijzaak behandeld, het wordt niet getest, en niemand ziet het als het achterloopt. Een prompt is configuratie in proza. In een [eerder stuk over contextgebruik](https://koenholman.nl/onderzoek/context-als-eindige-hulpbron/) bleek dat het grootste bestand in het leespad van een agent ook het meest gemuteerde was — en dat is de combinatie waarin instructiedrift het snelst groeit. ### 7. Configuratiedrift — de machinerie schuift onder je vandaan De laatste soort zit niet in het model maar in alles eromheen: afhankelijkheden, workflows, gekopieerde bestanden, drempelwaarden. GitHub's eigen [hardeningdocumentatie](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions) formuleert het voor workflows zonder omwegen: een actie pinnen op een volledige commit-hash is op dit moment de enige manier om hem als onveranderlijke release te gebruiken, want een tag kan verplaatst of verwijderd worden. Een tag is een naam; een hash is inhoud. Wie op een naam pint, vertrouwt dat de naam blijft betekenen wat hij betekende — hetzelfde patroon als een model-alias, en hetzelfde patroon als in het [stuk over MCP-servers](https://koenholman.nl/onderzoek/vertrouwen-bindt-aan-de-naam-niet-de-inhoud/), waar vertrouwen aan een toolnaam bleef hangen terwijl de inhoud veranderde. Sculley's *vaste drempels in dynamische systemen* horen hier ook: een beslisgrens die ooit met de hand is gezet op een model dat inmiddels is bijgewerkt. De drempel staat er nog, het model eronder is anders, en niets meldt dat de twee niet meer bij elkaar horen. > **En de achtste, die de lus sluit** > > Als de uitvoer van een model weer invoer wordt voor het trainen van het volgende, drift niet één systeem maar de hele verdeling. [Shumailov en collega's (2023)](https://arxiv.org/abs/2305.17493) noemen dat *model collapse*: het gebruik van modelgegenereerde inhoud bij het trainen veroorzaakt onomkeerbare defecten waarbij de staarten van de oorspronkelijke verdeling verdwijnen. Ze tonen het bij variational autoencoders, mengmodellen én taalmodellen. Het is drift zonder buitenwereld: het systeem verschuift zichzelf, elke generatie een stukje verder van het vertrekpunt dat niemand meer heeft. ## Wat de zeven delen Leg de zeven naast elkaar en er blijven drie eigenschappen over die ze allemaal hebben. - **Het vertrekpunt ligt niet bij jou, of is niet bewaard.** Een model-alias, een tag, een prompt zonder datum, een opdracht van tien beurten geleden, een trainingsverdeling van vorig jaar. In elk geval is er ooit iets getoetst, en is dat toetsmoment niet vastgelegd als iets waartegen je later kunt vergelijken. - **Er beweegt iets dat jij niet beheert.** Sculley's onstabiele afhankelijkheid: een signaal, een model, een repo van iemand anders. Jouw diff is leeg, en toch is het gedrag anders. - **Niets wordt rood.** Dit is de eigenschap die drift onderscheidt van een storing. Een storing meldt zich; drift werkt gewoon door, alleen anders. Sculley's voorstel voor een detector is daarom geen foutmelding maar een invariant: in een gezond systeem hoort de verdeling van voorspelde labels ongeveer gelijk te zijn aan die van waargenomen labels, en een verschuiving daarin is vaak het eerste teken dat de wereld is veranderd terwijl de trainingsdata dat niet deed. Die derde eigenschap verklaart ook waarom de meeste bestaande controles drift niet zien. Tests toetsen of iets doet wat het deed toen de test geschreven werd — op invoer die toen gekozen is. Ze meten de eigen code tegen een eigen verwachting. Drift zit in de afstand tussen die verwachting en de wereld, en daar kijkt een test niet naar. Sculley zegt het met zoveel woorden: unit- en end-to-end-tests zijn waardevol, maar in een veranderende wereld niet voldoende als bewijs dat een systeem doet wat het moet doen. > **Vanaf hier: mijn interpretatie** > > Alles hierboven is terug te lezen in de bronnen onderaan. Wat nu volgt staat daar niet in: het is wat ik uit die drie gedeelde eigenschappen zou afleiden voor een systeem dat ik zelf beheer. ## Drift zichtbaar en kleiner maken De drie eigenschappen wijzen elk naar een handgreep. Als drift ontstaat doordat het vertrekpunt niet bewaard is, doordat een afhankelijkheid vanzelf beweegt en doordat niets rood wordt, dan is de remedie: bewaar het vertrekpunt, laat de afhankelijkheid alleen langs een poort bewegen, en bouw iets dat rood kán worden. In die volgorde, want de tweede en de derde zijn zinloos zonder de eerste. 1. **Pin op inhoud, niet op een naam.** Een gepind model-ID in plaats van een alias, een commit-hash in plaats van een tag, een bewaarde referentie-uitkomst in plaats van “het werkte toen”. Dit is de goedkoopste stap en de enige die de andere mogelijk maakt: zonder vast vertrekpunt is er niets om tegen te meten. 2. **Laat de pin bewegen, maar alleen langs een poort.** Pinnen zonder mechanisme om te verschuiven is geen veiligheid maar verstarring: binnen weken loop je achter en durft niemand nog de sprong te maken. De vorm die ik zou kiezen is een canary: één plek volgt de nieuwste versie en draait daar de volledige toets op, en pas als die groen is schuift de pin van de anderen — via een wijziging die iemand kan lezen. Zo wordt drift van soort 3 en 7 een beslissing met een diff in plaats van een gebeurtenis zonder. 3. **Meet gedrag tegen een vaste referentie, op een klok.** Een golden set die periodiek draait op dezelfde invoer als bij de toets, een pariteitscheck tussen de verwachte en de werkelijke verdeling, een invariant à la Sculley's voorspellingsbias. Niet omdat elke afwijking erg is, maar omdat een afwijking dan een getal wordt in plaats van een gevoel. Voor conceptdrift, waar de labels laat komen, is dit het enige dat werkt: meet de invoer nu en oordeel over de uitkomst later, maar bewaar allebei. 4. **Geef elke kopie een bron en een datum, of maak er geen.** Elke kopie van tekst, configuratie of een tabel is een driftoppervlak: twee plekken die hetzelfde horen te zeggen en dat na een maand niet meer doen. Waar een kopie onvermijdbaar is, hoort erbij te staan waarvan hij een kopie is en van wanneer, en hoort er een check te bestaan die het verschil meldt. Waar dat niet kan, is één bron met een verwijzing beter dan twee bronnen met een belofte. 5. **Veranker het doel opnieuw naarmate de context groeit.** Voor agents wijzen Arike en Laban dezelfde kant op: drift neemt toe met de lengte van de context, en een verkeerde vroege aanname wordt niet vanzelf gecorrigeerd. De handgreep is dan niet een betere prompt maar een kortere afstand tot het vertrekpunt: de opdracht herhalen bij elke fase, de specificatie consolideren voordat er gebouwd wordt, en een lange taak opknippen in stukken die elk opnieuw bij het doel beginnen. Wat ik expres *niet* zou doen is elke drift bestrijden. Een nieuwer model is vaak beter; een dependency-update dicht een lek; een verschoven invoerverdeling kan gewoon de werkelijkheid zijn. Het doel is niet stilstand maar zicht: dat een verschuiving een moment heeft waarop iemand had kúnnen kijken, en een getal dat zegt hoe groot hij was. Drift die je kunt zien, is een keuze. Drift die je niet ziet, is de enige soort die gevaarlijk is. ## Waar het ophoudt **Vier voorbehouden bij dit stuk** **De indeling in zeven is van mij, niet uit de literatuur.** Gama en collega's onderscheiden twee soorten en vier patronen; de overige soorten hierboven komen uit losse publicaties die het woord elk op hun eigen manier gebruiken. De soorten overlappen: doeldrift is ook een vorm van instructiedrift, en een model-alias is ook configuratie. De indeling is bedoeld om te herkennen, niet om te classificeren. **De cijfers zijn uit specifieke opstellingen.** Het priemgetal-cijfer gaat over twee versies van één model op één taak in 2023, en de auteurs hebben het tussen hun eerste en derde versie zelf bijgesteld. De 39% van Laban komt uit gesimuleerde gesprekken op zes generatietaken. De honderdduizend tokens van Arike zijn de score van hun beste agent in hun eigen evaluatie. Geen van deze getallen is een eigenschap van “taalmodellen” in het algemeen. **De API-gedragingen zijn van één aanbieder, op één datum.** Wat hier over gepinde ID's, aliassen en deprecatietermijnen staat komt uit de documentatie van Anthropic zoals die op 3 september 2026 te lezen was. Andere aanbieders hanteren andere regels, en deze regels kunnen veranderen — wat op zichzelf al een voorbeeld van soort 3 is. **De handgrepen zijn niet gemeten.** De vijf punten onder het kantelpunt volgen uit de gedeelde eigenschappen, niet uit een experiment dat aantoont dat ze werken. Wat er wél is: een systeem waar ik ze zelf op toepas, en de meting daarvan is een apart stuk. ## Bronnen 1. [A Survey on Concept Drift Adaptation](https://mpechen.win.tue.nl/publications/pubs/Gama_ACMCS_AdaptationCD_accepted.pdf) — Gama J, Žliobaitė I, Bifet A, Pechenizkiy M, Bouchachia A · ACM Computing Surveys 46(4), geaccepteerde versie · 2014 2. [Hidden Technical Debt in Machine Learning Systems](https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf) — Sculley D et al. · NIPS · 2015 3. [How is ChatGPT's behavior changing over time?](https://arxiv.org/abs/2307.09009) — Chen L, Zaharia M, Zou J · arXiv:2307.09009, derde versie oktober 2023 · 2023 4. [Model IDs and versioning](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions) — Anthropic · Claude Platform-documentatie, geraadpleegd 3 september 2026 · 2026 5. [Model deprecations](https://platform.claude.com/docs/en/about-claude/model-deprecations) — Anthropic · Claude Platform-documentatie, geraadpleegd 3 september 2026 · 2026 6. [Know When To Stop: A Study of Semantic Drift in Text Generation](https://arxiv.org/abs/2404.05411) — Spataru A, Hambro E, Voita E, Cancedda N · arXiv:2404.05411 · 2024 7. [Technical Report: Evaluating Goal Drift in Language Model Agents](https://arxiv.org/abs/2505.02709) — Arike R, Donoway E, Bartsch H, Hobbhahn M · arXiv:2505.02709 · 2025 8. [LLMs Get Lost In Multi-Turn Conversation](https://arxiv.org/abs/2505.06120) — Laban P, Hayashi H, Zhou Y, Neville J · arXiv:2505.06120 · 2025 9. [The Curse of Recursion: Training on Generated Data Makes Models Forget](https://arxiv.org/abs/2305.17493) — Shumailov I, Shumaylov Z, Zhao Y, Gal Y, Papernot N, Anderson R · arXiv:2305.17493, derde versie april 2024; later in Nature 631 · 2023 10. [Security hardening for GitHub Actions — Using third-party actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions) — GitHub · GitHub Docs, geraadpleegd 3 september 2026 · 2026 ## Toets het op je eigen systeem Laat een systeem zijn eigen driftoppervlak in kaart brengen: elke plek waar iets kan verschuiven zonder dat een eigen wijziging eraan te pas komt. ``` Je gaat het driftoppervlak van dit systeem inventariseren. Drift is hier de afstand tussen wat ooit getoetst is en wat er nu draait — niet een fout die iemand maakt, maar een verschuiving in iets waarvan dit systeem afhangt. Stap 1 — vind de referentiepunten. Zoek elke plek waar dit systeem leunt op iets buiten de eigen repo: modelnamen in code en configuratie, versies van afhankelijkheden en workflows, gekopieerde documenten of tabellen, datasets en drempelwaarden, en instructiebestanden die een agent leest. Noteer per plek: wijst de verwijzing naar een naam die kan verschuiven (een alias, een tag, "latest", een kopie zonder datum) of naar inhoud die vastligt (een gepind ID, een commit-hash, een bewaard resultaat)? Stap 2 — vind de kopieën. Zoek tekst of configuratie die op twee plekken staat en hetzelfde hoort te zeggen: een samenvatting van regels in meerdere bestanden, een changelog die overgenomen is, een lijst die met de hand gesynchroniseerd wordt. Noteer per kopie of er een bron, een datum en een controle bij staat. Stap 3 — vind de detectoren. Welke checks vergelijken de huidige staat met een bewaard vertrekpunt — een golden set, een canary, een pariteitscheck, een versheidsdatum? Welke van de plekken uit stap 1 en 2 heeft géén detector? Dat zijn de plekken waar drift stil blijft. Stap 4 — bij agents: zoek waar het oorspronkelijke doel wordt herhaald of hersteld tijdens een lange taak, en hoe lang de context wordt voordat dat gebeurt. Stap 5 — lever een tabel: plek · wat kan er verschuiven · wie of wat merkt het · na hoeveel tijd. Sorteer op de laatste kolom, langste bovenaan. Voeg geen oordeel toe over of drift erg is; dat is een beslissing, geen meting. ```