I let an autonomous agent run my ops for 30 days — the 4 guardrails that made it safe

Description and use

A 30‑day autonomous ops agent ran safely by implementing four guardrails: tiered permissions, mandatory evidence logging, a blocker‑unblock loop, and an external reward tied to real revenue.

Problem

Deploying an LLM‑powered autonomous agent with shell access risks catastrophic incidents if not properly constrained.

Outcome

The agent ran safely for 30 days, avoiding destructive actions, providing clear evidence of its work, handling blockers autonomously, and focusing on revenue‑driven tasks.

Workflow

• 1. Tier permissions by demonstrated behavior (read‑only → restart services → file edits → owner‑only actions).
• 2. Log every action in an append‑only JSONL file with verdicts.
• 3. Maintain a key‑value registry of infrastructure state to avoid duplicated work.
• 4. Reconcile a health ledger after each task; unreconciled tasks are considered incomplete.
• 5. Implement a hard‑coded unblock loop: capture blocker → research fixes → act → verify → repeat up to 3 times → if still blocked, escape with full attempt log.
• 6. Wire the reward to external money received, not internal task completion metrics.

Evidence

Don’t give an agent sudo on day one. Tier the permissions by demonstrated behavior…

Source

An agent that can’t prove what it did is a liability, not a worker. Three artifacts minimum…

Source

The default LLM‑agent failure is graceful surrender… The fix is a hard‑coded unblock loop…

Source

If you measure an agent by tasks completed, it will happily generate beautiful reports nobody reads… The only honest metric for a business‑running agent is money received from strangers, net.

Source