# When to let an agent loose: an ops take > An agent that can act can also act wrongly. After twenty years of running systems, here's how I decide how much rope to give one, and the guardrails that earn their keep. Source: https://rfriedmann.de/blog/letting-an-agent-loose/ Published: 2026-06-17 · Track: learn · Level: Ops The moment an agent stops [just talking and starts acting](/blog/what-is-an-ai-agent/), the question changes. A chatbot's worst day is a wrong answer you can ignore. An agent's worst day is a wrong *action* you cannot take back: the deleted records, the email blast to the whole company, the production config it "tidied up". Same confident guessing as ever, now wired to a keyboard. After twenty years of keeping systems running, my rule for handing work to anything, junior hire, cron job, or agent, is the same, and it has nothing to do with how clever the thing is. It's about what happens when it's wrong. ## The line I draw Sort every action the agent could take by two questions: can it be undone, and how far does it reach. That splits cleanly into two piles.

Let it run on its own

Keep a human in the loop

Plotting a few everyday actions makes the split easier to feel than to recite.
Match autonomy to blast radius
[diagram omitted — see the page for the chart]
Reversibility and reach, not how clever the model is, decide how much rope to give an agent.
Most useful agent work lives happily in the left column. An agent that reads logs and proposes a fix is enormously useful and basically safe. The danger is letting it also *apply* the fix to production unattended, because you were impressed by how well it did the reading. ## The guardrails that actually earn their keep This is the same lesson as [building imp with an agent](/blog/writing-cuda-with-an-agent/): you don't trust agent output because it looks good, you build a room it can't break out of. The ones that matter, in order of how much grief they save:

  1. Least-privilege tools

    The single biggest lever. Don't hand it a raw shell and hope. Give it the three narrow tools the task needs. An agent literally cannot do what it has no tool for, so the safest action is one you never exposed.

  2. A human gate on the irreversible

    Anything in the right column above pauses for a yes. The agent proposes the delete, the deploy, the email; a person approves it. This is where "autonomous" should stop, on purpose.

  3. Sandbox and dry-run first

    Let it loose on a copy, or in --dry-run mode that prints what it would do. Real changes happen only after the rehearsal looks right.

  4. Hard limits

    A cap on steps, a timeout, a spend ceiling. A stuck loop should hit a limit and stop, not run all weekend running up an API bill or overloading an API.

  5. An audit log and an independent check

    Log every tool call so you can see what it actually did, and verify results against something the agent can't fake, the way imp's tests check kernels against an independent reference. A green run it graded itself proves nothing.

None of these are exotic. They're the same controls you'd put around a new employee's access on day one. The agent just makes skipping them more tempting, because it's fast and it sounds sure of itself. ## A heuristic that travels When I'm unsure how much rope to give an agent for some task, I don't ask whether the model is "good enough". I ask one question: It is a good test because it forces you to think about consequences and access together, which is what matters most. You would happily let an intern read dashboards and draft a report unsupervised. You would not let them push to production or email customers on day one, no matter how sharp they seemed in the interview. The agent is the eager, fast, occasionally overconfident intern who never gets tired. Treat it like one. This is the same honest split I draw for AI [in an infrastructure team](/blog/llms-in-your-infrastructure/) and for [when not to reach for it at all](/blog/when-not-to-use-ai/): the technology is genuinely useful, and the discipline is refusing to let "useful" quietly become "unsupervised". Build the room first. Then hand over the keys, one at a time.