AI-agents op een echt extern bureaublad — de Agent Runtime, in ontwikkeling.

Een agent die alleen in een headless browser leeft, kan Final Cut niet openen, geen videobestand uit Finder naar een creatieve tool slepen, geen pdf ondertekenen in Voorvertoning, geen .dmg- of .exe-installatieprogramma uitvoeren, een andere app geen toestemming voor schermopname geven, geen bestand kiezen met de bestandskiezer van het systeem en geen onverwacht dialoogvenster van het besturingssysteem overleven. Dit zijn de momenten waarop de meeste echte workflows zich afspelen — en waar de agent in een headless browser stilletjes faalt.

Gevirtualiseerde containers (het "agent computer"-patroon van de grote labs) dichten sommige van die gaten, maar brengen hun eigen gaten mee. Het image is meestal een minimaal Linux-bureaublad met een handvol voorgeïnstalleerde apps; alles daarbuiten is onbereikbaar. De container heeft geen continuïteit met het werkelijke werk van de gebruiker — diens geïnstalleerde apps, ingelogde accounts, opgeslagen bestanden en verleende toestemmingen. Elke agent-run begint op een blanco machine die niet de machine van de gebruiker is.

Het ontwerp van Remio kiest de andere weg. Een agent die via de runtime verbinding maakt die we bouwen, zou het echte bureaublad van de gebruiker krijgen — de werkelijke Mac, pc of Linux-machine waarop de gebruiker werkt — via dezelfde externe-bureaubladsessie die een mens nu al gebruikt. Elke app die de gebruiker heeft geïnstalleerd zou er zijn. Elk account waarbij de gebruiker is ingelogd zou er zijn. Elk bestand zou er zijn. De agent zou geen huurder zijn van een synthetische omgeving; hij zou een gast zijn op het echte werkstation van de gebruiker, zolang de gebruiker hem binnenlaat — en geen moment langer.

Wat nu wordt geleverd, is de livestream: het scherm van de host, continu opgenomen, in hardware gecodeerd en verzonden over hetzelfde versleutelde kanaal dat een menselijke client al gebruikt. Een agent-runtime zou diezelfde pijplijn hergebruiken voor zijn eigen stilstaande opnamen — één frame op verzoek, of alleen het gebied waar een model al weet dat het moet kijken — in plaats van een tweede, aparte opnameroute op te zetten. Dat hergebruik is een ontwerpkeuze waarover we zijn uitgekomen, geen bewering over wat er nu bestaat.

Voor agents die beter redeneren over tekst dan over pixels schetst het ontwerp een transcriptmodus: tekst op het scherm teruggegeven met omkaderingen, gegenereerd met de eigen OCR van het platform (het Vision-framework op macOS, de Windows OCR-API op Windows) in plaats van een visiemodel in de lus. Hiervan is niets gebouwd. Het staat op de lijst omdat een agent er een tekstmatch mee in een nauwkeurige klik kan omzetten zonder ooit een frame naar zijn model te sturen — een echte efficiëntiewinst, als we het goed bouwen.

Voor de meest getrouwe gestructureerde toegang schetst het ontwerp ook een weergave van de toegankelijkheidsboom van het besturingssysteem voor het actieve venster — dezelfde boom die een schermlezer doorloopt: een gelabelde hiërarchie van knoppen, tekstvelden, menu's en rollen. Ook dit bestaat nog niet. En in elke versie die we schetsen, geldt dezelfde regel als bij de invoerpijplijn: een agentsessie zou precies zien wat de toestemming voor schermopname van de host een menselijke sessie al laat zien, niet meer. Staat die toestemming uit voor een scherm, dan krijgt een agent niets terug van dat scherm — net als een menselijke client nu.

