Skip to content

Isolated Agent VMs

Design choice: give every coding agent its own VM rather than sharing a development environment via git worktrees. The scaling substrate for the software-factory.

Two options

  1. Git worktrees on one machine — shallow copies of the codebase share services (database, cache, user management). Cheaper, but "you're still going to have to branch every database or cache or user management to have reproducible and separate environments." Side effects between branches.
  2. Full VM per agent — agent's own database, cache, auth state, dev server, plus the codebase. Pure. Isolated. Can scale to hundreds or thousands. Cursor runs "multiple thousands a day" this way internally.

Trade-off

  • More expensive per agent.
  • Much more setup work to make your dev environment reproducible (orbstack + postgres + redis + clickhouse + electron + UI layer, all reproducible from a snapshot).
  • Once built, it scales effectively infinitely.

Zakariasson's recommendation: "It is more expensive. It's going to take a lot more work to set up your factory or your environment to support this. But once you have it set up properly, you can scale this to like 100 or a thousand agents."

The internal CLI trick

Cursor exposes cursor dev tool backend start / cursor dev tool frontend start as skills the agent can call. These abstract away all the orchestration (orbstack, clickhouse, postgres, redis, electron). Agent doesn't need to know — it just needs the verb.

This is a general pattern: wrap your messy environment startup behind agent-accessible skills. Same reasoning as onboarding docs for humans, but executable.

Cross-references