agentOS: Agenten als Bibliothek im eigenen Backend, ohne Sandbox

Welches Problem agentOS löst und für wen

Coding-Agenten laufen üblicherweise in einer Sandbox: MicroVM booten, Container ziehen, Netzwerk regeln. Das kostet Kaltstartzeit und Speicher pro Instanz, und die Anbindung an die eigene Anwendung läuft über eine weitere Netzwerkgrenze. agentOS setzt genau dort an. Die README beschreibt das Projekt als leichtgewichtige VM, die im eigenen Prozess läuft, statt als vollständige Linux-Umgebung. Zielgruppe sind Backend-Teams, die Agenten in eine bestehende Node.js-Anwendung einbetten und deren Funktionsaufrufe direkt aus dem Gast heraus erlauben wollen. Der zweite Teil der Zielgruppe sind Teams, die mehrere Agenten parallel betreiben und die Kosten pro Ausführungssekunde senken wollen. Die README nennt dafür 92x schnellere Kaltstarts und 47x weniger Speicher gegenüber Sandbox-Anbietern. Diese Zahlen stammen aus einer eigenen Benchmark-Seite mit dokumentierter Methodik; sie sind Herstellerangaben und keine unabhängige Messung. Wer die Zahlen als Einkaufsargument nutzt, sollte die Reproduktionsschritte auf agentos-sdk.dev/docs/benchmarks selbst nachfahren.

Wie die Runtime aufgebaut ist: V8-Isolates, Wasm und Bindings

Der Mechanismus lässt sich aus der README recht genau rekonstruieren. Gast-JavaScript läuft in V8-Isolates, kompilierte Werkzeuge laufen als WebAssembly, beides in einer gemeinsamen Runtime. Es gibt keine MicroVM und keine verschachtelte Virtualisierung; die README spricht von Warm-VM-Erstellung im einstelligen Millisekundenbereich und Tens of Megabytes pro VM. Die Anbindung an den Host läuft über Bindings: Der Agent ruft Host-Funktionen als gewöhnliche JavaScript-Aufrufe auf, nicht über einen separaten Netzwerkdienst. Credentials bleiben damit auf dem Host, der Gast sieht nur Ein- und Ausgaben. Für die Rechteverwaltung gibt es Permissions, die Dateisystem-, Netzwerk-, Prozess- und Umgebungszugriff steuern. Netzwerk-Egress ist standardmäßig verweigert. Das ist die wichtigste Designentscheidung im ganzen Projekt: Der Agent ist kein vertrauenswürdiger Prozess, sondern ein Gast mit explizit zu erteilenden Fähigkeiten. Wer Bindings und Permissions nicht konfiguriert, bekommt einen Agenten, der nach außen nichts darf. Das ist als Default sinnvoll, kostet aber Einrichtungsaufwand, der in der README nur verlinkt und nicht ausgeführt wird.

Quickstart: npm-Paket, Actor-Registry und zwei Prozesse

Die Installation erfolgt über npm install @rivet-dev/agentos @agentos-software/pi. Gängige POSIX-Werkzeuge wie coreutils, sed, grep, gawk, findutils, diffutils, tar und gzip sind laut README bereits enthalten. Auf der Serverseite wird mit agentOS({ software: [pi] }) eine VM erzeugt und über setup({ use: { vm } }) in eine Rivet-Actor-Registry gehängt; registry.start() startet den Dienst. Der Client nutzt createClient<typeof registry>({ endpoint: "http://localhost:6420" }) und holt sich mit client.vm.getOrCreate("my-agent") ein Handle. Danach folgen handle.connect() für Streaming-Events, handle.openSession({ agent: "pi", env: { ANTHROPIC_API_KEY: ... } }) und handle.prompt(). Dateien lassen sich mit handle.writeFile() und handle.readFile() austauschen, Shell-Befehle mit handle.exec(). Der README zeigt beides, inklusive node /hello.mjs und cat /out.txt. Lokal startet man den Server mit npx tsx server.ts, den Client mit npx tsx client.ts. Für den Betrieb ohne Actor-Runtime verweist die README auf @rivet-dev/agentos-core mit AgentOs.create(). Wer keinen Rivet-Actor-Layer will, sollte diesen Pfad zuerst prüfen, weil er die Persistenz- und Sleep/Wake-Funktionen des Hauptpakets nicht mitbringt.

Grenzen: Preview-Status, fehlende Details und der falsche Einsatzfall

Die README sagt selbst, dass agentOS sich in Preview befindet und die API sich ändern kann. Das ist die zentrale Einschränkung. Wer heute auf v0.2.x aufsetzt, muss damit rechnen, dass Signaturen sich zwischen Minor-Releases verschieben. Der Versionsverlauf stützt das: v0.2.19 und v0.2.19-rc.1 liegen wenige Stunden auseinander, v0.2.20-rc.1 folgt eine Woche später. Ein Release-Kandidat kurz nach einem stabilen Release deutet auf einen schnellen Zyklus hin. Zweite Grenze: Die README beschreibt Permissions und Bindings nur als Links, ohne Beispielkonfiguration. Wie eine Permission-Regel konkret aussieht, lässt sich aus dem vorliegenden Material nicht sagen. Dritte Grenze: agentOS ist ausdrücklich keine vollständige Linux-Umgebung. Wer Browser, native Binaries oder Dev-Server im Gast braucht, ist hier falsch. Die README nennt dafür Sandbox-Mounting als Ausweg: Bei Bedarf wird eine vollständige Sandbox gestartet und deren Dateisystem eingebunden. Das ist ein zusätzlicher Betriebspfad, der die Kosten- und Latenzvorteile relativiert, sobald er greift.

