# Building Agents that Don't Break Themselves

DevFeed: [Building Agents that Don't Break Themselves](<https://devfeed.tech/articles/building-agents-that-don-t-break-themselves-1690.md>)

Original publisher: [Read original article](<https://fly.io/blog/building-agents-that-dont-break-themselves/>)

Published: 2026-06-08T00:00:00Z

Content type: tutorial

Language: en

Sources: [The Fly Blog](<https://devfeed.tech/sources/the-fly-blog.md>)

Topics: [AI Bots](<https://devfeed.tech/topics/ai-bots.md>)

Tags: [agent](<https://devfeed.tech/tags/agent.md>), [agents](<https://devfeed.tech/tags/agents.md>), [ai](<https://devfeed.tech/tags/ai.md>), [api](<https://devfeed.tech/tags/api.md>), [bash](<https://devfeed.tech/tags/bash.md>), [cdn](<https://devfeed.tech/tags/cdn.md>), [close-to-users](<https://devfeed.tech/tags/close-to-users.md>), [deploy-app-servers](<https://devfeed.tech/tags/deploy-app-servers.md>), [docker](<https://devfeed.tech/tags/docker.md>), [elixir](<https://devfeed.tech/tags/elixir.md>), [fly](<https://devfeed.tech/tags/fly.md>), [fly-io](<https://devfeed.tech/tags/fly-io.md>), [heroku-alternative](<https://devfeed.tech/tags/heroku-alternative.md>), [heroku-competitor](<https://devfeed.tech/tags/heroku-competitor.md>), [hosting](<https://devfeed.tech/tags/hosting.md>), [i](<https://devfeed.tech/tags/i.md>), [networking](<https://devfeed.tech/tags/networking.md>), [node-js](<https://devfeed.tech/tags/node-js.md>), [postgresql-clusters](<https://devfeed.tech/tags/postgresql-clusters.md>), [sandbox](<https://devfeed.tech/tags/sandbox.md>), [sandboxes](<https://devfeed.tech/tags/sandboxes.md>), [servers](<https://devfeed.tech/tags/servers.md>)

## AI overview

A tutorial on keeping long-lived AI agents safe by separating the agent process from risky shell execution. It recommends running each potentially destructive task in an isolated, disposable Sprite rather than letting the agent execute commands in its own environment.

## Source excerpt

Building agents is fun. Rebuilding agents that break themselves... less so. A lot of Fly people are building agents with less of a penchant for self-destruction by teaching their agents to do anything risky in a Sprite. You get an agent that stays alive long enough to actually use its snazzy self-improvement features, and you can allow your agent to try things that would otherwise be battleship-scale footguns. Here's how to do it. Brains vs Hands Your agent would be pretty useless without a shell, because this is where it does agent things. Run the test suite, apply the migration, install the dependency, delete the temp files. Unfortunately, your agent's shell access is also what tends to ruin your afternoon, simply because "delete the temp files" and "delete the wrong files" are one fat-fingered glob apart, and as we're frequently warned, AI can make mistakes. This is why we have sandboxes. But a lot of people default to putting an agent that's going to do potentially scary work in a sandbox. This comes with a long list of tradeoffs that you really don't have to make, because where your agent lives and where it runs code are two entirely separate considerations. PPE for agent workers. The agent process is a loop. It calls a model, reads the response, picks a tool, rinse and repeat. It's a long-lived process that only becomes more competent and less stupid if memory, skills and history persist. So a Fly Machine that sleeps when idle and wakes on a message, a small VPS. Your laptop while you iterate. These are all fine homes for a loop calling an API, which doesn't need a blast shield. It's when you want your agent to execute that things get hairy. bash -c + whatever string the model just produced needs to be run in a padded room. Somewhere where the agent's code can't break itself or anything connected to it. And if your agent is doing more work than you are, you're going to want a whole facility of padded rooms that can be thrown away and rebuilt on a whim. One Sprit