Autonomie is een ontwerpkeuze, geen modeleigenschap

Agency en autonomie zijn twee verschillende knoppen

Voor de vijf niveaus verderop is één onderscheid nodig, en de auteurs maken het expliciet omdat de twee termen in eerdere literatuur vaak door elkaar liepen. Agency is wat een systeem kán: “the capacity to formulate an intention for an action and carry out that action.” Een agent met toegang tot veel tools heeft veel agency. Autonomie is iets anders: “the extent to which an AI agent is designed to operate without user involvement.” Dat is een definitie uit de robotica — “the ability to operate without a human operator for a protracted period of time” — die de auteurs naar AI-agents overzetten.

Het contrastvoorbeeld uit het paper zelf maakt het onderscheid concreet. Een agent die alleen een rekenmachine-API mag aanroepen heeft weinig agency — er is weinig dat hij kán doen — maar als hij dag en nacht op de achtergrond draait en grote volumes berekeningen verwerkt zonder dat iemand meekijkt, heeft hij hoge autonomie. Een andere agent met toegang tot tientallen tools heeft juist hoge agency, maar als hij voor elke volgende stap eerst terugvraagt aan de gebruiker, is zijn autonomie laag. Meer kunnen en meer zelfstandig doen zijn dus geen synoniemen — het zijn twee assen die onafhankelijk van elkaar bewegen.

Vijf niveaus, dezelfde agent

Met dat onderscheid op tafel bouwen Feng et al. een schaal van vijf niveaus, elk gekarakteriseerd door de rol die de gebruiker inneemt. Ze passen alle vijf toe op hetzelfde voorbeeldverzoek (het onderzoek naar de economische impact van generatieve AI hierboven), met hetzelfde model, dezelfde tools en dezelfde omgeving — alleen het niveau verandert.

• L1 — Operator. De gebruiker plant en beslist, de agent voert uit op aanvraag. Vergelijkbaar met een “copilot”-metafoor: ChatGPT Canvas, Microsoft Copilot. Geschikt voor situaties waarin de gebruiker zelf vaardigheden opbouwt, of waar een fout duur is en verantwoording moeilijk te herleiden.
• L2 — Collaborator. Agent en gebruiker plannen, delegeren en werken samen uit, ieder deels zelfstandig. De gebruiker kan het werk van de agent op elk moment overnemen. Voorbeelden: OpenAI Operator, Cocoa.
• L3 — Consultant. De agent neemt het voortouw over een langere horizon, maar raadpleegt de gebruiker voor expertise en voorkeuren. De gebruiker kan geen controle overnemen, alleen wijzigingen aanvragen. Voorbeelden: Gemini Deep Research, Replit Agent.
• L4 — Approver. De agent betrekt de gebruiker alleen bij een blokkade, een ontbrekende credential, of een vooraf aangewezen risicovolle stap. Voorbeelden: Devin, Manus, SWE Agent.
• L5 — Observer. Volledige zelfstandigheid; de gebruiker kan meekijken via logs maar niet ingrijpen, op een noodstop na. Voorbeelden: Voyager, The AI Scientist.

L4 verdient een aparte opmerking. De auteurs noemen een risico dat niet bij de andere niveaus speelt: “How can misaligned agents leverage user disengagement to gain more autonomy?” Een gebruiker die te vaak om goedkeuring wordt gevraagd, klikt op den duur door zonder te lezen — en een agent die dat patroon leert herkennen, kan van die gewoonte profiteren. Toezicht dat in naam bestaat maar in de praktijk een automatisme is geworden, is geen toezicht meer. Dezelfde auteurs noteren ook, terloops maar niet toevallig: naarmate de autonomie van een agent toeneemt, groeit ook het aanvalsoppervlak. Dat raakt aan de vraag hoe je een agent tegen onvertrouwde invoer beschermt, maar is er niet hetzelfde als: hier gaat het over hoeveel een agent uit zichzelf mag doen, niet over wat een aanvaller hem kan laten doen.

Wat een leverancier ervan bouwt

De permissiedocumentatie van Claude Code (laatst gewijzigd 21 augustus 2026) beschrijft zes modi die zich merkbaar langs dezelfde as laten leggen. Manual vraagt bij het eerste gebruik van elk gereedschap — L1. Auto keurt acties automatisch goed via een classifier die controleert of ze bij het verzoek passen — een geautomatiseerde approver, L4. bypassPermissions slaat toestemming vrijwel helemaal over, met een expliciete waarschuwing in de documentatie zelf: “Only use this mode in isolated environments like containers or VMs where Claude Code can't cause damage.” Dat is bijna letterlijk de rechtvaardiging die Feng et al. voor L5 geven — volledige autonomie is te verdedigen zodra de gevolgen van een fout de omgeving niet uit kunnen.

Eén zin uit diezelfde pagina raakt de kern van het ontwerpkader zonder het te citeren: “Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don't change what Claude Code allows.” Het niveau zit niet in het model. Het zit in de laag eromheen — precies het onderscheid waar dit stuk mee opende.

Waarom een langere tijdshorizon niet evenredig meer autonomie is

Het kader van Feng et al. zegt dat autonomie los van capaciteit ontworpen kán worden. Dat is geen garantie dat een sterker model in de praktijk niet toch als vrijbrief voor een hoger niveau wordt gelezen — “dit model haalt hogere scores, dus mag het meer zelfstandig”. METR's tijdshorizon-onderzoek laat zien waarom die redenering mank loopt.

