There is a Fly.io post making the rounds about building agents that don't break themselves. It's a good post. The planner/executor split — one agent reasons, a separate constrained agent acts, and the planner never has write access — is a sound idea. I don't use it. But I understand why it works, and I understand what it's actually solving.
What it's solving is authority scope. That's the real subject, whether the post names it or not.
The Three Causes
When AI agents destroy things — deleting tools, overwriting their own configuration, recursively modifying themselves into uselessness — the cause is almost always one of three things:
You are not in the loop enough. You have not provided enough structure. You are asking too much in a single turn.
That's it. Not a model problem. Not a fundamentally unsolvable containment problem. A task-design problem.
The planner/executor architecture is an elegant structural solution to all three at once. The planner has broad authority but no write access; the executor has write access but no autonomy. You are implicitly in the loop at the boundary between them. The task scope is bounded by what the executor can do. It works because it enforces what most people forget to enforce explicitly.
But you can get there without that architecture. The simpler path is to ask yourself the right questions before you spin up a session.
Diagnostic
If your agent destroyed something, ask: was I present enough to catch it before it ran? Did I give it enough context to know what it wasn't supposed to touch? Did I ask it to do more than one full cognitive job in a single prompt?
What Actually Happened
I spent months chasing my tail with agent systems last year. A lot of that time was spent recovering from sessions that went sideways — agents with too much latitude, tasks that were scoped too broadly, turns that tried to accomplish three things that each deserved their own session.
Part of what changed was the tool. I'll be direct: switching to Claude Code made a material difference. Not because it's magic, but because the model follows complex standing instructions reliably, which means your scaffolding actually holds. When the agent reads its brief and stays inside it, you stop spending your time on recovery work and start spending it on actual output.
But the tool matters less than what I did with it. I gave it a complete instance — a test instance, not production. And I immediately created agent scopes: each project has its own session, its own brief, its own defined authority. What this agent can write. What it cannot touch. What requires a message back to me before proceeding.
The agent that destroyed something was almost always the agent that was given the opportunity to destroy something.
Scaffolding Is the Work
The thing I've added most over time isn't smarter prompts. It's structure.
Standing instructions in project root files that every session reads on startup. Authority tables: this agent owns these directories, not those. Explicit rules about when to stop and message upward rather than proceed. Task sizing: one coherent job per turn, not three.
This is scaffolding. It's boring to build. It is the work.
The Fly post suggests that agents shouldn't be able to see their own source code or modify their own tool definitions. That's right. I'd extend it: agents shouldn't need to. If you've scoped the task correctly, the agent isn't looking for its own configuration because you've told it what to do with enough precision that it isn't searching for more context.
Right-sized tasks for context windows isn't just a performance optimization. It's the containment mechanism. An agent that's asked to do one bounded thing has a smaller opportunity surface for breaking anything. An agent asked to "improve the codebase" has been handed a gun.
Keep Adding Structure
I am still adding structure. Not because the current structure is failing — it isn't — but because each new project surface is a new authority surface, and every new surface needs a brief.
The scoping work doesn't end. What you're building, iteratively, is a set of constraints fine enough that an agent operating inside them cannot do significant damage even if it makes a mistake. Not because the agent is dumb. Because the box is the right size.
The planner/executor split formalizes this into an architectural pattern. That's worth doing at scale. For most people starting out, the version of this that works is simpler: stay in the loop, structure the brief, right-size the task.
If your agents are destroying things, start there.
— J.P. Howlett