> Have you had agents like claude code , codex etc all fully running in agent-os?

We have gotten them all working inside of agentOS. However, we found it's a better architecture to run the agent loop outside of agentOS and expose it as tools. The trust boundary & blast radius of running the agent inside the sandbox makes it difficult.

Also, the memory overhead of running individual Claude Code instances is nuts, it's better to run the agents in a single process using tools.

I wrote a bit more on it here: https://rivet.dev/blog/2026-07-27-run-your-harness-outside-t...

> Also with the s3 backing changes, it reminds me a lot of the work done on celld, good to see more self-hostable durable objects out there.

Appreciate it!

Rivet has a much different architecture than most S3-backed databases. Having an object-per-actor doesn't scale well with cost and performance, so we built a SSD tiered storage engine instead: https://rivet.dev/changelog/2026-10-26-introducing-rivet-3-0...

Ping me on Discord if you give it a try, would be fun to catch up: https://rivet.dev/discord

If you combine this with products like Sprites from Fly.io (or OSS version - agent substrate), where you pay only per execution request in a sandbox, you can have huge savings compare to the event loop inside the sanbdox. You will be billed only for request executions (tens of milliseconds per read/write, hundreds of milliseconds per search, etc.) and zero for all the waiting time during the the inference phase.

Also, if you don't require a real Linux sandbox — you might actually emulate the environment, e.g. just-bash idea with linux-like environment to give agents something that looks like their native habitat, but under the hood, it can be just CF Durable Objects SQLite or whatever else.

Probably(?) almost all knowledge work doesn't require a Linux sandbox. You can just build a document reading and editing agent that does tool calls and connects to other products via MCPs, APIs, etc. And lightweight actors make a lot of sense to me in these cases.

> Wouldn't an agent in any capacity need a sandbox runtime to do agentic work?

Developers on Rivet use 3 different patterns:

- Just agents: many agents just need tools, such as customer support or personal agents

- Agents with lightweight sandbox: Rivet provides a V8 / WebAssembly sandboxing library for running JS & Python with a filesystem, which covers most workloads like data analysis, file processing, evals, and code mode (https://rivet.dev/agentos/)

- Agent outside of the sandbox: expose the sandbox to the agent as tools, which is better for blast radius, trust boundary, and orchestration (see below)

> Is the idea that state/memory/context and runtime env are separate concepts in rivet?

Exactly, Rivet Actors support running the harness outside of the sandbox. It's often referred to "separation of head from the hands."

I wrote a bit about why a while back: https://rivet.dev/blog/2026-07-27-run-your-harness-outside-t...

> When you say "sandboxes are too slow" do you mean needing to boot the sandbox to get back Agent state?

Specifically coldstarts. As LLMs are getting faster and have more realtime use cases, sandboxes are become the bottleneck on time to interactive for an agent.

Instead, we provide an optional agent library that runs Pi Durable on top of actors (https://rivet.dev/agents/docs/quickstart/) or you can write your agent from scratch if you choose.