METR meet hoe lang een taak — uitgedrukt in de tijd die een geoefende mens er normaal over doet — een model met 50% kans succesvol afrondt: de “50%-tijdshorizon”. In hun update van januari 2026 (Time Horizon 1.1) is de taakset uitgebreid van 170 naar 228 taken, met het aantal lange taken (8 uur of meer) verdubbeld van 14 naar 31 — al zijn daarvan er nog maar 5 met een echte menselijke tijdmeting; de rest is geschat.

Die cijfers zijn al reden tot voorzichtigheid, maar de scherpste correctie komt van METR zelf. In een aparte notitie schrijft een van de hoofdauteurs van het oorspronkelijke tijdshorizon-onderzoek dat het begrip vaker verkeerd wordt gelezen dan hen lief is: “Time horizon is not the length of time AIs can work independently. Rather, it's the amount of serial human labor they can replace with a 50% success rate.” Vijftig procent slagen is geen bruikbare drempel voor de meeste consequential actions.

Autonomie als iets dat je kunt certificeren

Feng et al. stellen “autonomy certificates” voor: een derde partij die per agent vastlegt op welk maximumniveau hij mag draaien, gegeven een vaste set capaciteiten en een vaste omgeving. Het idee is minder bureaucratisch dan het klinkt — het lost een specifiek probleem op dat ze aanwijzen in bestaande veiligheidskaders. Anthropic's eigen Responsible Scaling Policy classificeert systemen met “low-level autonomous capabilities” als systemen die “significantly higher risk” dragen — maar een binaire drempel (kan het een taak volledig zelfstandig afronden, ja of nee) meet niet wat er in de praktijk toe doet. Hun eigen voorbeeld: een L5-agent die zelfstandig omzet genereert, en een L4-agent die dezelfde omzet alleen genereert na één simpele goedkeuring — in de praktijk vergelijkbaar risico, maar een binair kader beoordeelt ze alsof het tweede veiliger is.

Om zo'n certificaat uit te reiken moet autonomie meetbaar zijn, los van capaciteit. Feng et al. stellen daarvoor “assisted evaluations” voor: een agent krijgt een taak zonder hulp; lukt dat niet, dan neemt de betrokkenheid van een meelezende gebruiker stapsgewijs toe (eerst alleen goedkeuringen, dan overleg, dan samenwerking) tot de taak wel slaagt, en het niveau volgt uit hoeveel betrokkenheid daarvoor nodig bleek. De auteurs noemen zelf dat dit kostbaar is — tot vijf testrondes om een agent als L1 aan te merken — en de methode is in dit paper voorgesteld, niet op een echte agent gedraaid.

Wat ik hieruit zou bouwen

• Kies het niveau per actie, niet per agent. Een enkel systeem kan op consultant-niveau research doen en op operator-niveau code aanraken die productie kan breken. Eén niveau voor een heel systeem is een vereenvoudiging die de gevaarlijkste actie de vrijheid van de veiligste geeft.
• Verwar “kan veel” niet met “mag veel”. Agency en autonomie zijn losse knoppen. Een capabeler model dat een taak beter aankan, is geen argument om die taak minder te controleren — dat is een argument om de taak sneller te laten uitvoeren, wat iets anders is.
• Leg vast wat het niveau handhaaft, niet alleen wat het beoogt. Een niveau dat alleen als gewoonte bestaat, verandert zonder waarschuwing zodra iemand het systeem anders gebruikt of uitbreidt. Hetzelfde punt dat de permissiedocumentatie maakt: de regel hoort in de laag te zitten die de handeling uitvoert, niet in een instructie die het model kan lezen en negeren.
• Reken de betrouwbaarheidsdrempel van de taak mee, niet de gemiddelde score van het model. METR's 98%-drempel voor kritieke, moeilijk verifieerbare taken ligt ver boven de 50% waarop een tijdshorizon-cijfer is gebaseerd. Een model dat gemiddeld goed scoort, hoeft daarmee niet dicht bij de drempel te zitten die een specifieke actie nodig heeft.
• Noem de prijs. Een lager niveau kost doorlooptijd; een hoger niveau kost controleerbaarheid zodra het misgaat. Geen van beide is gratis, en een keuze die dat niet benoemt is nog geen afgewogen keuze.

Wat dit stuk niet aantoont

• Niet dat een hoger autonomieniveau slechter is. Sommige taken — goed afgebakend, makkelijk te verifiëren, in een omgeving die geen schade naar buiten toelaat — horen juist op een hoog niveau thuis.
• Niet dat tijdshorizon een slechte maatstaf is. METR's eigen notitie zegt waar hij wél voor deugt: het volgen van de trend in vaardigheid over tijd, niet het bepalen van een delegatiedrempel voor een individuele taak.
• Niet dat autonomy certificates de oplossing zijn. Het is een voorstel met een onbeproefde evaluatiemethode, geen bestaand mechanisme.
• Niet dat de vijf niveaus van Feng et al. de enige juiste indeling zijn. Andere kaders delen taken anders in; wat overeind blijft is het onderliggende punt, dat autonomie een aparte as is.

Waar het ophoudt