Waarom AI-agents QA doorstaan en toch falen in productie

Continu leren wordt de engineeringsdiscipline voor het verbeteren van agents na implementatie, zonder te breken wat al werkte.

Een AI-agent kan elke pre-launch evaluatie doorstaan en toch falen in productie een week later. Dat is geen contradictie. De evaluatieset weerspiegelt wat het team wist te testen voor de lancering. Productie is waar de ontbrekende gevallen opduiken: vreemde formuleringen, ontbrekende context, tool-edge cases, ongeduldige gebruikers, conflicterende beleidsregels en workflows die geen benchmarkontwerper ooit had bedacht.

De agent wordt voortdurend gecorrigeerd door de gebruikers. Het teleurstelt gebruikers. Vervolgens eindigt de sessie, het logbestand wordt opgeslagen en de volgende gebruiker ontmoet in wezen hetzelfde systeem.

Dit is waarom continu leren centraal staat bij agent-engineering. Het is geen functie van één product. Het is een categorie methoden voor het verbeteren van agents vanuit ervaring, terwijl het behoudt wat al werkte. Klassiek continu leren onderzoek formuleerde het probleem als leren in de tijd zonder catastrofale vergetelheid. Agents maken dat probleem breder. Het ding dat verandert, kan een model zijn, maar het kan ook een prompt, een tool, een vaardigheid, een workflow of geheugen zijn.

Die onderscheid maakt ertoe, omdat de meeste agent-falen niet worden opgelost door als eerste naar modeltraining te grijpen.

De fine-tuning reflex is te smal

Wanneer teams praten over het verbeteren van een AI-systeem, klinkt het standaardplan vaak zo: verzamel fouten, label betere antwoorden, fine-tune het model. Die instinct is begrijpelijk. Begeleide fine-tuning, Direct Preference Optimization, Group Relative Policy Optimization, en parameter-efficiënte methoden zoals LoRA zijn nuttige tools wanneer het model zelf moet veranderen.

Maar veel productiefouten zijn geen modelgewichtfouten. Ze zijn systeemfouten.

De agent kan vertrouwen op verouderd geheugen, een vereiste bevestiging overslaan, een tool met de verkeerde argumenten aanroepen of een zaak via de verkeerde workflow routeren. Vaak is het probleem niet de capaciteit van het basismodel. Het is de context, geheugen, toolinterface of workflow eromheen.

Een moderne agent heeft verschillende lagen. Het model redeneert en genereert. De harness eromheen definieert de prompts, tools, vaardigheden, code, routing en workflow. Geheugen draagt feiten en geleerde procedures over sessies heen. Continu leren is de discipline van beslissen welke laag moet veranderen, hoe klein de verandering kan zijn en hoe te verifiëren dat de verandering daadwerkelijk heeft geholpen.

Soms is de juiste oplossing een geheugenschrijf. Soms is het een promptbewerking. Soms is het een toolwrapper, een routeringsregel of een workflowpatch. Fine-tuning moet beschikbaar blijven, maar het moet niet het eerste antwoord zijn op elke fout.

Benchmarks zijn nuttig, maar productie geeft ze zelden

Er is spannend werk aan de gang om de agentharness zelf te optimaliseren. Methoden zoals GEPA, Meta-Harness, en verwante prompt- of workflow-optimalisatiebenaderingen behandelen de agent als een systeem dat kan worden gemuteerd en getest. Ze kunnen bewerkingen van prompts of andere harnesscomponenten voorstellen, kandidaten uitvoeren en de versies behouden die beter scoren.

Dat is de juiste richting. Het verplaatst verbetering uit het smalle kader van “update de gewichten” en in het bredere kader van “verbeter de agent”.

Maar er is een addertje onder het gras: deze methoden gaan meestal uit van een benchmark. Ze hebben een taak nodig die herhaaldelijk kan worden uitgevoerd en een evaluator die zegt of kandidaat A beter is dan kandidaat B. Zonder dat wordt optimalisatie giswerk met betere tooling.

Dit is niet wat de meeste teams in productie hebben.

Wat ze hebben, zijn logbestanden. Ze hebben sporen, gebruikerscorrecties, ondersteuningsaanvragen, thumbs-down-gebeurtenissen, escalatienotities en occasionele expertfeedback. Die signalen zijn waardevol, maar ze zijn nog geen benchmark. Ze vertellen je dat er iets gebeurd is. Ze vertellen je niet automatisch hoe je het moet afspelen, wat succes zou moeten lijken of hoe je een voorgestelde oplossing moet scoren.

Die kloof is waar veel continu-leerefforts stilvallen. Het team heeft ervaring, maar nog geen leeromgeving.

Logbestanden zijn geen lessen

Een productielogbestand registreert één pad door een interactie. Een gebruiker vroeg om een vlucht. De agent zocht. De gebruiker zei dat de datum verkeerd was. Dat is bewijs van een fout, maar het is niet genoeg om van te leren.

Het logbestand definieert de contrafacticum niet. Had de agent moeten vragen om bevestiging? Had het de datum moeten afleiden uit eerder context? Had het een andere tool moeten aanroepen? Had het moeten weigeren om door te gaan totdat de onduidelijkheid was opgelost? Een mens kan het antwoord weten na het lezen van het spoor, maar het systeem krijgt die structuur niet voor niets.

