agentOS : un système d'exploitation pour agents, embarqué comme bibliothèque

Le problème : un agent qui exécute du code sans sortir de votre backend

Faire tourner un agent qui écrit des fichiers et lance des commandes impose normalement une frontière : microVM, conteneur, virtualisation imbriquée. Le README d'agentOS décrit l'inverse : un VM qui vit dans votre processus, sans démarrage de microVM ni téléchargement de conteneur. La cible est l'équipe qui a déjà un backend Node.js et qui veut y intégrer un agent capable de lire et écrire des fichiers, plutôt que d'exploiter un service séparé avec sa propre authentification et son propre réseau. Le README résume la promesse par une phrase : « Give agents an operating system as a library. » La conséquence pratique est que les appels de l'agent vers votre code passent par des bindings, décrits comme de simples appels JavaScript et non comme un service réseau supplémentaire. Les identifiants restent sur l'hôte ; l'agent ne voit que les entrées et les sorties.

Ce que le runtime exécute réellement : isolates V8, WebAssembly et utilitaires POSIX

Le mécanisme visible dans le matériel fourni tient en deux couches. Le JavaScript invité tourne dans des isolates V8, et les outils compilés tournent en WebAssembly, le tout dans un seul runtime compact. Le README indique que les utilitaires POSIX courants sont livrés avec : coreutils, sed, grep, gawk, findutils, diffutils, tar et gzip. Un agent peut donc enchaîner des commandes shell sans que vous installiez une distribution. Node.js est aussi pris en charge : le README montre writeFile d'un fichier /hello.mjs puis exec("node /hello.mjs"), suivi d'un exec("cat /out.txt") qui renvoie « hi » dans stdout. Les agents intégrés cités sont Pi, Claude Code (beta), Codex (beta) et OpenCode, installés comme des paquets npm, par exemple @agentos-software/pi. Les permissions filtrent l'accès au système de fichiers, au réseau, aux processus et à l'environnement, et le README précise que les capacités sortantes comme l'egress réseau sont refusées par défaut. C'est le choix de conception le plus intéressant du projet : la valeur par défaut est fermée, pas ouverte.

Deux modes de déploiement : acteur Rivet ou agentos-core sans runtime d'acteur

Le paquet @rivet-dev/agentos exécute chaque VM comme un acteur Rivet, avec persistance, sleep/wake, multijoueur, URLs de prévisualisation et orchestration intégrées. Ce mode suppose le runtime d'acteur et un endpoint, que le client joint via createClient avec endpoint: "http://localhost:6420". Pour intégrer le contrôle du VM dans une application Node.js existante sans ce runtime, le README renvoie vers @rivet-dev/agentos-core : AgentOs.create() démarre un VM et renvoie un handle appelé directement. Ce sont deux profils d'usage distincts, et le choix n'est pas cosmétique : le premier apporte la persistance et la reprise après veille, le second vous laisse gérer vous-même le cycle de vie. Le README ne détaille pas ce que le mode embarqué perd exactement en termes de durabilité, et c'est une zone que la documentation devra clarifier avant une adoption en production.

Mise en route : les commandes et les clés de configuration du README

L'installation tient en une ligne : npm install @rivet-dev/agentos @agentos-software/pi. Le serveur se déclare avec agentOS({ software: [pi] }) puis setup({ use: { vm } }) et registry.start(). Le client se crée avec createClient<typeof registry>({ endpoint: "http://localhost:6420" }), récupère un handle via client.vm.getOrCreate("my-agent") et s'abonne aux événements de streaming avec conn.on("sessionEvent", ...). La session s'ouvre par handle.openSession({ agent: "pi", env: { ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY! } }), puis handle.prompt({ content: [{ type: "text", text: "..." }] }). La lecture du fichier produit passe par handle.readFile("/workspace/hello.js") et un TextDecoder. Le développement local se lance avec npx rivetkit dev, et les deux fichiers d'exemple s'exécutent avec npx tsx server.ts et npx tsx client.ts dans deux terminaux. Le point à retenir sur la configuration : la clé d'API du modèle est passée dans env au moment de openSession, donc elle transite par l'hôte et non par l'agent.

