Elke paar maanden bedenkt de industrie een nieuwe term voor software die naar verluidt zelfstandig kan denken. Op dit moment is dat woord "Agentic AI". Leveranciers zijn er snel bij om het op landingspagina's en in pitchdecks te plakken. Maar een label is slechts marketingtekst totdat het systeem de confrontatie aangaat met jouw omgeving, jouw data en jouw foutmodi. Het woord zelf zegt niets over veiligheid, betrouwbaarheid of geschiktheid.

Het is tijd om te stoppen met het lezen van functielijsten en te beginnen met het meten van capaciteiten.

Het labelprobleem

Sales engineers zullen je dashboards, multi-model dropdownmenu's en mobiele toegang laten zien als bewijs van een "agentic" architectuur. Dat zijn interfacekeuzes, geen gedragsgaranties. Een product kan er hypermodern uitzien en toch in elkaar storten op het moment dat het een plan moet herzien na een API-timeout.

Wat telt, is of het systeem zich daadwerkelijk gedraagt als een autonome agent. Breekt het werk op in stappen? Raakt het echte systemen aan binnen strikte grenzen? Als er iets misgaat, past het zich dan aan, of faalt het simpelweg en wacht het af? Totdat je deze vragen beantwoordt met bewijs dat specifiek is voor jouw stack, koop je een concept, geen product.

Vijf capaciteitstests die er echt toe doen

Ik toets elke "agentic" claim aan vijf specifieke capaciteiten. Voor elk van deze capaciteiten stel ik een eenvoudige triagevraag: is het gedrag gedocumenteerd, geverifieerd in een pilot, of nog onbekend? "Onbekend" is de standaard. Het product heeft de bewijslast om het tegendeel aan te tonen.

Planning. Breekt het systeem een ambigu doel op in geordende, verifieerbare stappen? Iedereen kan een takenlijst genereren. De echte test is het afhandelen van een complex doel zoals "verlaag onze cloudkosten dit kwartaal met vijftien procent". Een echte agent brengt een audit van het huidige verbruik in kaart, identificeert ongebruikte resources, stelt aanbevelingen voor rightsizing op en plant wijzigingsverzoeken in de juiste volgorde in. Als het je een generieke tekst van vijf bullets geeft en zegt dat het klaar is, dan is dat geen planning. Dan is het samenvatten.

Tools. Handelt het binnen een vastgestelde reikwijdte op echte systemen? Het aanroepen van een mock API in een gepolijste demo is eenvoudig. Authentificeren bij je productie-CRM met credentials met minimale rechten (least-privilege), een record schrijven en de transactie loggen is moeilijk. Je moet precies weten welke systemen het aanraakt, welke keys het gebruikt en waar de blast radius eindigt. De reikwijdte moet begrensd zijn. Als de agent standaard schrijfrechten heeft in productie, heb je geen agent. Dan heb je een aansprakelijkheid.

Correctie. Past het zijn volgende stap aan na een fout? Dit is waar de meeste prototypes falen. Als de derde stap een 503-fout of een schema-mismatch teruggeeft, gaat de agent dan in een oneindige loop, hallucineert hij een succesmelding, of past hij zijn pad aan? Echte correctie betekent het observeren van de fout, het herplannen van de rest van de workflow en het uitvoeren van een nieuw pad zonder de beperkingen los te laten. Een retry-loop verpakt in optimisme is geen correctie.

Context. Houdt het beperkingen actief bij elke stap? Geheugen is niet genoeg. Als stap één een harde regel vaststelt zoals "overschrijd een budget van vijfhonderd dollar niet" of "sluit EU-klantgegevens uit", dan mag stap zeven die grens niet negeren omdat de context van de prompt is verschoven. Dit geldt voor compliance-regels, de tone-of-voice van het merk, goedkeuringshiërarchieën en toegangscontroles. Het behoud van context is het punt waar long-context modellen en klassiek state management elkaar moeten ontmoeten.

Toezicht. Kan een mens het proces stoppen of hervatten? Je hebt circuit breakers nodig die fijnmazig zijn, niet alleen een kill switch op de virtuele machine. Kan iemand het plan inspecteren na stap twee en stap drie goedkeuren? Als een externe afhankelijkheid faalt, kan een mens dit dan oplossen en de workflow hervatten zonder de status te verliezen? Toezicht is geen auditlog die je leest nadat het mis is gegaan. Het is een live mechanisme voor interventie.

