Prêt pour les agents : voici le runtime que nous concevons.

Un agent qui vit uniquement dans un navigateur sans interface ne peut pas ouvrir Final Cut, ne peut pas glisser un fichier vidéo du Finder vers un outil de création, ne peut pas signer un PDF dans Aperçu, ne peut pas lancer un installeur .dmg ou .exe, ne peut pas accorder à une autre application l’autorisation d’enregistrer l’écran, ne peut pas choisir un fichier avec le sélecteur de fichiers du système, et ne survit pas à une boîte de dialogue inattendue de l’OS. Ce sont pourtant ces moments-là où se joue la plupart des vrais workflows, et où l’agent de navigateur sans interface échoue discrètement.

Les conteneurs virtualisés (le modèle d'« ordinateur d’agent » des grands laboratoires) comblent certaines de ces lacunes, mais en créent d’autres. L’image est en général un bureau Linux minimal avec quelques applications préinstallées ; tout ce qui sort de ce périmètre est inaccessible. Le conteneur n’a aucune continuité avec le travail réel de l’utilisateur : ses applications installées, ses comptes connectés, ses fichiers enregistrés, ses autorisations accordées. Chaque exécution d’agent démarre sur une machine vierge qui n’est pas celle de l’utilisateur.

La conception de Remio emprunte l’autre voie. Un agent connecté via le runtime que nous construisons obtiendrait le vrai bureau de l’utilisateur — le Mac, le PC ou la machine Linux sur lesquels il travaille réellement — par la même session de bureau à distance qu’un humain utilise déjà aujourd’hui. Toutes les applications installées seraient là. Tous les comptes connectés aussi. Tous les fichiers également. L’agent ne serait pas le locataire d’un environnement artificiel ; il serait l’invité du véritable poste de travail de l’utilisateur, aussi longtemps que celui-ci l’y autorise, pas un instant de plus.

Ce qui est livré aujourd’hui, c’est le flux en direct : l’écran de l’hôte, capturé en continu, encodé en matériel et transmis sur le même canal chiffré que celui d’un client humain. Un runtime d’agent réutiliserait ce même pipeline pour ses propres captures fixes — une seule image à la demande, ou simplement la région qu’un modèle sait déjà devoir regarder — au lieu de monter un second chemin de capture séparé. Cette réutilisation est un choix de conception arrêté, pas une affirmation sur ce qui existe aujourd’hui.

Pour les agents qui raisonnent mieux sur du texte que sur des pixels, la conception esquisse un mode transcription : le texte affiché à l’écran, renvoyé avec ses zones englobantes, produit par l’OCR natif de la plateforme (framework Vision sur macOS, API OCR de Windows sur Windows) plutôt que par un modèle de vision dans la boucle. Rien de tout cela n’a été construit. C’est à l’étude parce que cela permettrait à un agent de transformer une correspondance de texte en clic précis sans jamais envoyer d’image à son modèle — un vrai gain d’efficacité, si nous le réalisons bien.

Pour l’accès structuré de la plus haute fidélité, la conception esquisse aussi une lecture de l’arbre d’accessibilité de l’OS pour la fenêtre au premier plan — le même arbre que parcourt un lecteur d’écran : une hiérarchie étiquetée de boutons, de champs de texte, de menus et de rôles. Rien de cela n’existe encore non plus. Et dans chacune des versions que nous esquissons, la règle du pipeline de saisie s’applique aussi : une session d’agent verrait exactement ce que l’autorisation d’enregistrement d’écran de l’hôte permet déjà de voir à une session humaine, pas davantage. Si cette autorisation est désactivée pour un écran, l’agent ne recevrait rien de cet écran — comme un client humain aujourd’hui.

Chaque session Remio — humaine ou d’agent — démarrerait de la même manière : un humain lit un code à six chiffres affiché à l’écran de l’hôte et le saisit sur le client. Aucune conception à l’étude ne permet à un agent de créer sa propre session, de détenir un jeton qu’il pourrait renouveler en silence, ou de prolonger l’accès au-delà du moment où l’humain qui l’a jumelé décide d’y mettre fin. L’exécution suivante de l’agent exigerait un nouvel jumelage par l’humain — un nouveau moment « humain dans la boucle », à chaque fois, par conception.

Tant qu’une session d’agent est active, l’hôte comme le client afficheraient un indicateur permanent et sans équivoque — ainsi qu’une commande Arrêter qui met fin immédiatement à la session, accessible à la personne assise au clavier de l’hôte, et pas seulement à celle qui l’a lancée. Chaque action de l’agent serait inscrite dans un journal d’audit que l’humain peut consulter. Rien de tout cela n’existe dans le code livré aujourd’hui ; c’est le niveau que la conception doit atteindre.

La frontière des autorisations suit la même logique que les sections saisie et écran ci-dessus : une session d’agent hériterait exactement des autorisations de l’OS que respecte déjà une session humaine sur l’hôte — enregistrement d’écran, accessibilité — rien de plus large. Elle n’aurait pas de droit élevé qui lui soit propre, ni aucun moyen d’élargir le cadre que l’humain a déjà fixé pour l’application Remio. Si une capacité que nous concevons ne rentre pas dans cette frontière, elle ne sort pas.

La forme que nous retrouvons sans cesse est volontairement petite : quelques primitives de saisie (un clic, une touche), quelques-unes de vision (une image fixe, une région), une pour une lecture structurée de l’interface. C’est une esquisse, pas une spécification : rien n’est livré, et l’interface exacte reste ouverte. Ce à quoi nous nous engageons aujourd’hui, c’est la forme, pas la syntaxe.

L’indépendance vis-à-vis du modèle est une exigence de conception, pas une aspiration à laquelle nous songerons plus tard. Ce qui sortira fonctionnerait de la même façon que le modèle qui planifie le workflow soit Claude, GPT, Gemini ou un modèle que vous faites tourner vous-même. Nous ne construisons pas cela autour du format d’appel d’outils d’un seul fournisseur, car dès que nous verrouillons le runtime sur l’interface d’un modèle, nous avons fait le mauvais genre de promesse.

Le runtime du bureau et le runtime propre à l’agent sont deux choses différentes, et nous comptons qu’elles le restent. Remio serait ce qui amène les actions d’un agent sur un vrai bureau ; le modèle, la boucle de planification et l’endroit où elle s’exécute resteraient entièrement au choix de celui qui construit l’agent. Nous ne prévoyons ni d’héberger les modèles, ni de les facturer à l’usage, ni d’en contrôler l’accès.

Remio n’est pas fait pour un agent qui n’a besoin que d’un navigateur web — extraire des pages, remplir des formulaires, lire des tableaux de bord. Une session de bureau à distance complète est plus qu’un onglet de navigateur n’en demande, et Remio ne cherche pas à concurrencer cette catégorie.

Remio n’est pas fait pour un agent qui a besoin de dizaines d’environnements jetables — un par tâche, un état neuf à chaque fois, une exécution en parallèle. Remio est construit autour d’une session persistante jumelée par un humain, ce qui est la forme opposée : faible concurrence, forte continuité, vrai contexte utilisateur.

Si nous construisons l’Agent Runtime tel que cette page le décrit, ce serait la bonne réponse quand l’agent a besoin d’un vrai bureau d’OS avec des applications natives, les logiciels réellement installés par l’utilisateur, ses vrais comptes et ses vrais fichiers, et une frontière de session avec un humain dans la boucle. Des agents d’accessibilité qui pilotent un bureau pour un utilisateur en situation de handicap. Des tests qualité assistés par IA sur de vraies applications d’OS. Des workflows agentiques qui doivent utiliser un outil natif précis que l’utilisateur possède déjà. Toute tâche pour laquelle « utilise ma vraie machine, avec tout ce qu’elle contient, pendant que je supervise » est la formulation naturelle. Dans ces cas, une fois livré, Remio serait le runtime.