La limite structurelle : pas de noyau Linux, donc pas de navigateur ni de binaire natif

Le README est explicite sur le partage des rôles. agentOS est un VM léger dans votre processus ; un sandbox est un environnement Linux complet. Si votre charge de travail demande un navigateur, des binaires natifs ou des serveurs de développement, agentOS n'est pas le bon outil. Le projet ne prétend pas remplacer le sandbox : il propose le montage de sandbox, qui démarre un sandbox complet à la demande et monte son système de fichiers quand la charge le nécessite. Deux autres réserves viennent du matériel lui-même. D'abord, le README indique que le projet est en preview et que l'API est susceptible de changer ; trois versions publiées entre le 2 et le 9 septembre 2026, dont deux release candidates, confirment un rythme de mouvement rapide. Ensuite, les chiffres de performance du README (démarrage à froid, mémoire, coût) sont ceux du projet, mesurés selon une méthodologie que le README renvoie à une page dédiée ; je ne les ai pas reproduits, et ils ne doivent pas servir de base de décision sans lecture de cette méthodologie.

Face à un sandbox classique : la différence n'est pas la vitesse, c'est la frontière

La comparaison que fait le README avec E2B et Daytona porte sur des métriques, mais l'écart de conception est plus utile. Un sandbox type E2B ou Daytona vous donne une machine Linux complète : vous y accédez par le réseau, vous y installez ce que vous voulez, et la frontière est le réseau plus l'hyperviseur. agentOS déplace la frontière à l'intérieur du processus : les appels de l'agent vers votre code ne sont plus des requêtes HTTP mais des bindings, et les capacités sortantes sont refusées par défaut. Ce déplacement a un coût : vous héritez de la surface d'attaque de votre propre processus, et la granularité des permissions devient votre principale défense. Un sandbox conserve l'avantage de l'isolation par le noyau et de la compatibilité avec tout ce qui s'exécute sous Linux. Le montage de sandbox est justement la réponse du projet à ce compromis : garder agentOS pour l'orchestration légère et ouvrir un sandbox quand la charge l'exige.

Maintenance, versionnement et licence

Le dépôt est actif : dernier push le 9 septembre 2026, aucune archive, branche par défaut main. Le versionnement reste en 0.x, avec des release candidates publiées en parallèle des versions stables (v0.2.19 puis v0.2.20-rc.1). Concrètement, une mise à niveau peut casser des appels : le README prévient que l'API est susceptible de changer pendant la preview. Prévoyez de figer la version dans votre package.json et de lire les notes de version avant de monter de mineure, plutôt que de suivre le dernier tag. La licence est Apache-2.0, une licence permissive avec une clause de brevets explicite ; elle n'impose pas de publication de vos modifications, mais je ne donne pas d'avis juridique et il faut la lire en entier, notamment si vous redistribuez le paquet ou si vous le modifiez. Le coût d'exploitation dépend de l'hébergement : le README propose Rivet Cloud en gestion ou l'auto-hébergement, et les estimations de coût par seconde d'exécution qu'il publie supposent un agent par instance et un taux d'utilisation de l'hôte de 70 %, une hypothèse à vérifier contre votre propre trafic.

Conclusion éditoriale

agentOS convient aux équipes qui veulent exécuter du code d'agent dans un processus Node.js existant avec des permissions par défaut restrictives, et qui acceptent une API en preview. Il ne convient pas à celles qui ont besoin d'un noyau Linux complet, de navigateurs ou de binaires natifs : dans ce cas, gardez un sandbox et utilisez le montage de sandbox décrit dans la documentation. Avant d'adopter, vérifiez trois points précis : que la version v0.2.20-rc.1 correspond bien à la branche principale, que la politique de permissions par défaut bloque bien l'egress réseau dans votre configuration, et que la licence Apache-2.0 couvre l'usage que vous prévoyez.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rivet-dev/agentos on GitHub