Coding Agents
Give each coding session a sandbox, a filesystem, and durable memory on Rivet Actors.
A coding agent needs somewhere to run commands and somewhere to remember what it already did. On Rivet both belong to the same object: one Actor per coding session, holding the transcript and owning a sandbox whose filesystem survives between turns.
One Actor per session
Key the agent Actor by session id, so agent.getOrCreate([sessionId]) always reaches the same conversation (see Actor Keys). The transcript, the run status, and the sandbox session id live in that Actor’s persistent state, so a restart resumes the session instead of starting a new one. There is no separate session database to keep in sync.
The sandbox is an Actor too
The sandbox comes from rivetkit/sandbox and shares the agent’s key, which makes the agent-to-sandbox mapping implicit in the key space. It runs the coding agent (Codex by default) inside Docker, Daytona, or E2B, and owns the filesystem and process state for that session. The agent Actor submits a prompt, awaits the sandbox round trip, and broadcasts the result to connected clients as an event.