Voor continu leren te werken, moet een rauwe fout worden omgezet in iets wat kan worden afgespeeld. Dat betekent een taak die de agent opnieuw kan tegenkomen, een gebruiker of simulator die het relevante patroon opnieuw creëert, tools die de agent kan aanroepen en evaluators die succes definiëren. De evaluator kan de eindantwoord controleren, de toolaanroepen, een beleidsgrens, latentie, kosten of al het bovenstaande.

Dit is het minder zichtbare deel van het werk, maar het is het deel dat verbetering echt maakt. Zodra een fout een afspeelbare omgeving wordt, kun je een concrete vraag stellen: heeft de voorgestelde oplossing de fout daadwerkelijk verholpen?

Zonder die stap zijn teams voornamelijk aan het patchen vanuit het geheugen.

David Silver en Richard Sutton hebben een komende era van ervaring beschreven, waarin agents leren van interactie met de wereld in plaats van van statische menselijke data. Voor enterprise-agents hangt die visie af van het omzetten van rommelige productie-ervaring in omgevingen die kunnen worden afgespeeld, gescoord en hergebruikt.

Ervaring alleen is niet genoeg. Het moet getest kunnen worden.

Regressie is de verborgen kosten

Zelfs wanneer een fout afspeelbaar wordt, blijft het moeilijkste deel over: het oplossen zonder iets anders te breken.

Iedereen die een complexe agent heeft onderhouden, heeft dit patroon gezien. Je voegt een instructie toe zodat de agent agressieve restitutieaanvragen escaleert. Nu escaleert het routine-restitutieaanvragen die snel moeten worden afgehandeld. Je vermindert toolaanroepen in één workflow. Nu slaat een andere workflow een vereiste controle over. Je corrigeert een verouderd geheugen. Nu generaliseert de agent de correctie te veel naar een andere productlijn.

Elke patch is lokaal zinvol. Het systeem drijft nog steeds globaal.

Dit is de agentversie van catastrofale vergetelheid. In neurale netwerken verwijst de frase meestal naar nieuwe training die oude capaciteiten overschrijft. Bij agents is de fout breder en vaak moeilijker te zien. Vergetelheid kan optreden in prompts, tools, geheugen, routing en workflow. Het manifesteert zich niet als een schone metriek op een trainingscurve, maar als een gebruiker die zegt: “Dit werkte vroeger”.

Daarom kan regressiecontrole niet een laatste beoordelingsstap zijn. Het moet in de leerlus zelf zitten.

Het doel is niet alleen om de prestaties op de nieuwste fout te maximaliseren. Het doel is om de nieuwe zaak te verbeteren terwijl de oude behouden blijft. Elke oplossing die werkt, moet deel worden van de groeiende geheugen van de agent van wat moet blijven werken. In de praktijk betekent dit dat oude fouten regressietests worden. De geschiedenis van de agent wordt een beperking, niet alleen een archief.

Dit is waar continu leren meer wordt als serieus software-engineering dan prompt-tinkering. Een verandering is niet goed omdat het beter klinkt. Het is goed omdat het een gemeten gedrag verbetert en de gedragingen die het systeem al had verdiend, niet degradeert.

Wat praktisch continu leren vereist

Een productieklare continu-leerlus heeft vier eigenschappen nodig.

Ten eerste moeten fouten afgespeeld kunnen worden. Een eenmalige fout is een anekdote. Een afspeelbare, beoordeelde omgeving is een test. Tot de agent hetzelfde patroon opnieuw kan tegenkomen, kan niemand bewijzen dat de oplossing werkte.

Ten tweede moet diagnose holistisch zijn. De oplossing kan in het model zitten, maar het kan ook in geheugen, prompt, tool-laag of workflow zitten. De beste oplossing is meestal de kleinste duurzame verandering die de fout verklaart.

Ten derde moet leren levenslang zijn. De agent moet deze week niet verbeteren door stilzwijgend het gedrag van vorige week ongedaan te maken. Eerdere successen moeten tijdens optimalisatie beperkingen worden, niet verrassingen na implementatie.

Ten vierde moet de lus efficiënt zijn. Als elke verbetering een kwartaalproject voor opnieuw trainen vereist, zal het systeem nooit bij productie blijven. De lus moet eerst goedkope oplossingen proberen, alleen escaleren wanneer nodig en verificatie dicht bij de verandering houden.

Geen van deze dingen betekent dat agents zichzelf blindelings moeten bijwerken. Het betekent het tegenovergestelde. Verbetering moet meetbaar worden. Elke verandering moet een test hebben, een voor- en na-score en een regressiecontrole.

Dat is wat continu leren van een vage aspiratie in een engineeringsdiscipline verandert.

De toekomst van agents zal niet alleen worden gedefinieerd door grotere contextvensters, sterkere basismodellen of meer tools. Die zullen ertoe doen. Maar de belangrijkste vraag voor ondernemingen is wat er gebeurt na implementatie.

Wanneer de agent morgen faalt, kan het systeem die fout omzetten in een test? Kan het de oplossing naar de juiste laag routeren? Kan het bewijzen dat de oplossing heeft geholpen? Kan het bewijzen dat niets anders brak?

Als het antwoord nee is, leert de agent niet echt van productie. Het verzamelt risico.

De agents die ertoe doen, zullen het beter doen. Ze zullen accumuleren.