De werking van je AI agent volgen – praktijkcasus

Een in software geïntegreerde AI agent bestaat uit twee lagen. De eerste laag is het aanspreken van de AI middels prompts, zoals we dat kennen uit chatbots, grofweg het vakgebied prompt engineering. De tweede laag bestaat uit traditionele software maar gericht op de agent om deze in goede banen te leiden. Dit plus prompt engineering is waar context engineering zich op richt.

In 100% traditionele software werk je doorgaans met formele programmeertalen en voorspelbare processen. Het domein software engineering heeft al decennia manieren ontwikkeld voor ons om daar grip op te houden.

Een AI agent is anders. Je prompt is feitelijk een deel van je broncode geworden, ondanks dat het gewoon natuurlijke taal is. Wij hebben eigenlijk geen goede manier om daar grip op te houden. Wat je dan dus moet is verzorgen dat je ziet wat er gebeurt en dat doe je door sporen – traces – achter te laten die je later kan analyseren. Die traces zeggen iets over de oorspronkelijke vraag, het antwoord, maar ook de procesflow (opheldering, validatiefout, interventie etc).

Traces module in Tingit

Om de sporen op te slaan, hebben we gekozen om per aanroep van de 8QL agent een trace aan te maken. Aangezien voor één prompt meerdere keren de agent kan worden aangeroepen, hebben we dat gebundeld door het conversatie ID in de trace mee te nemen.

Verder nemen we metadata mee, zodat we de precieze datum en tijd hebben, maar ook de versie van Tingit en het gebruikte AI-model, wat op dit moment enkel nog Gemini 2.5 Flash Lite is.

De belangrijkste gegevens bestaan uit de user prompt, de prompt die is samengesteld door Tingit en die naar de AI is verstuurd en het antwoord van de AI.

De belangrijkste doelstellingen die wij hopen te realiseren met deze data zijn:

• het kunnen analyseren van de oorspronkelijke gebruikersvraag om te bepalen of het verzoek écht succesvol was – een AI is wat makkelijker in het claimen van success
• het kunnen categoriseren van fouten, zodat we grip krijgen op de zwakheden van de AI agent en doelgericht foutcategorie kunnen gaan aanpakken
• het kunnen naspelen van scenario's in de AI studio van Google, waar we het originele scenario (de nul-situatie) en aanpassingen in de prompt (de één-situatie) met elkaar kunnen vergelijken
• een basis voor de nog te ontwikkelen evaluatieset van de 8QL agent, zodat we met vertrouwen de effectiviteit kunnen meten bij i) het wisselen van AI model, ii) het upgraden van een AI model versie of iii) een wijziging in de prompt

Testmiddag 8QL

Op donderdag 2 oktober hebben we met een groep van negen personen gelijktijdig tests uitgevoerd op de 8QL agent. De instructie was om te proberen zinvolle 8QL query's te laten genereren, maar ook om de grenzen op te zoeken van wat het systeem aan kan, bijvoorbeeld door de agent met onzin-vragen te voeden of prompt injection (de AI dingen laten doen waar hij niet voor bedoeld is) te proberen.

De sessie duurde ongeveer twee uur en in die periode heeft het testteam 1.394 traces weten te genereren. Deze traces werden overgeheveld van de database naar een spreadsheet om de analyses op te kunnen uitvoeren.

Eerste observaties

Hoewel de 8QL agent goed is in omgaan met namen en de verschillende Tingit-functies, zagen we met een oppervlakkige analyse van de data al snel een aantal problemen:

• de AI heeft de neiging om SQL constructies (wellicht omdat de naam op 8QL lijkt?) toe te passen in 8QL (nog strengere instructies)
• de AI krijgt bepaalde verboden constructies niet mee, maar de validatie rekent daar wel op af (gelijktrekken)
• de AI kan niet goed omgaan met de datum van vandaag, ondanks dat daar een Tingit-keyword voor is (prompt formulering, strengere instructies)
• de AI heeft de neiging dubbele quotes te gebruiken, wat niet is toegestaan (strengere instructies)
• de AI vergeet soms delen van de gebruikersvraag, vooral als het een keer mis is gegaan met een eerder gegenereerde query (reflecteren op originele vraag)

Verder is het niemand gelukt om de AI agent te hacken. Dat was conform verwachting, omdat er volgens ons geen aanvalsoppervlak is (zie eerdere risicoanalyse).

Vervolgstap

De tabel met traces wordt regel voor regel doorlopen en iedere trace wordt voorzien van een foutcategorie. De foutcategorieën worden bedacht op het moment dat ze gezien worden, omdat ze nog niet eerder gezien zijn. Voor iedere foutcategorie wordt een probleemanalyse uitgevoerd, een oplossingsrichting bedacht en bij correcte werking wordt deze doorgevoerd in de 8QL agent.

Op langere termijn worden de traces gebruikt om een evaluatieset uit te distilleren, die gaat dienen om de werking van de 8QL agent tenminste op niveau te houden en idealiter verder te verbeteren.