Drie dingen die er toe doen in de tweede helft van 2026
Na het werken met productie-agentsystemen in verschillende klanttrajecten, zijn er drie disciplines die het verschil maken tussen systemen die standhouden en systemen die stilletjes worden uitgezet.
1. Een meetframework per agent, niet per product
De standaard metric voor de meeste AI-features die live gaan, is adoptie. Hoeveel gebruikers het hebben geopend. Hoeveel sessies. Hoeveel seats geactiveerd. Dat is een productmetric, geen agentmetric. Het vertelt je niets over of de agent doet waarvoor je hem gebouwd hebt.
De bruikbare metrics zitten een niveau dieper. Taaksuccespercentage: heeft de agent de toegewezen taak afgerond zonder dat een mens moest ingrijpen of het opnieuw doen? Nauwkeurigheid van tool-aanroepen: als de agent een functie of API aanriep, deed hij dat met de juiste argumenten? Kosten per uitkomst: niet per token, niet per sessie, maar per eenheid daadwerkelijk geleverde waarde.
Die zijn lastiger te instrumenteren, zeker als je agent snel in elkaar is gezet voor een demo. Maar het zijn de enige cijfers die je vertellen of het systeem zijn plek in de stack verdient. Kies er twee of drie voor je live gaat. Later kun je er altijd meer aan toevoegen. Met geen enkele starten betekent dat je vliegt zonder instrumenten.
2. Identiteit, auditlogs, rollback en menselijke override zijn de basis, niet het plafond
Elke productieagent moet weten namens wie hij handelt, een spoor achterlaten van wat hij heeft gedaan, teruggedraaid kunnen worden als hij op basis van slechte data heeft gehandeld, en een duidelijk pad hebben waarlangs een mens kan ingrijpen en het overneemt.
Die vier dingen zijn geen compliance-checklist. Het zijn de mechanische eigenschappen die een agentisch systeem veilig maken om op schaal te draaien. Zonder die eigenschappen kan één slechte run de state corrumperen, een klant verkeerd in rekening brengen, iets onherstelbaar verwijderen, of een downstream proces starten dat dagen kost om terug te draaien.
Het bezwaar dat ik meestal hoor, is dat het toevoegen van deze infrastructuur het team vertraagt. Dat klopt, licht, de eerste keer. Bij de derde agent kost het twee uur, want de patronen liggen er al in. De kosten om dit achteraf toe te voegen na een incident liggen een orde van grootte hoger.
Dit is dezelfde logica waardoor versiebeheer ononderhandelbaar werd voor code. Niemand discussieert er nog over. Auditlogs en rollback voor agents komen ook zover. Teams die dit nu als optioneel behandelen, lenen gewoon tijd.
3. ROI op uitkomstniveau, niet op toolniveau
Dit is waar veel businesscases stil instorten. Een team bouwt een agent, meet de kosten om hem te draaien (compute, API-aanroepen, engineeringtijd), vergelijkt dat met de licentiekosten van de SaaS-tool die hij vervangt, en beschouwt het als een succes.
Maar de toolkosten waren nooit de echte kosten. De echte kosten waren de tijd die iemand besteedde aan een taak die een resultaat opleverde. De juiste vraag is: levert de agent dat resultaat sneller, nauwkeuriger en met minder correcties achteraf? Dat is een uitkomst. Daar zit de ROI.
Meten op toolniveau voelt comfortabel omdat de cijfers makkelijk op te halen zijn. Meten op uitkomstniveau vereist dat je definieert hoe een goed resultaat eruitziet. Dat dwingt een gesprek over kwaliteit af dat veel teams nog niet willen voeren. Voer dat gesprek voor je iets live zet. Het maakt alle andere beslissingen scherper.
