De meeste engineeringteams evalueren AI-agenten nog steeds op dezelfde manier als ze wiskundehuiswerk nakijken. Ze kijken naar de uiteindelijke output. Als

De meeste engineeringteams evalueren AI-agents nog steeds op dezelfde manier als ze een wiskundetoets nakijken. Ze kijken naar de uiteindelijke output. Als het antwoord goed is, geven ze groen licht voor de release en gaan ze door. Dit is een gevaarlijke afsnijroute. Een correct antwoord kan een diep gebrekkig systeem verbergen.

Het echte verhaal zit in het pad dat de agent heeft afgelegd om daar te komen. Dat pad wordt de agent trajectory genoemd. Het omvat elke tool call, elke routeringsbeslissing en elke pauze waarbij de agent stopt om opnieuw na te denken. Je kunt het zien als het kruimelpad van de agent. En als je alleen de bestemming inspecteert, mis je alle waarschuwingssignalen die onderweg verspreid liggen.

Het probleem met rommelige paden

Een agent kan bij het juiste antwoord uitkomen terwijl hij zich gedraagt als een dronken bestuurder. Hij slingert door de verkeerde tools, keert terug naar de router en doorloopt redundante redeneringen voordat hij uiteindelijk per ongeluk iets correcte vindt. De gebruiker ziet een schoon resultaat. Achter de schermen verliest het systeem resources en stapelt het risico zich op.

Hoe ziet deze chaos er in de praktijk eigenlijk uit?

Ten eerste is er de redundante tool call. De agent raadpleegt je klantendatabase, krijgt het resultaat, vergeet het vijf seconden later en raadpleegt hetzelfde record opnieuw met identieke parameters. Dit is geen dataprobleem. Het is een trajectprobleem. De agent slaagde er niet in de status te behouden, waardoor hij werk herhaalt.

Dan is er het 'wrong-tool-first'-patroon. Een coding agent probeert misschien op het web te zoeken naar een functiedefinitie die al in het lokale repository staat. Of een support agent grijpt naar de billing API terwijl de vraag van de gebruiker duidelijk om de account settings tool vraagt. Elke verkeerde keuze verbruikt tokens, verhoogt de latentie en vergroot de kans dat de contextlimieten worden overschreden voordat het echte werk begint.

Router loops zijn een ander alarmsignaal. De beslissingsnode kan geen besluit nemen. Hij stuurt de taak naar tak A, verandert van gedachten, trekt het terug, stuurt het door naar tak B, en stuurt het vervolgens zonder reden door een algemene fallback-node. Elke loop voegt een extra netwerkstap toe en een extra laag verwarring aan het uiteindelijke debuglog.

Ten slotte is er herhaalde analyse. De agent blijft bij elke stap dezelfde conclusie opnieuw afleiden in plaats van deze als vaststaand te beschouwen. Het is als een timmerman die de plank tien keer meet voor elke zaagsnede. De eerste meting was prima. De volgende negen zijn verspilde bewegingen.

Deze extra stappen hebben reële gevolgen. De latentie loopt op. In een synchrone chatinterface voelen drie extra seconden als een eeuwigheid. Op schaal vertalen die seconden zich in duizenden dollars aan compute. Ook het risico op falen stijgt. Elke onnodige stap is een extra kans dat een externe API een timeout geeft, een context window overloopt of dat er een race condition ontstaat. En als er iets misgaat, veel succes met het debuggen van een trace die op spaghetti lijkt. Je zult uren besteden aan het reconstrueren waarom de agent stap zeven nam, om er vervolgens achter te komen dat stap zeven nooit had mogen bestaan.

Wat convergentie eigenlijk betekent

Als de trajectory het pad is, dan is convergentie de maatstaf voor de efficiëntie ervan. Convergentie vertelt je hoe nauw de agent de kortste levensvatbare route volgt tussen een gebruikersverzoek en de juiste oplossing.

Dit is niet hetzelfde als accuracy. Accuracy is een grof instrument. Het vraagt of de eindtoestand correct is. Convergentie vraagt of de reis logisch was. Een agent met een hoge accuracy en een lage convergentie is een risico dat zich vermomt als succes. Een agent met een hoge convergentie en een matige accuracy is meestal gemakkelijker te repareren, omdat de redenering helder is en de fouten gelokaliseerd zijn.

Je kunt een ruwe convergentiescore berekenen door de stappen die de agent daadwerkelijk zet te vergelijken met het kortste pad dat je voor die taakklasse hebt gedefinieerd. Als een standaard restitutieaanvraag precies drie tool calls zou moeten vereisen en de agent er negen gebruikt, dan krijgt je convergentieverhouding een klap. Je kunt dit verfijnen door verschillende soorten verspilling te wegen. Eén verkeerde tool call kan meer kosten dan één redundante call, afhankelijk van de latentie en de prijs van de tool. Een router loop die geen waarde toevoegt, kan de zwaarste straf krijgen, omdat het wijst op een architecturale