The studio
What did the studio learn building Sandboxer?
Sandboxer, cloud computers for AI agents, is built and run the way North Bay Ventures builds everything: agents write, review and ship most of the work, and a person approves the decisions that are hard to undo. Building a product for agents with agents taught a few lessons that now apply across the studio.
Updated November 14, 2026
Why build Sandboxer at all?
Because AI agents need somewhere safe to run code, and lots of them at once. The studio looks for problems that AI has just made newly urgent, and an agent that installs packages, runs tests and starts servers needs a full machine where its mistakes can't reach anything else. Each Sandboxer sandbox is a full Ubuntu microVM with root, Docker and SSH. See how we build companies.
Lesson 1: Build every interface for agents first
An agent can't click through a dashboard. So everything Sandboxer does is reachable without one: a REST API described by an OpenAPI file, the sbx CLI with JSON output, TypeScript and Python SDKs, and an MCP server hosted at sandboxer.com/mcp. Coding agents such as Claude Code and Codex come installed in every sandbox. The same rule now shapes Transformer and Flagger.gg; see how to make a product AI agents can use.
Lesson 2: Make the safe thing the default
Agents forget things, so the product has to remember for them. Every sandbox stops on its own an hour after it starts unless you change that, an idle sandbox pauses itself with its memory, and a stopped one costs nothing for compute. API keys can be scoped to one sandbox and a few actions, with an expiry. A sandbox started with no secrets holds none of your credentials. None of this depends on the agent being careful. See how to stop an AI agent from overspending.
Lesson 3: Publish facts with dates, and keep them current
AI assistants quote what they read, so a stale number does real damage. Sandboxer's guides open with a short answer and date their measurements, and its llms.txt and llms-full.txt carry the current facts in one place. This site treats those files as the only source of truth for Sandboxer: a daily check compares every fact here against them and fixes anything that has drifted. When Sandboxer changed its plans or its defaults, the pages here followed. See what answer engine optimization is.
Lesson 4: Ship behind flags, straight to production
There's no staging server. Changes merge through pull requests and go straight to production, with risky ones switched off behind a feature flag until they're ready. The flag system built for Sandboxer and Transformer became its own product: Flagger.gg is built from the flag system that runs both in production. See feature flags instead of staging.
Lesson 5: Keep a person on the decisions that are hard to undo
Agents do the routine work of running Sandboxer, but prices, plans, legal terms and launches wait for Jon's yes, and an approval passed along by another agent counts only if it quotes his words. Even a page on this site that restates Sandboxer's prices goes to Sandboxer's chief of staff before it's published. See how our AI agent teams ship code and how the studio uses agents.
Frequently asked questions
Was Sandboxer built by AI agents?
Largely. Agents write, review and ship most of the code and run routine operations through pull requests and automated checks, while a person approves prices, legal terms and launches.
How are Sandboxer and Flagger.gg related?
Flagger.gg is built from the flag system that runs Sandboxer and Transformer in production.
What is the biggest lesson from building for agents?
Put the guardrails in the product, not the agent: deadlines, idle pause, scoped keys and no-secret sandboxes work even when the agent forgets.
Who decides Sandboxer's prices?
Jon approves prices and plans. Agents can draft changes, but nothing about money goes live without his yes.