The five things I never let my AI do

I handed a flock of AI agents the keys to my company. The reason it still runs is a short list of things they are never allowed to do without me. Most of the writing about AI agents right now is about giving them more: more tools, more autonomy, more of your workflow. I run a handful of small apps as one person and a flock of AI agents, and the single most important part of that setup isn't anything the agents can do. It's the short list of things they can't - not without me in the loop, clearing each one myself. I didn't start with the list. I earned it, one near-miss at a time. Here's what's on it, and why each line is what makes the autonomy around it safe. Everything I write about this setup circles the same question: when nobody else is checking, how do I know the work is real? The harness I built to answer it automates the work and refuses to automate the judgment. This piece is about the places where that judgment has to be a human hand, because checking after the fact is already too late. One person, many agents, real buttons The boundaries matter because the agents don't live in a sandbox. They touch the real world: they open a browser, edit files, run shell commands, stage deployments, format posts for publishing. That's the whole point. If an agent can only suggest, I've just built a slower, more expensive version of myself. The leverage comes from letting it act. But "letting it act" and "letting it act on anything" are very different bets. An agent that can publish can also publish the wrong draft to the wrong place. An agent that can delete can also delete the one thing I can't get back. Autonomy without edges isn't power; it's a loaded tool with a nervous trigger. So I drew edges - and I keep them short enough to actually remember. The five lines 1. Nothing goes out the door without me. Publishing an article, sending a message, posting in public, submitting a form - anything that leaves my machine and reaches another human - stops one step short of the send. The agent writes the whole thing, formats it, stages it - and then stops, because the call to send it isn't its call to make. Every article in this series, including this one, was drafted and checked by agents and went out only when I gave the word on that specific piece - no agent has ever been the thing that decided a piece was ready to leave. The draft is cheap and reversible; the send is neither. So the send is mine. 2. It never touches credentials. No passwords, no two-factor codes, no creating accounts, no entering payment details. This isn't a preference I can wave away when I'm in a hurry - it's a hard wall. If a task genuinely needs a login, the agent stops and hands the keyboard back to me. The moment an automated system can authenticate as me is the moment a single bad instruction can do unbounded damage, so that capability simply doesn't exist in my setup. 3. Irreversible is mine. Deleting data, overwriting something I didn't create, moving money, changing who has access to what - the whole category of "you can't undo this" is gated to a human. The test I use is blunt: if getting it wrong means I can't get back to where I was, an agent doesn't get to do it alone. And before it overwrites or removes anything, it has to actually look at the thing first - if what's in front of it doesn't match how the task described it, that mismatch is a reason to stop and ask, not a detail to steamroll on the way to "done." 4. No new automation without a hypothesis, a metric, and a sunset. Before any agent stands up a new recurring job - a scheduled task, a watcher, a polling bot - it has to answer three questions in writing: what metric will this move, how will I measure it, and on what date does it turn itself off if the metric doesn't move? I added this line the expensive way. I once ran a fifteen-persona automation for eighteen days with no success metric; it made thousands of model calls and I couldn't prove that a single one changed an outcome. Now "it seemed fun" and "I was lonely" are disqualifying answers. If you can't say what better means, you don't get to build the thing that's supposed to deliver it. 5. It has to prove, not promise. An agent doesn't get to tell me a task is done. It has to show me - the test output, the diff, the rendered screen. In my setup, one agent's "done" is another agent's job to try to refute, and a claim that survives that is the only kind I act on. The gate that enforces this exists because one pattern kept repeating: a task reported as finished, and a diff that turned out to hold nothing but comments, whitespace, and renames wearing the feature's name. The report was always fluent. The work was sometimes absent. So "done" is a hypothesis now, not a status. None of these live only in a prompt I could talk an agent out of. They're enforced in two places at once - the rules I write, and a permission layer underneath that stops an agent cold the instant it reaches for an outward action I haven't cleared, even in the middle of an otherwise-approved task. I've watched it happen: an agent several steps into a job I had greenlit reached for a publish button and was refused by the layer below it, because publishing wasn't the specific thing I'd approved. The line held even though I wasn't watching that exact second. A rule you can argue with isn't a boundary; it's a suggestion. The fences aren't the opposite of trust - they're what let me hand over everything else. The line that surprised me If you'd asked me at the start which of these would matter most, I'd have pointed at the credential wall - the scary one, the one about catastrophic damage. In practice, the line I lean on hardest is the fourth: the automation with no metric. The dramatic failures are rare and loud, and the rules for them are easy to write. The quiet failure - a system that runs forever, costs a little every day, and never produces evidence that it's worth it - is the one that actually bleeds a company of one. It doesn't blow up. It just sits there, spending, looking busy. The hypothesis-metric-sunset line is the most boring one on the list, and it has saved me more than any of the dramatic ones. Why the fences make the autonomy safe Here's the part that took me longest to understand. The lines don't make my agents less useful. They're what let me give them more. I can let an agent drive a browser through a ten-step console workflow precisely because I know it will stop dead at the login screen, and send nothing outward until I've cleared that exact thing. I can let it refactor across a dozen files because I know the irreversible operations are fenced off from it. The boundary isn't the opposite of trust - it's the precondition for it. I trust the autonomy because I know exactly where it ends. A concrete version of that happened recently. I handed an agent a tedious ten-step console setup - reading dashboards, flipping settings, filling forms - and let it run the whole thing while I did something else. I could look away because the only two places it could actually hurt me, entering a credential and clicking the final confirm, were both walled off. It reached each wall, stopped, and handed the moment back to me. I did those two clicks in about thirty seconds; the agent did the forty tedious minutes around them. Without the walls I'd have had to babysit all forty minutes, or not delegate at all. The fence is the thing that let me leave the room. A good colleague earns your trust partly by knowing which decisions aren't theirs to make. It turns out the same is true of a flock of agents. The ones I would never hand real work to are the ones with no sense of where the line is. Draw the lines before the architecture If you're handing real actions to AI - not toy tasks, but things that touch your users, your money, your data - draw your lines before you draw your architecture: - Name the outward actions. Anything that reaches another person waits for you. - Wall off credentials entirely. Not "be careful" - "cannot." - Fence the irreversible. If you can't undo it, an agent can't do it alone. - Gate unmeasured automation. No hypothesis, no metric, no sunset, no build. - Demand proof, not status. "Done" is a claim to verify, never a fact to accept. I gave a flock of AI agents an enormous amount of rope. The company still stands because I was just as deliberate about the five places I tied it off. The exciting part of building with agents is everything they can do. The part that lets you sleep is the short, boring list of things they can't. I draft these essays with the same kind of AI agents this one describes - working from my own real setup and logs - and I edit and fact-check every line before it goes out. Nothing here left my desk on an agent's say-so. Top comments (0)