The problem
An idea-to-app builder hands a coding agent a real machine, real packages, and real model access, then asks it to work unsupervised for an hour. That agent is the most dangerous user the platform will ever have.
It must never see platform keys. It must not spend without limit. And a crash, a deploy of the platform, or a lost sandbox must not throw away an hour of the user's work.
Architecture
The builder runs as a gated pipeline, available both as an app and as a white-label API. Each phase writes a versioned document, and the build phase hands those documents to a coding agent inside its own microVM.
Key decisions
Gates before code
Research, requirements, design, and a technical spec come first, and the user approves each one. By the time the agent writes code, it builds from an agreed spec instead of a one-line prompt. A failed step retries from that step, and follow-up changes go to the same warm agent session instead of regenerating the app.
A sandbox that holds a token, not a key
Each project gets its own microVM with an outbound allow-list: package registries, git, and the platform's own proxy. The agent reaches models through that proxy with a per-run token, which the platform stores only as a hash and which carries its own call budget.
Runs that survive crashes and deploys
A build runs detached from the request that started it and writes its progress to a log inside the sandbox. It sends a heartbeat, and if the heartbeat goes stale, another instance takes over the run with an atomic claim. Clients resume the event stream from the last event they saw. The workspace is saved as versioned snapshots, so a lost sandbox restores from the newest one.
Hard budgets on the agent
Every run has a limit on time, turns, and model calls. Sub-agents are switched off, so the agent cannot fork its way past the budget. Fallback to another model happens only before the first token, because a switch mid-stream would restart the answer.
The agent tests itself, then the platform tests the agent
The agent must prove its own API rejects bad input with a 400, not a 500. After the build, the platform calls every route itself and allows one repair turn for anything that fails.
Deploys that are verified before they go live
Only an allow-list of files ships, with build commands fixed by the platform. The build writes a SHA-256 manifest, the platform stages the deploy, checks the manifest, and only then promotes it. A secret found in the bundle stops the deploy. Each app gets its own serverless Postgres that scales to zero.
Results
- No provider key ever enters a sandbox.
- A crash or a platform deploy pauses a build instead of losing it.
- Every live deploy matches the manifest the build produced.
- Cost is visible per tenant and per phase, so the unit economics are known, not guessed.
Tradeoffs
Gates slow down a user who only wants to see something fast, so the early phases are kept short and streamed. A microVM per project costs more than shared containers, and the platform pays for it with idle sweeps that archive quiet workspaces. Fixed build commands limit what an app can do at deploy time, and that limit is the point.