De meeste softwareteams zitten niet vast op de vraag of een AI-agent iets kan.
Een actueel bericht over Closing the AI agent trust gap with graduated autonomy is hier de context. Het nieuws is niet het punt; het maakt de operationele beslisdruk zichtbaar.
Ze zitten vast op de vraag wat hij mag.
Dat klinkt klein, maar het bepaalt of een agent een demo-truc blijft of echt werk uit handen neemt. Te weinig rechten en je bouwt een dure chatbot met goede bedoelingen. Te veel rechten en je maakt van een experiment ineens iets dat operationeel moet kloppen zonder mechanisme om vertrouwen op te bouwen.
AWS zet daar nu een derde route tegenover: graduated autonomy. Niet alles open. Niet alleen lezen. Maar autonomie die groeit als een agent zich herhaaldelijk betrouwbaar gedraagt, en weer krimpt als de prestaties terugvallen.
Dat is geen cosmetische nuance. Het is een ander antwoord op dezelfde bottleneck waar veel teams tegenaan lopen: waarde uit agents halen zonder meteen alle controle los te laten.
De verkeerde vraag is meestal de eerste vraag
In veel teams begint het gesprek nog steeds bij capaciteit.
Wat kan het model? Hoeveel tickets kan het afhandelen? Kan het code reviews doen, incidenten samenvatten, releases voorbereiden?
Dat zijn begrijpelijke vragen, maar ze schuiven de echte beslissing naar achteren. Want zodra een agent meer mag dan samenvatten of zoeken, kom je uit bij permissions. Mag hij alleen lezen? Mag hij een voorstel doen? Mag hij een wijziging klaarzetten? Mag hij die ook uitvoeren?
Daar gaat het meestal mis. Niet omdat mensen tegen AI zijn, maar omdat er geen tussenstand bestaat. Het systeem kent alleen “niets” of “alles”.
En dan blijven teams hangen in pilots. De agent doet nuttig werk in een afgebakende demo, maar zodra het op echte processen aankomt, wordt de stap naar productie te groot. Niet technisch te groot. Organisatorisch te groot.
Graduated autonomy is een permission-model, geen AI-slogan
De AWS-post maakt dat heel concreet. Het patroon heet graduated autonomy: een agent krijgt stap voor stap meer rechten op basis van sustained reliability. Blijft de performance goed genoeg, dan kan de autonomie omhoog. Zakt die terug, dan moet die weer omlaag.
Dat is belangrijk, omdat vertrouwen hier niet wordt behandeld als gevoel maar als gedrag over tijd.
In de bron wordt dit uitgewerkt met Amazon Bedrock AgentCore, Amazon DynamoDB en AWS CodePipeline. Je hoeft die stack niet één-op-één over te nemen om het idee te snappen. De kern is dat je een mechanisme nodig hebt dat prestaties meet, status bewaart en permissions daarop laat reageren.
Precies daar zit de inhoudelijke winst. Niet in nog een agent. Wel in een systeem dat onderscheid kan maken tussen “deze taak mag hij al zelfstandig doen” en “hier blijft menselijk toezicht goedkoper dan autonomie”.
Dat is een veel volwassener vraag dan: kan de agent dit aan?
Waarom dit voor softwareleiders een performance-vraag is
Wie graduated autonomy alleen als security- of platformvraag ziet, mist de zakelijke consequentie.
De bottleneck is vaak niet de kwaliteit van het model. De bottleneck is dat je geen schaalbare manier hebt om vertrouwen te verdienen per taak, per workflow, per type actie.
Zonder zo’n mechanisme blijven teams twee slechte opties houden.
Of je laat een agent alleen lezen. Dan leer je weinig over echte waarde, omdat hij niets mag veranderen.
Of je geeft te snel veel ruimte. Dan wordt een experiment ineens onderdeel van je operationele keten, terwijl je nog niet weet of de betrouwbaarheid stabiel genoeg is.
Voor softwareleiders is dat een performanceprobleem omdat het bepaalt waar capaciteit echt vrijkomt.
Een agent die alleen tickets samenvat, helpt op papier. Een agent die in een beperkte context ook acties mag voorbereiden, validaties kan doorlopen en pas later extra rechten verdient, verandert de doorlooptijd van werk. Maar alleen als je dat permission-model ook echt ontwerpt.
Anders koop je snelheid in de demo en traagheid in de operatie.
Wat ik hier als eerste zou checken
Als ik dit in een team zou beoordelen, zou ik niet beginnen bij het model.
Ik zou eerst kijken naar drie dingen.
Eén: welke taak is klein genoeg om autonomie te verdienen, maar groot genoeg om waarde te leveren?
Twee: welke signalen bepalen reliability? Niet alleen foutpercentages, maar ook herstelgedrag, consistentie en het soort correcties dat mensen nog moeten doen.
Drie: waar liggen de grenzen van de permission-ladder? Welke acties mag een agent uitvoeren, welke alleen voorbereiden, en welke blijven bewust handmatig?
Als je dat niet kunt aanwijzen, heb je geen autonome agentstrategie. Dan heb je een hoop verwachting rond een model.
En dat is precies waarom veel teams te vroeg praten over “volledige autonomie”. Het klinkt ambitieus, maar het slaat meestal een cruciale tussenstap over: het verdienen van vertrouwen.
De echte winst zit in selectief opschalen
Graduated autonomy is interessant omdat het softwareleiders dwingt om anders te denken over waarde.
Niet: hoe snel kunnen we een agent overal op loslaten?
Maar: waar levert autonomie rendement op, en waar blijft menselijk toezicht simpelweg goedkoper en verstandiger?
Dat antwoord verschilt per workflow. In sommige processen is lezen en voorstellen al genoeg. In andere processen moet een agent eerst weken of maanden betrouwbaar gedrag laten zien voordat hij iets mag uitvoeren. En soms blijft het gewoon een slecht idee om meer rechten te geven, hoe goed het model ook is.
Dat is geen teleurstelling. Dat is volwassen ontwerp.
De teams die hier het verst mee komen, behandelen autonomie niet als einddoel maar als gevolg van bewezen gedrag. Ze bouwen een systeem waarin rechten verdiend worden, niet verondersteld.
Daar zit voor mij de belangrijkste les uit deze AWS-aanpak. Niet dat agents slimmer worden. Maar dat je hun rol eindelijk kunt laten meegroeien met bewijs in plaats van met hoop.
En dat is precies waar veel softwareorganisaties nu nog te weinig op ingericht zijn.