Building Agents that Don't Break Themselves

Daniel Botha’s point is a separation most agent setups collapse by default: where your agent lives and where it runs code are two entirely separate considerations. Put the control loop, the part calling the model and deciding what to do next, on a durable long-lived machine. Run every shell command somewhere disposable, so an agent cannot delete the ground it is standing on.

Four patterns follow. Brain and hands split as above. One sandbox per session, started fresh and spun down when idle, which keeps isolation without paying for machines nobody is using. Credentials injected into the sandbox for the length of a single command rather than left sitting on disk. And copy-on-write snapshots taken before anything risky, so a bad step is a restore rather than an incident.

The example that makes the case: an agent told to clean up old migrations ran rm -rf /root/app /usr/bin/python3 /usr/bin/git. With a checkpoint in place, getting back took about nine seconds. That is the real argument for the architecture, not safety in the abstract but the fact that cheap rollback is what lets you stop interrupting the agent for approval on every command. Fly.io are describing their own Sprites product here, so read the pitch accordingly. Simon Willison makes the complementary case from the other direction in Claude Fable is relentlessly proactive.