Elke Remio-sessie — mens of agent — zou op dezelfde manier beginnen: een mens scant de QR-code of typt het Device-ID en de pincode die op het scherm van de host staan in Remio. Er is geen ontwerp in overweging waarin een agent zijn eigen sessie aanmaakt, een token bewaart dat hij stilletjes kan verversen, of toegang verlengt voorbij het moment waarop de mens die hem koppelde besluit te stoppen. Voor de volgende agent-run zou de mens opnieuw moeten koppelen — telkens een nieuw human-in-the-loop-moment, ontwerpmatig.

Zolang een agentsessie actief is, tonen zowel de host als de client een permanente, onmiskenbare indicator — en een Stop-knop die de sessie direct beëindigt, bereikbaar voor wie er ook aan het toetsenbord van de host zit, niet alleen voor degene die de sessie startte. Elke handeling van de agent zou worden vastgelegd in een auditlog die de mens kan inzien. Niets hiervan bestaat vandaag in uitgebrachte code; het is de lat waar het ontwerp overheen moet.

De toestemmingsgrens volgt hetzelfde verhaal als de secties over invoer en scherm hierboven: een agentsessie zou precies de rechten op OS-niveau van de host erven die een menselijke sessie al respecteert — Schermopname, Toegankelijkheid — niets breders. Hij krijgt geen eigen verhoogde toestemming en geen route om de grenzen te verruimen die de mens al voor de Remio-app heeft gesteld. Past een mogelijkheid die we ontwerpen niet binnen die grens, dan wordt ze niet geleverd.

De vorm waar we steeds op uitkomen, is bewust klein: een paar primitieven voor invoer (een klik, een toets), een paar voor zicht (een stilstaand frame, een gebied), één voor een gestructureerde UI-weergave. Dat is de schets, geen specificatie — niets ervan is uitgebracht en de exacte interface staat nog open. Waaraan we ons nu binden, is de vorm, niet de syntaxis.

Modelonafhankelijk zijn is een ontwerpeis, geen ambitie voor later. Wat er ook verschijnt, werkt op dezelfde manier of het model dat de workflow plant nu Claude, GPT, Gemini of iets is dat je zelf draait. We bouwen dit niet rond het tool-calling-formaat van één leverancier, want zodra we de runtime aan de interface van één model koppelen, hebben we de verkeerde belofte gedaan.

De bureaublad-runtime en de eigen runtime van de agent zijn twee verschillende dingen, en dat willen we zo houden. Remio zou het ding zijn dat de handelingen van een agent op een echt bureaublad brengt; het model, de planlus en waar het draait blijven volledig aan wie de agent bouwt. We zijn niet van plan zelf modellen te hosten, te meten of de toegang ertoe te beperken.

Remio is niet gebouwd voor een agent die alleen een webbrowser nodig heeft — pagina's scrapen, formulieren invullen, dashboards lezen. Een hele externe-bureaubladsessie is meer dan een browsertabblad nodig heeft, en Remio probeert niet in die categorie te concurreren.

Remio is niet gebouwd voor een agent die tientallen wegwerpomgevingen nodig heeft — één per taak, telkens een verse staat, parallelle uitvoering. Remio is gebouwd rond een blijvende, door een mens gekoppelde sessie, wat de omgekeerde vorm is: lage gelijktijdigheid, hoge continuïteit, echte gebruikerscontext.

Als we de Agent Runtime bouwen zoals deze pagina beschrijft, zou het het juiste antwoord zijn wanneer de agent een echt OS-bureaublad nodig heeft met native apps, de werkelijk geïnstalleerde software van de gebruiker, de echte accounts en bestanden van de gebruiker, en een sessiegrens met een mens in de lus. Toegankelijkheidsagents die een bureaublad bedienen voor een gebruiker met een beperking. AI-ondersteunde QA op echte OS-apps. Agentische workflows die een specifieke native tool moeten gebruiken die de gebruiker al bezit. Elke taak waarbij "gebruik mijn eigen machine, met alles erop, terwijl ik toezicht houd" het natuurlijke uitgangspunt is. Voor die gevallen zou Remio, zodra het verschijnt, de runtime zijn.