An agent has been operating a live game server for 30 days. The permission split is what made it safe.

Setup: I run a small MU Online private server. .NET, PostgreSQL, Docker on a VPS, plus a PHP site and a launcher. I'm not a programmer. An agent writes and operates all of it. 2,177 commits in 30 days, real players logged in the whole time. The thing I'd tell anyone putting an agent near production is that the interesting design decision isn't the prompt, it's the permission boundary. Mine is: reads are free, writes ask. The agent reads any file, runs any diagnostic and queries the database unattended. Anything that writes to the database, restarts the game or deploys stops and waits for a human. It's enforced in config, not by instructions in a prompt, because instructions are advisory and config isn't. The execution channel is git, which turned out to matter more than I expected. The agent writes an order file, commits it, and a runner on the server picks it up within a minute, executes it and commits the result back. Every action has a diff, a result file and a timestamp. When something goes wrong I read a log, not a chat transcript. Two failure modes worth knowing about. Negative findings are the unreliable ones. "I searched and this doesn't exist" is wrong often enough that I re-verify it myself. Positive findings are almost always fine. Guardrails that were never tested. I shipped a check meant to block a bad state three separate times and it never fired once. Now the guard gets tested against both the new input and the old one before it ships. The real bottleneck was never the model. It was verification: a task that finishes unattended is worthless if "done" wasn't defined in a way I can check afterwards.