Bewijs wint van vinkjes

Een demo is geen betrouwbaarheidspercentage. Een vinkje op een vergelijkingsoverzicht van leveranciers is geen bewijs. Wanneer een account executive zegt dat het product "revises after test failure", is je volgende stap om om de evidence card te vragen.

Een evidence card vervangt het vinkje door specificiteit. Het ziet er als volgt uit:

  • Capaciteit: Correctie
  • Claim: Herzien na een testfout
  • Bewijs: In afwachting van gecontroleerde testomgeving
  • Eigenaar: Developer-experience team
  • Stop als: Herziening een goedgekeurde interface wijzigt

Dit format dwingt duidelijkheid af. Het scheidt de marketingclaim van het bewijs. Het wijst eigenaarschap toe, zodat je precies weet welk team wordt opgeroepen wanneer de agent een goedgekeurde interface breekt tijdens een revisiepoging. Zonder eigenaar is er geen verantwoordelijkheid. Zonder stopcondities is er geen vangrail.

Voordat je een pilot lanceert, moet je drie dingen schriftelijk vastleggen. Ten eerste: je taken. Deze moeten voortkomen uit echte bedrijfslogica, niet uit synthetische benchmarks. Ten tweede: je faaltests. Trek halverwege de uitvoering een API-sleutel in, injecteer een ongeldige JSON-respons, of verdubbel de verwachte latentie. Ten derde: je stopcondities. Deze moeten automatisch zijn, geen handmatige paniekknop waarvan je hoopt dat iemand hem opmerkt.

Hoe je claims van leveranciers kritisch bevraagt

OpenAI stelt dat agents vijf componenten vereisen: modellen, tools, instructies, guardrails en menselijke interventie. Je kunt deze lijst gebruiken als een vocabulaire om leveranciers te bevragen zonder hun specifieke architectuur over te nemen.

Vraag welk model verantwoordelijk is voor planning versus louter generatie. Vraag welke tool-permissies hardcoded zijn en welke dynamisch. Vraag waar guardrails worden afgedwongen: in de prompt-laag of in de orchestration engine. Vraag of menselijke interventie een ingebouwde checkpoint is of een post-mortem e-mail die wordt verzonden nadat de agent je database al heeft verpest. Je bent niet op zoek naar de stack van OpenAI. Je gebruikt hun framework om gaten in die van iemand anders bloot te leggen.

MonkeyCode biedt een open-source pad en een gratis cloudversie. Die combinatie maakt het goedkoop om een pilot te starten. Maar een goedkope instap is niet hetzelfde als gevalideerd succes. Onbekende delen van het systeem blijven onbekend totdat je je eigen taken draait op je eigen infrastructuur. Laat je niet misleiden door een ticket van nul dollar met de gedachte dat de moeilijke vragen al zijn beantwoord.

Een inkoopregel die budget bespaart

Mijn regel voor het uitbreiden van een agentic pilot naar een productie-commitment is simpel. Ik verhoog de scope en het budget alleen wanneer kritieke capaciteiten bewezen zijn en er een duidelijke eigenaar is voor fouten. Geen roadmap-slide. Geen wachtrij voor supporttickets. Bewijs betekent logs uit jouw omgeving. Een eigenaar betekent een benoemde persoon die een pager draagt voor die specifieke foutmodus.

Als de leverancier geen bewijs kan leveren, of als je interne team geen eigenaar kan aanwijzen, ben je niet klaar om uit te breiden. Je bent klaar om te blijven testen.

Wat te onthouden: Het woord "Agentic" is het startschot voor je evaluatie. Het is niet de finishlijn. Beschouw het als een aanleiding om moeilijkere vragen te stellen, strengere pilots uit te voeren en bewijs te eisen dat er binnen jouw organisatie toe doet. Als het product de vijf capaciteitstests op jouw terrein niet kan doorstaan, met jouw fouten, dan is het niet echt agentic. Dan is het gewoon een andere demo.

Bron: https://dev.to/bestbee/is-it-really-agentic-ai-use-a-five-capability-product-gate-1c0h

Optionele leercommunity: https://t.me/GyaanSetuAi