Drie dingen die tellen in de tweede helft van 2026
Na werk aan production agent-systemen langs meerdere client tracks, zijn het drie disciplines die bepalen welke systemen standhouden en welke stilletjes worden uitgeschakeld.
1. Een meetframework per agent, niet per product
De standaardmetriek voor de meeste live AI-features is adoption. Hoeveel gebruikers openden het. Hoeveel sessies. Hoeveel seats geactiveerd. Dat is een product-metriek, geen agent-metriek. Het zegt niets over of de agent doet wat je hebt gebouwd.
Bruikbare metreken liggen een niveau dieper. Task success rate: heeft de agent de toegewezen taak voltooid zonder dat een mens moet ingrijpen of het opnieuw doen? Tool call accuracy: wanneer de agent een functie of API aansprak, riep hij dan de juiste aan met de juiste argumenten? Cost per outcome: niet cost per token, niet cost per sessie, maar cost per eenheid werkelijke geleverde waarde.
Deze zijn moeilijker in te bouwen, vooral als je agent snel voor een demo in elkaar gezet is. Maar het zijn de enige getallen die je vertellen of het systeem zijn plaats in de stack verdient. Kies twee of drie voor je live gaat. Je kunt later altijd meer toevoegen. Met geen enkele metriek starten betekent blind vliegen.
2. Identiteit, audit logs, rollback en human override zijn de basis, niet het plafond
Elke production agent moet weten namens wie hij handelt, een spoor achterlaten van wat hij deed, omkeerbaar zijn als hij op slechte data werkt, en een duidelijk pad hebben voor een mens om in te grijpen en over te nemen.
Die vier dingen zijn geen compliance-checklist. Ze zijn de mechanische eigenschappen die een agent-systeem veilig op schaal maakt. Zonder ze kan één slechte run state beschadigen, een klant verkeerd berekenen, iets onherstelbaars verwijderen, of een downstream process starten die dagen kost om uit te spoelen.
De tegenwerping die ik meestal hoor is dat deze infrastructuur het team vertraagt. Dat doet het, licht, de eerste keer. Na de derde agent is het een tweeuur setup omdat de patronen al op hun plaats liggen. De kosten ervan achteraf na een incident in te bouwen zijn vele malen hoger.
Dit is dezelfde logica die version control onmisbaar maakte voor code. Niemand twistert erover meer. Audit logs en rollback voor agents krijgen daar ook toe. Teams die nu bouwen en deze als optioneel behandelen, lenen gewoon tijd.
3. ROI op outcome-niveau, niet op tool-niveau
Dit is waar veel business cases stilletjes ineenzakken. Een team bouwt een agent, meet de kosten ervan (compute, API calls, engineering tijd), vergelijkt dat met de licentiekosten van het SaaS-tool dat het vervangt, en roept het uit als winst.
Maar de tool-kosten waren nooit de echte kosten. De echte kosten waren de tijd die een persoon spendeerde aan een taak die een resultaat opleverde. De juiste vraag is: levert de agent dat resultaat sneller, nauwkeuriger en met minder downstream correcties op? Dat is een outcome. Dat is waar de ROI zit.
Meten op tool-niveau is comfortabel omdat de getallen makkelijk zijn op te halen. Meten op outcome-niveau vereist dat je definieert hoe een goed resultaat eruitziet, wat een gesprek over kwaliteit afdwingt waar veel teams nog niet klaar voor zijn. Voer dat gesprek voor je shipped. Het maakt alles scherper.
