logoalt Hacker News

k9294 • today at 6:01 PM • 2 replies • view on HN

There is a notion right now of decoupling the agent loop from the sandbox, so the sandbox isn't waiting for request-response from the agent. This would probably be 90+% of all the agent work.

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.


Replies

NathanFlurry • today at 6:20 PM

Exactly this.

> Also, if you don't require a real Linux sandbox — you might actually emulate the environment

We built agentOS for this: https://rivet.dev/agentos/

It provides Linux-compatible sandboxing using V8 / WebAssembly. Supports full POSIX filesystems, networking stacks, and process trees.

apsurd • today at 6:36 PM

This is a very helpful explanation, thank you. The part about basically duck-typing an Agent's environment and tool access is particularly insightful.