Technical architecture
Start simple, then scale the parts that need it
Most tools in this space pair a managed sandbox with one agent service and deploy to hosts that already exist. Architect 2.0 starts the same way. Heavier pieces come later, each tied to a clear trigger. The full reasoning is in docs/ARCHITECTURE.md.
1. What we would ship first
| Part | v1 choice | Buy or build | Why |
|---|---|---|---|
| Sandboxes | E2B (managed Firecracker microVMs), one per active project | Buy | AI-written code is untrusted and agent frameworks need real Linux and Python. Managed sandboxes give that in days, not months. |
| Agent loop | A job queue inside our API service. Each run: plan, act, verify, commit. Run state saved in Postgres | Build | This is the product. Keeping it in one service makes it easy to change quickly. |
| Models | A gateway module in the API (AI SDK or LiteLLM) with one message and tool format | Build (thin) | Switching Claude, GPT, Gemini or open-source becomes a setting, not a rewrite. |
| Live preview | Sandbox port URLs behind a small Cloudflare Worker proxy | Build (small) | Checks the viewer has access, wakes paused sandboxes, keeps previews on their own domain. |
| Realtime | WebSocket from the API; Redis pub/sub between workers | Build | Streams the build timeline, logs and terminal to the browser. |
| GitHub | GitHub App with short-lived tokens and webhooks. Every agent turn is a commit on a branch | Build | Git is the source of truth: undo, export, pull requests, no lock-in. |
| User app hosting | Front ends on Vercel or Cloudflare; backends and agents on Fly Machines or Cloud Run; Neon for each app's database | Buy | These already scale to zero and roll back. No reason to build hosting on day one. |
| Architect itself | Web app on Vercel, API and workers as containers on Cloud Run, Supabase Postgres, Redis, S3 | Buy | Small team, few moving parts, easy to operate. |
2. What changes as it grows
None of these are needed on day one. Each one is added when its trigger shows up in the numbers.
When
Agent runs last hours and wait on people (approvals, questions)
Then
Move runs from the job queue to Temporal for durable, resumable workflows
When
The sandbox bill becomes a top-3 cost, or enterprise needs VPC
Then
Self-host Firecracker on bare metal behind the same sandbox interface
When
Teams need spend caps, bring-your-own-key and per-app metering
Then
Split the model gateway into its own service
When
Thousands of deployed apps and hosting margin matters
Then
Run user apps on our own scale-to-zero cluster (Knative)
When
Agent traces and usage outgrow Postgres
Then
Send them to ClickHouse
When
One region is saturated or customers need data residency
Then
Split into regional cells with their own sandboxes and workers
3. Target architecture at scale
Where the design ends up once all of the above has happened: thousands of builders at once, many regions, enterprise requirements.
4. This prototype vs. the real system
| Area | In this prototype |
|---|---|
| Authentication | Real: Supabase Auth with email magic link and GitHub / Google OAuth |
| Database | Real: Supabase Postgres with row-level security (projects, profiles, published apps) |
| Plan generation | Real LLM call through a small model gateway (Anthropic, OpenAI, Gemini), with an offline fallback |
| Attachments | Real: files and images are read in the browser; text files are passed to the planner as context |
| GitHub | Real repo listing and create-repo-and-push when signed in with GitHub; pull requests simulated |
| Sandbox, build, preview | Simulated with realistic events, timeline and progressive rendering |
| Code view | Real Monaco editor over generated framework code; simulated terminal |
| Deploy | Full flow; the deployed app is served at /apps/<slug> from the stored plan |