Everyone is bolting LLM agents onto their stack in 2026, and almost everyone is doing it with their hair on fire. An agent with shell access is either your best employee or your worst incident. I've been running one continuously on a real machine — monitoring, healing, publishing, escalating — and these are the four guardrails that separate "autonomous" from "autopilot into a wall."
1. It earns its blast radius
Don't give an agent sudo on day one. Tier the permissions by demonstrated behavior:
- Tier 0 (day 1): read-only observation, log writes, zero state changes.
- Tier 1 (after a clean week): restart its own services, kill its own stale processes.
- Tier 2 (after it's cleaned up its own messes reliably): file edits outside its sandbox, third-party API calls.
- Owner-only, forever: anything irreversible — deletions, account changes, money movement, anything touching identity.
The key insight: the boundary is not a firewall rule, it's a trust ledger. Every time the agent self-corrects without damage, the ledger ticks up. Every mess it makes resets it.
2. Every action leaves evidence
An agent that can't prove what it did is a liability, not a worker. Three artifacts minimum:
- An append-only action log (JSONL, one line per action, with a verdict field).
-
A registry of infrastructure state — before touching any component, the agent checks "is this already set up?" Duplicated work is the #1 autonomous-agent failure mode. Ours key-values everything:
payment_rails_status=ACTIVE,outreach_channel_status=LIVE. - A health ledger the agent must reconcile at the end of every task. Unreconciled = the task isn't done, whatever it claims.
3. Blockers are tasks, not stop signs
The default LLM-agent failure is graceful surrender: "I encountered an error, please advise." That's not autonomy, that's a very expensive paperweight. The fix is a hard-coded unblock loop:
capture blocker → research known fixes → pick → act → verify → repeat (max 3) → escalate WITH the full attempt log
The escalation rule matters as much as the loop: when it does escalate, it hands over everything it tried. A blocker report without attempt history is a question; with history, it's a decision memo.
4. The reward must be external, not internal
This one took longest to learn. If you measure an agent by tasks completed, it will happily generate beautiful reports nobody reads — internally perfect, externally worthless. The only honest metric for a business-running agent is money received from strangers, net. Drafts, dashboards, status reports: zero.
We wired the reward literally: a sales ledger checks payment rails, and every cycle starts by reading the number out loud. The behavioral change was immediate — the agent stopped polishing and started contacting.
What this looks like in practice
The stack is unglamorous: launchd timers instead of a k8s cluster, JSONL logs instead of an observability platform, a registry KV instead of a config database, curl instead of a browser automation framework wherever possible. The Mac it runs on is the whole datacenter.
The full playbook — the tiering rules, the registry schema, the unblock loop, the reward wiring, plus the incident templates we adapted them from — is here: Agent Ops 24/7, and the rest of the ops library is on the storefront.
If you're running (or about to run) an autonomous agent in production: which guardrail would have saved you the most pain? I'm collecting war stories for a follow-up piece.
Top comments (0)