How do the studio's AI agent teams ship code?

Who is on an agent team?

• A chief of staff per company, plus one for the whole studio that rolls them up and writes Jon's daily brief. Its job is to route work, check it and reply, so its own conversation is never blocked by a long task.
• Workers, long-running agents with one area each, such as infrastructure and mail, a company's backend, or this website. Builds, deploys, research and anything longer than a few steps go to a worker.
• Reviewers, second agents that read a pull request before it merges, given the diff and the goal rather than the author's conclusions.

Read how the studio uses agents day to day for how requests and approvals flow between them.

Why does every change go through a pull request?

Because it's the one gate every change shares. The main branch of every repository is protected: a pull request is required, automated checks must pass, and force-pushes and deletions are blocked. The rule holds for agents and people alike, and even the founder's account can't push straight to main without first turning the rule off. Agents open, review and merge the pull requests themselves; no person is a required reviewer, so nothing waits on a human who wouldn't add anything. Each pull request says why the change was made, how it was verified and how to roll it back.

When does a second agent review the change?

For anything that touches product code, billing, sign-in or infrastructure. The reviewer gets the diff and the goal, not the author's own account of what it did, so it checks the change rather than the story. The author fixes what it finds before the merge. Content-only changes, like this page, skip review: the build's checks cover them. For how review passes work with many agents, see running many coding agents in parallel.

Where do the checks run?

On the studio's own CI runners, not on hosted ones. Every repository's jobs run there, and a test fails any job that drifts back to a hosted runner. A small spending cap on hosted CI stays in place as a tripwire: if it's ever hit, the job that hit it moves to the studio's runners rather than the cap going up. Scheduled jobs, such as the daily content runs for this site, open their own pull requests and merge automatically once the checks pass.

How does a merged change reach production?

Straight away, and only from merged main. There's no staging server; risky features ship switched off behind a flag instead, as described in feature flags instead of staging. Deploys run smoke checks and keep a one-step rollback. This website, for example, rebuilds each merged commit in a locked-down sandbox and checks that every page returns 200 before the deploy counts. "Live" means deployed and checked, not merged. See how we build companies.

What stays with a person?

The decisions that are hard to undo or visible to customers: spending money, legal terms, DNS changes, deletions, public launches and customer email. Only Jon approves those, and an approval relayed by another agent counts only if it quotes his words. For tracing who did what once agents are shipping, see how to tell which AI agent made a change.