What changed
On September 3, Vercel announced that Cursor Cloud Agents can run their tool execution in Vercel Sandbox instead of Cursor's hosted machines. Cursor still owns the agent harness, inference, and planning; Vercel supplies the execution environment where an agent clones a repository, edits files, and runs commands and tests.
The reference architecture combines a dedicated Firecracker microVM for each agent request with Vercel Functions and Vercel Workflow as a durable control plane. That control plane claims queued requests, provisions workers, monitors sessions, retries failures, and cleans up after completion. The result is a scale-to-zero worker pool without long-lived virtual machines, plus short-lived, user-scoped credentials inside each sandbox.
Why it matters
The interesting shift is architectural: the model provider no longer has to own the machine that executes the agent's tools. A coding agent can keep its reasoning loop in one service while its runtime is supplied by a separate, programmable compute layer.
That separation addresses three production problems at once:
- Elasticity: one isolated runtime can be created per request and disappear when the work is finished.
- Reliability: queued work and retries are handled as durable workflow state instead of an in-memory process.
- Containment: untrusted or agent-generated code runs inside an isolated microVM, with credentials scoped to the user and session.
Cursor's Cloud Agents API makes this boundary explicit: an agent can target a Cursor-hosted cloud environment or route execution to a named machine or worker pool. Its self-hosted documentation also makes the tradeoff clear—tool execution, local files, and local credentials stay with the worker, while the agent loop remains in Cursor's cloud.
Builder takeaway
For coding, research, or QA agents, model the run as a durable job rather than a chat request tied to one server. Enqueue the task, provision an isolated runtime, inject only the credentials and network access it needs, stream logs and artifacts, retry idempotent stages, and persist the final diff or result before teardown.
This pattern is useful even if you never use Cursor or Vercel: it gives the agent a replaceable execution layer. That makes it easier to change models, move workloads between cloud and private infrastructure, and keep the blast radius of generated code small.