Agent Control Planes Should Not Live in the Sandbox
The outside-the-VM agent pattern maps to joelclaw's workload split: durable controller owns lifecycle, sandbox owns execution.
Vercel Labs Open Agents is a reference app for running background coding agents on Vercel: web UI, durable agent workflow, sandbox orchestration, and GitHub integration in one forkable repo.
The clever bit is the boundary: the agent is not the sandbox. The agent runs outside the Vercel Sandbox and talks to it through tools for files, search, shell commands, tasks, skills, and web access. The sandbox stays a plain execution environment: filesystem, git, dev server, preview ports, hibernation, resume. The control plane stays somewhere else.
That split matters because it keeps the lifecycle from turning into mud. A chat request starts a workflow, each turn can continue across persisted steps, active runs can reconnect to an existing stream, and the sandbox can hibernate independently. That’s a useful shape for joelclaw: durable runtime outside, disposable execution inside, fewer “where the fuck is the state?” problems.
It also has the boring-but-important product pieces: Better Auth for auth, Vercel OAuth sign-in, GitHub App installation tokens for repo access, optional auto-commit/push/pull request creation, read-only session sharing, optional ElevenLabs transcription, and optional Redis/Vercel KV skills metadata caching. Not magic. Just a clean reference architecture with the seams showing.
Key Ideas
- Open Agents models a coding-agent app as web app → durable workflow → sandbox VM, which keeps UI, orchestration, and execution separate.
- The agent runs outside the sandbox and controls it through tools, so the VM does not become the agent control plane.
- Chat requests start a Vercel Workflow run instead of executing the agent inline inside a request lifecycle.
- Runs support streaming, cancellation, and reconnection to existing workflow state, which is the part that makes background coding work feel less like duct tape.
- Vercel Sandboxes expose common preview ports like
3000,5173,4321, and8000, can use a base snapshot, and hibernate after inactivity. - GitHub App integration enables repo cloning, branch work, optional commits, pushes, and pull requests after a successful run.
- The repo is meant to be forked and adapted, not consumed as a hidden platform black box.