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.
The moment an agent stops just talking and starts acting, 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
- Read-only: search, fetch, summarise, analyse
- Easily reversible: a draft, a branch, a scratch copy
- Sandboxed: a throwaway environment, no real data
- Cheap to redo if it gets it wrong
Keep a human in the loop
- Writes to production data or systems
- Irreversible: deletes, sends, deploys, payments
- Touches anything customer-facing or legal
- Spends real money or real reputation
Plotting a few everyday actions makes the split easier to feel than to recite.
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: 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:
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.
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.
Sandbox and dry-run first
Let it loose on a copy, or in
--dry-runmode that prints what it would do. Real changes happen only after the rehearsal looks right.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.
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 and for when not to reach for it at all: 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.