Wat is computergebruik en waarom is het belangrijk? Computergebruik is een eenvoudig idee met verstrekkende gevolgen: in plaats van modellen vragen te laten beantwoorden, laten we ze zelfstandig software bedienen, door websites te navigeren, formulieren in te vullen, workflows te doorlopen en taken van begin tot eind uit te voeren.
Hierdoor wordt een grote categorie praktijktaken mogelijk die nu over verschillende interfaces is versnipperd, zoals volledige boekingsprocessen, afrekenen bij webwinkels, reisplanning in meerdere stappen en backofficeworkflows zonder bruikbaar API-equivalent. Deze problemen zijn niet nieuw. Nieuw is dat ze nu met modellen voor algemeen gebruik kunnen worden opgelost.
Recente systemen van Anthropic en OpenAI hebben laten zien dat agents niet alleen handelen, maar ook over de status redeneren, fouten herstellen en ter plekke taakspecifieke oplossingen samenstellen. Zo wordt de browser een algemene uitvoeringsomgeving voor agents. Dit roept meteen een ontwerpvraag op: hoeveel van die omgeving moeten we aan het model blootstellen?
Vroege systemen kozen ervoor de browser te omgeven met een vaste reeks veilige, vooraf gedefinieerde acties. Zoals we in dit artikel betogen, bereikt die aanpak inmiddels zijn grenzen.
Bij het bouwen van browseragents komt vaak dezelfde reflex op: vertrouw het model niet te veel.
Daarom zetten we een wrapper om de browser. We bieden vooraf gedefinieerde tools aan, zoals click, type, scroll, select en read_text. We vereenvoudigen het Document Object Model (DOM). We beperken de actieruimte. We proberen gedrag inzichtelijk en beheersbaar te maken via zelfontworpen abstracties.
Dat is een verstandig uitgangspunt. Maar op de lange termijn blijkt het ook steeds meer de verkeerde architectuur.
Naarmate grensverleggende modellen beter worden, is het probleem niet langer alleen dat het model te weinig tools heeft. Het probleem is dat we het dwingen te werken via abstracties die te veel van het onderliggende systeem wegnemen. We persen een rommelige, dynamische omgeving in een vaste actie-interface en vragen het model vervolgens om goed te presteren ondanks dat informatieverlies.
Die afweging wordt steeds minder aantrekkelijk.
De verschuiving die we onderzoeken is eenvoudig uit te leggen, maar heeft ingrijpende gevolgen. In plaats van de agent te behandelen als een kiezer van vooraf gedefinieerde acties, zien we die als een programmagenerator die binnen een begrensde runtime werkt.
De modellen zijn erg goed geworden en hebben je geabstraheerde vangrails niet meer nodig. Ze hebben de volledige actieruimte nodig om de taak te ontwerpen, uit te voeren en te verbeteren totdat ze hun doel bereiken.
Dit artikel gaat over die verschuiving, van browserautomatisering met veel abstracties naar begrensd computergebruik, en over wat er verandert wanneer je systemen zo ontwerpt.
Het probleem is niet dat vaste actie-interfaces conceptueel onjuist zijn. Het probleem is dat het web niet met ze meewerkt.
Moderne interfaces zijn gebouwd met React, Vue en Angular en bevatten asynchrone statusupdates, synthetische gebeurtenissystemen en ingebedde widgets van derden in cross-origin-iframes met een eigen levenscyclus. Een wrapper met de opdracht "typ in dit invoerveld" werkt alleen als de pagina jouw definitie van typen hanteert. Veel pagina's doen dat niet. Als je rechtstreeks een waarde instelt, omzeil je vaak volledig de wijzigingsdetectie van het framework. Het invoerveld lijkt ingevuld. De validatie wordt nooit geactiveerd. Het formulier blijft defect.
Je kunt dit repareren. Je kunt uitzonderingen toevoegen voor React-invoervelden, na focus blur-events versturen en wachten tot het netwerk inactief is voordat je de status uitleest. Elke reparatie afzonderlijk is correct. Samen groeien ze uit tot een systeem dat steeds moeilijker te onderhouden is en steeds specifieker wordt voor de websites die je al hebt gezien.
Het diepere probleem is dat je aannames over hoe interacties horen te werken in de abstractielaag vastlegt en vervolgens ontdekt dat het web andere aannames hanteert.
Denk aan een betaalformulier van Stripe of Adyen dat in een cross-origin-iframe is ingebed. Je wrapper kan het niet rechtstreeks bereiken, omdat het een afzonderlijke origin heeft. Je tool read_text kan de interne status ervan niet waarnemen. Je tool type kan de invoervelden ervan niet benaderen. Een agent op basis van wrappers loopt hier vast. De abstractie is ontworpen voor het hoofddocument. De werkelijke taak bevindt zich op een plek die de abstractie niet kan zien.
Een vergelijkbare discrepantie doet zich voor in minder voor de hand liggende processen. Een door het framework beheerd keuzemenu reageert mogelijk helemaal niet op rechtstreekse klikken, omdat het zichtbare element niet het daadwerkelijke bedieningselement is. Mogelijk is een reeks toetsenbordgebeurtenissen nodig om de onderliggende statusovergang te activeren. Van buitenaf lijkt de UI klikbaar. De abstractie zegt: "Klik." Er gebeurt niets.
Of denk aan een modaal proces met meerdere stappen, waarbij updates van de zichtbare DOM achterlopen op wijzigingen van de interne status. De juiste volgende actie hangt af van een statusovergang die nog niet zichtbaar is in de elementen die je wrapper kan waarnemen. Een agent op basis van wrappers handelt daardoor te vroeg of leest een verouderde status uit, omdat die met een onvolledig beeld van het systeem werkt.
In al deze gevallen verbergt de abstractie de signalen die de agent werkelijk nodig heeft.
Een model dat op een lager niveau werkt, kan deze situaties wel aan: het inspecteert de live-DOM, redeneert over framegrenzen en stelt de interactiereeks voor die specifieke interface samen. Het model is niet per definitie slimmer. Het heeft alleen toegang tot de informatie die eerder was weggefilterd.
De verandering waar we naartoe werken is eenvoudig uit te leggen: in plaats van het model uit vooraf gedefinieerde acties te laten kiezen, geven we het een uitvoeringsomgeving op een lager niveau. Die begrenzen we met runtimebeleid in plaats van met abstracties.
Deze ontwerpkeuze komt voort uit een bredere verschuiving in de sector naar primitieve tools op een lager niveau. Die benutten het natuurlijke vermogen van de agent om tijdens runtime bij te sturen en hoogwaardige code te produceren, in plaats van vaste specifieke tools te gebruiken die wel robuust zijn, maar het aanpassingsvermogen van het model in verschillende omgevingen beperken.
Denk aan het succes van Claude Code als een van de belangrijkste tools van veel ontwikkelaars en aan de bredere verschuiving in de sector naar terminalagents. Het grootste voordeel van Claude Code is niet het model zelf, maar de harness op een lager niveau. Door het model minder, modularere tools op een lager niveau te geven, oftewel de terminal, presteert het beter bij het aanroepen van tools. Dat komt vooral doordat de agent kan redeneren en aangepaste scripts voor de actuele taak kan maken, in plaats van algemene tools te gebruiken die het contextvenster vervuilen.
Voor browserautomatisering betekent dit in de praktijk dat het model rechtstreeks de actuele paginastatus kan inspecteren, door frames kan navigeren en aangepaste interactiecode voor de huidige interface kan maken, in plaats van alles te vertalen naar een vaste reeks vooraf gebouwde acties.
Het model gedraagt zich minder als een kiezer en meer als een programmeur tijdens runtime. Het inspecteert de huidige status, redeneert over de interface en stelt de interactielogica voor die specifieke situatie samen. Het kan reeksen met meerdere stappen maken, zich aan ongebruikelijke processen aanpassen en resultaten valideren voordat het doorgaat. Als een actie mislukt, ziet het model de onderliggende fout en corrigeert het zichzelf. Dit is krachtiger en riskanter, maar sluit veel beter aan bij de werkelijke aard van het probleem.
Belangrijk is dat het systeem niet minder gedisciplineerd wordt wanneer de abstractielaag verdwijnt. De discipline verhuist alleen.
Werk dat eerder in het ontwerp van wrappers en de verwerking van uitzonderingen zat, verschuift naar drie plaatsen: de prompt (die een vorm van operationele training wordt), de runtime (die grenzen afdwingt voor onder meer het navigatiebereik, gevoelige acties en nieuwe pogingen) en de evaluatielaag (die niet alleen beoordeelt of de taak is geslaagd, maar ook of de tussenstappen correct waren). Minder kwetsbare abstracties. Sterkere omringende systemen.
Een gevolg van deze verschuiving is dat de productcode vaak eenvoudiger wordt, terwijl het systeem als geheel juist meer kan. In plaats van interactiepatronen vast te leggen in herbruikbare wrappers, stelt de agent tijdens runtime het benodigde gedrag samen. Je onderhoudt een kleine verzameling krachtige primitieve functies en een begrensde uitvoeringsomgeving, in plaats van een steeds groter aanbod van gespecialiseerde tools en logica voor uitzonderingen.
Dit verandert ook de manier waarop het systeem generaliseert. Een agent op basis van wrappers generaliseert goed naar taken die lijken op de wrappers die je al hebt gebouwd. Een agent in een begrensde runtime generaliseert naar taken die dezelfde uitvoeringsbasis delen, zelfs als de zichtbare interface anders is.
Interactie met bijvoorbeeld een zoekformulier, een boekingsproces of een instellingenpagina kan er op UI-niveau totaal anders uitzien. Maar onderliggend delen ze patronen: status uitlezen, gebeurtenissen activeren, resultaten valideren en asynchrone updates verwerken. Een systeem dat op dat niveau werkt, kan gemakkelijker tussen taken schakelen.
De herbruikbare component is niet de lijst met acties. Het is het vermogen van het model om de status te inspecteren, veilig te handelen en resultaten te verifiëren.
De duidelijkste les uit dit werk is dat betrouwbaarheid niet voortkomt uit meer hulpfuncties voor het model. Die ontstaat vaak juist door het minder, maar krachtigere primitieve functies te geven en die op de juiste manier te begrenzen. Te veel hulp legt aannames vast over hoe een taak moet worden uitgevoerd. Beperkingen definiëren veilige operationele grenzen en stellen het model in staat betere lokale oplossingen te vinden.
Een krachtigere uitvoeringsomgeving vereist ook een scherper veiligheidsmodel. Zodra de agent niet meer beperkt is tot een kleine reeks vooraf gedefinieerde acties, werkt die feitelijk rechtstreeks met echte software. Dat verandert het risicoprofiel onmiddellijk.
Bij het ontwerp moet je rekening houden met vier aandachtspunten:
Blootstelling van gegevens. Als de agent met echte interfaces werkt, komt die vaak gevoelige informatie tegen. Dat vereist een gedisciplineerde aanpak voor afscherming en toegangsbeheer. Gegevens mogen alleen worden getoond wanneer dat voor de uitvoering nodig is. Logs en traces moeten zorgvuldig worden behandeld, zodat de observatielaag niet het gevoeligste onderdeel van het systeem wordt.
Uitvoeringsbereik. Een krachtige agent mag niet zomaar overal kunnen opereren. In de praktijk betekent dit dat je begrenst waar die naartoe kan navigeren, tot welke domeinen die toegang heeft en met welke systemen interactie is toegestaan. Deze beperkingen moeten op runtimeniveau worden afgedwongen en mogen niet alleen als conventies in prompts staan.
Vertrouwen in de omgeving. Moderne interfaces kunnen misleidende of actief vijandige instructies, inhoud en processen bevatten. Prompt-injectie via pagina-inhoud vormt een reëel aanvalsoppervlak. Het systeem heeft een duidelijke hiërarchie van instructies, validatiecontroles en stopvoorwaarden nodig om te voorkomen dat de agent onbedoelde aanwijzingen opvolgt.
Spectrum van autonomie. Niet alle acties moeten volledig autonoom worden uitgevoerd. In veel productieomgevingen is het belangrijk autonomie als een spectrum te beschouwen. Het systeem kan bij het verkennen en uitvoeren sterk agentisch werken, terwijl voor bepaalde categorieën acties nog steeds goedkeuring nodig is.
Het onderliggende principe is eenvoudig: als je het model meer macht geeft, moet je het omringende systeem versterken. Autonomie zonder beleid is niet klaar voor productie.
We vroegen ons niet langer af: welke browseracties moeten we beschikbaar stellen?
We gingen ons afvragen: hoe kunnen we het model een volledige actieruimte bieden, en met welk runtimebeleid kunnen we die toch veilig houden?
Die nieuwe invalshoek verandert wat belangrijk is. Actietaxonomieën en de volledigheid van wrappers worden minder belangrijk. Runtimebeleid, observeerbaarheid en evaluatie op stapniveau worden belangrijker. Modelcapaciteiten en systeemontwerp kunnen elkaar niet vervangen. Naarmate modellen beter worden, wordt het werk van het systeem belangrijker, niet minder belangrijk.
Browseragents die in demo's werken, slagen vaak doordat de taak beperkt is en de omgeving meewerkt. Productiesystemen vereisen iets anders: begrensde uitvoering, geïnstrumenteerd gedrag en evaluaties die een correct resultaat van een toevallig succes kunnen onderscheiden.
Minder wrappers ontwerpen. Meer systeemengineering.
En hoewel we ons op browseragents hebben gericht, wijst dit op een bredere benadering van computergebruik als systeemdiscipline.