The Problem With Running Agents On Your Own Machine

Most engineers give their coding agents a small corner of their own computer, or lean on CI/CD and containers. That setup limits what agents can do because they're sharing resources and interfering with your own work. The creator argues that containers only solve isolation — they don't give you scale or autonomy.

An agent sandbox, by contrast, is a full computer dedicated to the agent. That means the agent can own the entire environment and the "blast radius" of any failure is contained to that one box.

Stop allocating a corner of your machine to agents; treat sandboxes as disposable, ownable computers instead.
Use a dedicated sandbox provider (the video uses exe.dev) rather than short-lived CI containers that expire in hours or days.
Give each agent full SSH-level access to its own box so it isn't constrained by your local setup.

Running a "Software Factory" Inside Each Sandbox

Rather than firing a single prompt at a single agent, the workflow places an entire software development lifecycle — plan, build, review, gate checks — inside each sandbox. This is called a "software factory," and it was covered in more depth in a prior video the creator references but doesn't fully repeat here.

The demo runs five parallel software factories, each with a different model/harness configuration (Default, Frontier, Deepest Seek, Open Weights, Top Speed), all solving the same redesign prompt for a mock writing app called Inkwell. This is the "best of N" pattern: run multiple independent attempts, then compare results and pick the best.

Define multiple agent configurations (different models, harnesses, thinking levels) rather than betting on one model.
Run the same task across all configurations simultaneously using best-of-N, since sandboxes remove the resource contention that would make this painful locally.
Build deterministic gate checks into the pipeline (e.g., catching and fixing JSON errors) so failures don't silently propagate.

A Three-Tier Orchestration Structure

The system uses three layers: an out-of-sandbox orchestrator that kicks off jobs, an in-sandbox orchestrator that runs the software factory, and the individual coding agents doing the actual work. This lets the creator step out of the loop for most of the run and only re-enter to inspect, prompt, or validate.

One of the five runs (an open-weights config using Kimi K3) failed outright during the demo — it couldn't produce valid JSON output. The creator treats this as expected and as the reason best-of-N matters: when one config fails, the others still deliver results.

Separate orchestration from execution: an outer orchestrator triggers sandboxes, an inner orchestrator runs the lifecycle inside each one.
Expect and tolerate failures in individual runs — that's the point of running several in parallel.
Reserve manual involvement for the edges: planning at the start, reviewing and validating at the end.