Abgrenzung zu Sandbox-Anbietern und zum Rivet-Cloud-Pfad

Der Unterschied zu Sandboxes ist nicht nur die Geschwindigkeit, sondern die Architektur. Eine Sandbox ist ein vollständiges Linux-System mit eigenem Kernel-Kontext; agentOS ist ein Prozess in der eigenen Anwendung. Daraus folgt der unterschiedliche Integrationsweg: Bindings statt Netzwerkdienst, Permissions statt Netzwerkregeln auf VM-Ebene. Der Preis dafür ist die geringere Allgemeinheit. Ein Sandbox-Anbieter liefert eine Umgebung, in der fast alles läuft; agentOS liefert eine Umgebung, in der genau das läuft, was als Software-Paket eingebunden ist. Die README listet Pi, Claude Code (Beta), Codex (Beta) und OpenCode als eingebaute Agenten. Wer einen Agenten außerhalb dieser Liste braucht, muss prüfen, ob er sich als Software-Paket einbinden lässt. Beim Deployment gibt es zwei Wege: npx rivetkit dev lokal, dann entweder Rivet Cloud für verwaltete Infrastruktur oder Selbsthosting. Die README nennt Rivet Cloud explizit als Option, ohne Preise oder Betriebsdetails zu nennen. Wer die Kostenrechnung aus den Benchmarks als Argument nutzt, sollte beachten, dass sie für selbstgehostete Ausführung auf AWS oder Hetzner gilt und nicht für den verwalteten Pfad.

Wartung, Versionierung und Lizenz

Der letzte Push liegt laut Repository-Metadaten auf dem 9. September 2026, das letzte stabile Release v0.2.19 auf dem 2. September 2026. Der Abstand zwischen stabilem Release und nächstem Release-Kandidaten beträgt eine Woche. Für ein Projekt in Preview ist das ein normaler Rhythmus, für adoptierende Teams bedeutet es aber, dass Upgrade-Aufwand eingeplant werden muss. Die Lizenz ist Apache-2.0, also eine permissive Lizenz mit Patentklausel und ohne Copyleft-Pflicht für abgeleitete Werke. Das ist für kommerzielle Einbettung günstig. Wer den Code verändert und weitergibt, muss die Lizenzhinweise beibehalten. Rechtliche Beratung ersetzt das nicht; die konkreten Pflichten stehen im Lizenztext. Ein Hinweis auf den Reifegrad: Die README verlinkt eine Registry, eine Dokumentationsseite und einen Discord, aber das vorliegende Material enthält keine Angaben zu Maintainer-Anzahl, Release-Kadenz über längere Zeiträume oder unterstützten Node-Versionen. Wer diese Punkte für die Entscheidung braucht, muss sie im Repository selbst nachsehen.

Für wen sich der Einstieg lohnt und was zuerst zu prüfen ist

Der stärkste Fall für agentOS ist ein Node.js-Backend, das bereits eine Agenten-Schleife betreibt und die Netzwerkgrenze zur Sandbox loswerden will. Der zweite Fall ist ein Team, das viele kurzlebige Agenten ausführt und die Speicherkosten pro Instanz senken muss. Der schwächste Fall ist ein Team, das eine allgemeine Ausführungsumgebung für beliebige Workloads braucht. Bevor man das Paket in eine Produktionspipeline hängt, sollten drei Dinge geklärt werden. Erstens: Wie stabil ist die API über die nächsten Minor-Releases? Die README warnt selbst vor Änderungen. Zweitens: Wie sehen Permissions-Regeln konkret aus, und reicht der Default (Netzwerk-Egress verweigert) für den geplanten Agenten? Drittens: Wird der Sandbox-Mounting-Pfad gebraucht, und falls ja, wie verhält sich dann die Kostenrechnung? Ein sinnvoller erster Schritt ist der lokale Quickstart mit npx rivetkit dev, einem Pi-Agenten und einem einzigen Prompt, der eine Datei schreibt. Erst danach lohnt die Frage nach Deployment und Skalierung.

Redaktionelles Fazit

Für Teams, die Coding-Agenten in eine bestehende Node.js-Anwendung einbetten und dabei Credentials auf dem Host behalten wollen, ist agentOS einen Prototyp wert: npm install @rivet-dev/agentos, dann npx rivetkit dev lokal. Wer Browser, native Binaries oder Dev-Server im Gast braucht, sollte bei einer Sandbox bleiben oder den Sandbox-Mounting-Pfad prüfen. Vor dem Produktiveinsatz zuerst klären, ob die Preview-API-Stabilität und die Apache-2.0-Lizenz zum eigenen Release-Zyklus passen.

Offizielle Quellen

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