How Prod AI runs in production.

The eight flows on the diagram

1. 1Describe

   The studio sends the brief through the API gateway. Nothing runs yet: the planner returns a Blueprint and a priced Work Order.

2. 2Plan

   The orchestrator starts a durable workflow. The harness asks the model gateway, which picks a model per task and meters every call.

3. 3Build in a sandbox

   Approved work runs inside the project's microVM: write files, install, run, test, rehearse agents. Every step is checkpointed.

4. 4Live preview

   The preview proxy maps the project's subdomain to the sandbox dev server, including WebSockets for hot reload.

5. 5Show the work

   File, test and step events stream back through the realtime hub, so people see progress in plain English, not a spinner.

6. 6Branch + PR

   Each Work Order becomes a branch and a pull request through the GitHub App. Engineers' pushes sync back into the Blueprint or become code they own.

7. 7Ship

   Preflight passes, the deploy service builds one immutable release and rolls it out to Prod Cloud, Vercel or your VPC.

8. 8Governed agents

   The agent gateway is every live app's only way out: credentials, approval gates, caps and traces. Model calls use the runtime's own model gateway.

Sandboxing

One microVM per project, because the code is untrusted.

• Firecracker microVMs

  Chosen

  Isolation

  Own kernel per project

  Start

  ~150 ms from snapshot

  Fit for agentic apps

  Runs Node and Python agents, real ports, persistent disk

• gVisor containers

  Fallback

  Isolation

  User-space kernel

  Start

  ~1 s

  Fit for agentic apps

  Good isolation, some syscall and I/O overhead

• Plain Docker

  Rejected

  Isolation

  Shared host kernel

  Start

  ~1 s

  Fit for agentic apps

  One escape reaches every tenant

• Browser WebContainers

  Rejected

  Isolation

  Browser tab

  Start

  Instant

  Fit for agentic apps

  Node only: no Python agents, no long-running jobs

Scale

Thousands of people at once, without thousands of idle machines.

• The control plane is stateless; long work lives in durable workflows, so a pod restart never loses a build.
• Sandboxes suspend to a snapshot after 10 idle minutes and resume in about 150 ms from a warm pool.
• The model gateway queues by priority per provider and key, fails over between providers, and caches prompts.
• Events fan out over NATS; Postgres uses row-level security, read replicas and partitioned event tables.

Honest about the seams

What the prototype runs today, and what production adds.

Real runs in the live prototype. Stand-in is simulated or sandboxed, and labelled in the product. Designed is specified in ARCHITECTURE.md and not built yet.

• Studio, auth, data

  Real

  In the live prototype

  Next.js 16 on Vercel Hobby, Supabase Auth (Google, email link, guest sessions you can keep), Postgres with row-level security on every table. One server-only admin connection writes only the rows people must not: the spend meter, rate limits, budget holds, published sites, abuse reports and published apps' records

  In production

  The studio backend runs in each regional cell (service identities, residency, long-lived streams); Vercel keeps the marketing site. Plus SAML SSO, SCIM and regional data residency

• Planner

  Real

  In the live prototype

  Claude picks the kind of app. For a business app it plans a structured Blueprint, streamed live, and code expands it deterministically and validates every reference; for anything else it writes real React files, streamed file by file. Guests start from a starter plan

  In production

  Same contract, routed through the model gateway

• Change requests

  Real

  In the live prototype

  Claude returns typed edits; code resolves names and emits validated operations, with one self-repair retry; each change has a fixed price, Apply and Undo, and makes a new version

  In production

  Same, executed by the harness in a sandbox; parallel Work Orders rebase onto a versioned Blueprint

• Model gateway

  Model switch and budgets: realRouting gateway: designed

  In the live prototype

  One getModel() seam that picks the model from the environment. Every call passes a rate limit and holds its cost against per-person and site-wide 24-hour budgets; failed calls are metered too. One provider (Anthropic) and no gateway service

  In production

  A gateway service: routing by task, eval-gated switches, failover in the middle of a tool loop, prompt caching, BYOK, and a separate deployment for live apps

• Approvals and the agent gateway

  Approval gates: realProduction gateway: designed

  In the live prototype

  Claude + AI SDK tool approval, signed by the server: tools marked “Ask first” pause for a person. Try it runs on sample data; helpers in published apps work on that app's records and send email only after a person says yes. Other outside connections aren't real yet, and nothing holds credentials or controls egress

  In production

  Every production tool call passes an egress gateway that holds the credentials, enforces approvals and caps, tracks untrusted content per run, and traces the call

• Build + repair

  Builds, test runs, repairs: realTool loop in microVMs: designed

  In the live prototype

  A business app's build checks every reference in the plan, compiles the generated code with esbuild, and has Claude play and judge each AI helper's test runs (price shown first); a real failure gets a free fix and a free replay. A code app is compiled and bundled with esbuild in about 15 ms, and Claude repairs real build and runtime errors for free. Generated business-app code is compiled, not executed

  In production

  Full tool loop inside microVMs with verifier and budgets

• Sandbox + preview

  Code apps' browser sandbox: realServer microVMs: designed

  In the live prototype

  A code app runs in its own page with its own Content Security Policy and an opaque origin (no cookies, no access to the studio), talking to Prod AI only by postMessage. A business app's preview renders the Blueprint with the spec renderer; no generated business-app or imported code runs

  In production

  Firecracker microVM per project behind the preview proxy; imported repos run as themselves, with a preview per exposed port

• GitHub

  Public repo analysis: realPushes, PRs, sync: sandboxed

  In the live prototype

  Reads any public repo, detects stack and agent frameworks, maps its agents, writes House Rules; pushes and PRs are sandboxed

  In production

  GitHub App with a branch and worktree per Work Order, a merge queue and two-way sync

• Deploy and published apps

  Public /live URL, records, rollback: realImmutable releases: designed

  In the live prototype

  A public /live/… URL serves a published Blueprint snapshot, or a code app's published build in its sandbox, with rollback, real records (up to 2,000 per app, with undo) and team screens for invited people. Publishing checks the live link answers. Vercel and VPC targets are sandboxed

  In production

  Immutable releases, canary rollout, instant rollback, and a database per app