De oplossing werkte. De AI agent workflow ging ergens anders stuk.

Een financieel team gebruikt een agentflow die facturen van leveranciers leest en van elke factuur een korte samenvatting maakt. Op een dag klaagt een teamlid dat bedragen in dollars worden weergegeven zonder valuta.

Een collega past één regel in de instructies van de agent aan en voert de flow opnieuw uit met die factuur. De valuta wordt nu wel vermeld. De wijziging wordt doorgevoerd.

Drie weken later ontdekt de controller dat creditnota’s als gewone facturen zijn samengevat. Bedragen die negatief hadden moeten zijn, staan positief. Alle runs in die drie weken zijn met de status ‘geslaagd’ geëindigd.

Niemand was onzorgvuldig. De collega testte het geval dat niet goed werkte, maar niemand testte de gevallen die al goed gingen.

Dat is een regressie: een geval dat eerder werkte, maar na een wijziging niet meer. In een AI agent workflow is zo’n regressie gemakkelijk te veroorzaken en moeilijk te ontdekken. Een run kan namelijk succesvol eindigen en toch een verkeerd resultaat opleveren.

Eén gebruiker meldde dat een workflow na een wijziging alleen aangaf dat de run was geslaagd. Een stap kan nog steeds de status ‘geslaagd’ krijgen terwijl de vorm van de uitvoer ongemerkt verandert. Pas verderop kan iets misgaan, wanneer het probleem zichtbaar wordt. Twee andere gebruikers in dezelfde discussie gaven aan dat ze dit probleem ook in hun eigen systemen tegenkwamen.

In een andere discussie schreef een gebruiker dat het lastigste is om te ontdekken wanneer een wijziging het ene geval oplost, maar ongemerkt een ander geval kapotmaakt. Daarom voert die gebruiker de volledige reeks testgevallen telkens opnieuw uit, vaker dan gewenst.

Een derde gebruiker liet zien wat zo’n testronde kan kosten. De gebruiker klikte op uitvoeren om een wijziging te testen, maar het platform startte een volledige testronde voor alle gevallen in plaats van één run. Die ene onbedoelde ronde leidde tot ongeveer tien aanroepen van een betaalde screenshotdienst en zeven beeldgeneraties.

Deze meldingen leveren twee lessen op. Een run met de status ‘geslaagd’ is geen vergelijking met de laatst bekende goede run. En een volledige reeks testgevallen opnieuw uitvoeren is niet gratis wanneer de tests betaalde diensten of live systemen raken.

De vier controles hieronder zijn toepasbaar op elk platform, ook op EpicStaff. Onder elke controle leest u hoe EpicStaff hiermee omgaat. Ze vormen een aanvulling op de vragen die u aan elke leverancier stelt wanneer u kiest waar uw agents draaien.

Voor regressietests hebt u een vaste reeks testgevallen nodig. Elk testgeval bestaat uit een invoer en een korte notitie over wat er aan het resultaat moet kloppen. Houd de reeks klein. Het belangrijkste is welke gevallen u erin opneemt.

Voeg elk geval toe dat ooit misging. Hebt u een probleem opgelost, voeg dat geval dan toe aan de reeks, samen met vergelijkbare gevallen die er sterk op lijken. In het voorbeeld aan het begin was een vergelijkbaar geval naast ‘een factuur in dollars’ bijvoorbeeld ‘een creditnota in dollars’.

In EpicStaff kunt u een volledige flow starten met uw eigen testinvoer en een Python-stap afzonderlijk testen.

EpicStaff heeft geen ingebouwde test- of evaluatiefunctie. Bewaar uw reeks testgevallen daarom in uw eigen bestanden, naast de flow.

Hoe u een workflow de eerste keer test: U kunt een AI agent niet testen zoals gewone code.

Als de tests alleen worden uitgevoerd wanneer iemand eraan denkt, worden ze mogelijk juist overgeslagen wanneer ze het belangrijkst zijn. Een script of CI-job kan dit voorkomen. CI staat voor continuous integration: automatische controles die bij wijzigingen in de code worden uitgevoerd.

In EpicStaff kan een script of CI-job via de API en met een API-sleutel een flowrun starten.

Breng vóór de eerste volledige testronde in kaart welke externe systemen en diensten elk testgeval raakt, zoals betaalde diensten, e-mail, betalingen en systemen van andere teams. Laat tests waar mogelijk gebruikmaken van testaccounts of een vervangende dienst die opgeslagen antwoorden teruggeeft.

Leg vast hoeveel externe aanroepen één testronde hoort te doen en stop de ronde als dat aantal wordt overschreden. Een controle achteraf kan niet ongedaan maken wat de run al heeft uitgevoerd. Lees het model beoordeelde zijn eigen werk voor een voorbeeld met een live systeem.

Een eindstatus vertelt u dat geen enkele stap een fout heeft gemeld. Die status zegt niet dat elke stap hetzelfde resultaat heeft opgeleverd als de vorige keer. Dat is de kern van alle meldingen hierboven.

Vergelijk daarom een nieuwe run stap voor stap met een run waarvan u het resultaat vertrouwt. Wanneer een model tekst genereert, kunnen de formuleringen per run verschillen. Dat is op zichzelf geen regressie. Vergelijk wat hetzelfde moet blijven: welke velden een stap oplevert, het gegevenstype van elk veld, of een lijst leeg is en welke vertakking de run heeft gevolgd.

Een ander woord is ruis. Een ontbrekend veld kan op een regressie wijzen.

In EpicStaff kan een script via de API de uitvoer van elke stap in een afgeronde run uitlezen en twee runs met elkaar vergelijken.

Bewaar voor elk testgeval één run waarvan u het resultaat vertrouwt. Wijkt een nieuwe run daarvan af, laat dan een mens beoordelen of er sprake is van een regressie of dat het nieuwe resultaat voortaan als referentie moet dienen.

Wanneer de ene agent werk doorgeeft aan de andere: De sub-agent deed het werk. Het antwoord kwam nooit terug.

Als een testgeval niet meer werkt, is de eerste vraag: wat is er veranderd? Het antwoord is niet altijd uw eigen wijziging. Een collega kan bijvoorbeeld een andere stap hebben aangepast.

In EpicStaff bewaart elke run een volledige kopie van de flow zoals die was toen de run startte.

Vergelijk de kopie van de laatst bekende goede run met die van de run die het probleem vertoonde. Zo kunt u achterhalen welke wijziging het verschil heeft veroorzaakt, ongeacht wie deze heeft aangebracht.

Niet elke verandering is zichtbaar in een kopie van de flow. Uw aanbieder kan bijvoorbeeld een nieuwe modelversie beschikbaar stellen, of een ander systeem kan een ander antwoord teruggeven. Laat uw reeks testgevallen daarom ook volgens een vaste planning uitvoeren, en niet alleen na uw eigen wijzigingen.

De meeste teams beschouwen een probleem als opgelost zodra het gemelde geval weer werkt. Dat is maar de helft van het werk. De andere helft is controleren of alle gevallen die gisteren werkten, vandaag nog steeds werken.

Uw reeks testgevallen hoeft op de eerste dag niet groot te zijn. Wel moet deze alle gevallen bevatten die eerder misgingen. De tests moeten bovendien automatisch worden uitgevoerd, zonder dat iemand eraan hoeft te denken: na elke wijziging én volgens een vaste planning. Ook het model en de systemen rond uw flow kunnen immers veranderen zonder dat u daar zelf iets aan doet.

Een oplossing is pas af als de eerdere testgevallen nog steeds slagen.