LoginSign Up
← Back to all sparks
R

Rivet

DEVOPS
Velocity7.5

agentOS is becoming infrastructure other agent platforms build on, not a Rivet feature

agent-infrastructuresandboxingwebassemblyruntimeactorsstorage
◆Current state
Rivet has consolidated around agentOS, a virtual operating system that gives agents a terminal, filesystem and networking on WebAssembly and V8 isolates inside a backend you already run, instead of a container or VM per agent session. The surrounding pieces are now in place: a package registry, an install path measured in microseconds, durable timezone-aware cron for actors, and an execution API that runs JavaScript and Python directly rather than shelling out to bash. Underneath it, the team is building its own storage layer — a zero-disk SQLite engine that keeps writes local-fast while cold pages tier out to object storage.
◆Where it's heading
The argument Rivet keeps making is an economic one: a sandbox holds a whole container open while the agent sits idle waiting on inference, which is the cost structure isolates already solved. That case is no longer only Rivet's to make — Vercel's Eve and Flue both shipped agentOS support within two days of each other, which moves agentOS from a product surface toward a layer other vendors depend on. The recent work has shifted accordingly, from proving the runtime to filling in what a runtime needs to be depended on: execution APIs, scheduling, and now durable storage.
◆Prediction
With the execution API and storage engine landing back to back, the next gap in the stack is state and data access for agents built on agentOS — expect the SQLite tiering work to surface as a product surface actors can call, not just an engineering post. A third platform adoption announcement in the same changelog format is the other pattern the entries support.

◆Recent moves

  1. 19d ago

    How We Built the First Zero-Disk, S3-Tiered Storage Engine for SQLite

    A build-log on the storage engine underneath agentOS: SQLite writes stay local-fast while cold data tiers out to S3, so no disk is provisioned per agent. It is the durability half of the same argument the runtime work makes — keep the per-agent footprint near zero and push what is idle into object storage. Framed as engineering writing rather than a shipped surface, but it describes real infrastructure rather than positioning.

  2. 22d ago

    Introducing agentOS Execution API for JavaScript and Python

    ⚡ SPARK

    agentOS gains a first-class execution API for Node.js and Python, so agents invoke a language runtime directly instead of routing everything through bash. This is the step that turns the virtual OS from a terminal emulation layer into a programmable runtime, and it lands right as two outside platforms adopt agentOS.

  3. 23d ago

    Run Your Harness Outside the Sandbox: Why and How

    A positioning essay arguing the agent harness belongs in your own backend rather than inside the sandbox. It restates the architectural case the changelog releases are built on, without shipping anything itself.

  4. 24d ago

    Sandboxes vs WebAssembly → Lambda vs Workers, Round Two

    Another round of the sandboxes-versus-isolates argument, drawing the analogy to Lambda reserving containers for idle work. It is the clearest statement of why Rivet built agentOS, but it is commentary rather than a change users can adopt.

  5. 27d ago

    Flue now supports agentOS

    Flue adds agentOS as an alternative to sandbox VMs for its agents, one day after Vercel's Eve did the same. Individually an integration; as a pair it is the evidence that the isolate-over-container bet is being taken up outside Rivet.

  6. 28d ago

    Vercel's Eve now supports agentOS

    Vercel's Eve ships agentOS support, running agents in the backend the customer already operates rather than in hosted sandbox VMs. The first outside adoption in this window, and the one that set up Flue's two days later.