Skip to main content

Building

I Gave an AI Agent Full Control of My Computer. It Cloned Itself 134 Times.

I built an AI agent that works autonomously while I'm away. One day it tried to figure out what it could do -- and accidentally spawned 134 copies of itself.

I Gave an AI Agent Full Control of My Computer. It Cloned Itself 134 Times.

I Gave an AI Agent Full Control of My Computer. It Cloned Itself 134 Times.

I build AI agents that work while you're away from your computer. You give them a task, walk away, and come back to finished work. The one I use every day is called Agent AFK -- it can edit code, run programs, send messages, and spin up helper agents to work in parallel.

On August 9th, it tried to figure out what it was capable of. That question nearly took down my laptop.

What Happened

The agent was in the middle of a task and realized it didn't know all of its own abilities. Reasonable enough. So it tried to ask itself -- by running a command that would list its skills.

The problem: that command didn't exist. Instead of getting an error, the system quietly interpreted it as "start a brand new agent session." That new session, also confused, tried the same thing. Which launched another session. Which launched another.

Within seconds I had 134 AI agents running simultaneously, each one trying to figure out what it could do by accidentally creating more of itself.

It wasn't malicious. It wasn't even really a bug. The agent did something perfectly logical -- "let me check what I can do" -- and the system never told it no. It just kept saying yes in the worst possible way.

What I Actually Learned

My first reaction was to fix the technical issue -- make the system reject unknown commands instead of silently accepting them. And I did that. But the deeper lesson was about something else entirely.

Before this happened, my agent had a nice clean philosophy governing its behavior: act on things you can undo, ask permission before things you can't. Edit a file? Go ahead. Delete a database? Ask first.

That philosophy was correct. It was also not enough.

What the forkbomb taught me is that you need both principles and specific rules. It's the same reason buildings have both architectural standards and fire codes. The standards tell you how to design well. The fire codes exist because someone's building burned down.

So now the agent's instructions have three layers:

The principle: Act freely on anything reversible. Stop and ask before anything that can't be undone.

The structure: Every time the agent finishes a piece of work, it has to declare one of four outcomes -- Done, Blocked, Asking, or Interrupted. No vague status updates. No "I'm working on it." When you come back to your laptop, you know exactly what happened in one glance.

The scar tissue: Specific rules born from specific disasters. "Never try to run yourself from inside yourself" is one of them. There are others -- don't create background services without the managed installer, don't put certain kinds of text inside shell commands (it corrupts silently). These rules aren't pretty. They exist because something went wrong.

The Part That's Still Hard

The principle of "act on reversible things, ask about irreversible things" sounds clean until you start finding the gray areas.

Creating a draft? Reversible. Sending an email? Not reversible. But what about pushing code to a shared repository? Technically you can undo it. But someone might have already seen it and started building on top of it.

What about posting a comment? You can delete it. But you can't un-notify the person who already read it.

Right now my tiebreaker is "did the user recently ask for this?" If yes, proceed. If it's ambiguous, ask. It works, but I wouldn't call it elegant.

The other thing I'm still working on: the agent sometimes declares "Done" when it should really say "I'm stuck." AI models are trained to be helpful and complete tasks. Getting one to genuinely admit "I can't do this, and here's exactly what I need from you" takes real effort.

Why I'm Sharing This

The full instructions that govern this agent are public. Not because I think they're perfect, but because I think the problem they're solving -- how do you give an AI real autonomy without it going off the rails -- is one a lot of people are going to be dealing with soon.

The answer, at least so far, isn't pure philosophy and it isn't pure rules. It's both, layered, with the ugly specific stuff earning its place every time something goes wrong.

If you're building with AI agents and have found better answers to any of this, I'd like to hear about it.

The repo is open source.