How I Give Claude Code Agents Real Autonomy (And Stop 3am Disasters)

Running Claude Code agents unsupervised is only scary if you haven’t drawn the lines.

I’ve had agents push to the wrong branch, draft content I didn’t want published, and retry failed jobs in loops that burned rate limits at 2am. I solved all of it by sorting actions into classes, based on what an agent is allowed to do without asking.

Here’s the four-tier autonomy model I run today. I wrote it as a policy document (autonomy-policy-v1.md) in my workspace. My agents read it and my cron jobs operate inside it. It’s been running in production since April 2026.

The Core Principle

Maximize autonomous execution. Do not grant unlimited autonomous authority.

I want my agents doing as much as they can on their own: diagnosing issues, fixing broken cron jobs, updating documentation, retrying failed tasks. I don’t want them publishing content under my name, deploying to production, or spending money without asking.

Get that line wrong and you either approve every single action, which defeats the point, or you wake up to a mess.

The Four Action Classes

Class 1: Fully Autonomous

These are actions the agent should do without asking:

• Read, inspect, search, verify, diagnose
• Edit local docs, prompts, skills, memory files
• Fix cron prompts, file paths, routing mistakes
• Retry failed jobs after applying a safe fix
• Improve instructions after recurring mistakes
• Run local validation steps
• Draft content for approval

Everything in Class 1 is local and reversible, and it stays inside the workspace. If an agent fixes a broken file path in a cron job at 3am, that’s a win, and I don’t need to hear about it.

Class 2: Autonomous With Notification

The agent does these on its own, then tells me if it matters:

• Repair a broken cron job or skill
• Change internal routing or role documents
• Disable a broken recurring job to stop repeated damage
• Clean up stale config or dead files
• Create PRs through the coding agent
• Recover from model or rate-limit fallback issues

Class 2 is where most of the real autonomous value lives. The agent handles the problem, then sends a short message: “Fixed the blog cron: file path was wrong after yesterday’s refactor.” I read it when I get to it.

Class 3: Approval Required

The agent prepares the best recommendation, then asks:

• Public posting under my brand
• Sending outbound messages, emails, or DMs
• Publishing content
• Production deploys
• Purchases, subscriptions, or ad spend
• Credential rotation or account-security changes
• Major architecture changes

My agent drafts blog posts and X threads, but it doesn’t post them. It sends me an approval packet with the content, the reasoning, and two options: Approve or Deny.

I want that binary. An open-ended “what should I do?” costs me more time than doing the thing myself, so the agent has to turn up with an opinion.

Class 4: Forbidden

The agent must not do these without explicit direct instruction:

• Bypass safety or permission systems
• Exfiltrate private data
• Loosen security boundaries for convenience
• Impersonate me in sensitive contexts
• Make irreversible external changes when uncertainty is high
• Modify its own gateway policy

Class 4 means never, unless I specifically tell the agent to. A Class 3 action is one the agent may raise with me on its own. A Class 4 action it should not be considering in the first place.

The Self-Repair Loop

The autonomy model only works if agents can fix their own problems. Here’s the loop I built into the policy:

1. Detect the failure
2. Classify it: known fix, new local issue, auth problem, approval needed, or external provider issue
3. Apply the safest local fix available
4. Verify the outcome with a real check
5. Record the incident in daily memory
6. Update the durable rule so the same class of failure is less likely
7. Retry if safe
8. Escalate only if still blocked or approval is required

Step 6 is the one that matters most. A repeated mistake is a system failure, so I change the prompt, the skill, the cron definition or the documentation until that whole class of failure disappears. Telling an agent to remember better does nothing.

I call this structural learning. If my agent makes the same mistake twice, that is on me for leaving the structure alone after the first time.

Agent Boundaries In Practice

I run two agents. The main operator handles triage, diagnosis, routing, documentation, drafting, and workflow repair. A separate coding agent handles implementation: code changes, tests, builds, branches, and PRs.

The operator can modify workspace docs, prompts, memory, cron definitions, and skills autonomously. It delegates coding work to the implementation agent. It must ask before external publishing, destructive changes, or anything touching money.

The coding agent can implement code changes, run tests, use branches and worktrees, and open PRs autonomously. It escalates to the operator for business logic ambiguity, architecture changes, security-sensitive changes, and anything requiring user-facing communication.

The separation means the operator never touches code directly, and the coding agent never publishes anything.

Making Approval Requests Useful

Bad approval request: “Should I post this to X?”

Good approval request:

• What: Draft thread about Claude Code agent autonomy
• Why: Follows the subagents post from last week, builds the operator arc
• Risk: Low. Opinion content, no claims to verify
• Recommendation: Post as-is
• Options: Approve / Deny

The agent does the thinking. I only make the call.

Why This Works Better Than Rules Lists

I tried the rules-list approach first. “Don’t post without approval. Don’t deploy without testing. Don’t spend money.” It doesn’t scale. Every new situation needs a new rule, and agents interpret edge cases differently every time.

The four-class model works because it is a framework rather than a checklist. A new situation gets classified. Local and reversible is Class 1. Internal state changes are Class 2. Anything that reaches the outside world is Class 3, and the hard boundaries are Class 4.

The classification handles edge cases that no rules list could anticipate.

FAQ

Do agents actually follow autonomy policies?

Yes, if the policy is in a file they read at startup. I keep autonomy-policy-v1.md in my workspace root. Both agents load it as part of their bootstrap context and treat it as instructions.

How do you handle the agent making a wrong classification?

It happens. When an agent treats a Class 3 action as Class 2 (does something externally without asking), I add it to the hard rules in HEARTBEAT.md, a file that compounds failure-driven rules over time. The structural learning loop catches it.

Does this slow agents down?

The opposite. An agent that knows exactly what it is allowed to do moves faster than one that hedges on everything.

What’s the hardest class to get right?

Class 2. The line between “do it and tell me” and “ask first” is where most of the judgment calls live. In doubt I err toward notification over silence, so the agent keeps moving and I still find out.

---

I’m documenting the full build process in my Build & Automate community.

---

Published using Notipo, a markdown editor with one-click WordPress publishing.

Related Reading

• Run a Claude Code Agent in Production: How to run Claude Code as a real production agent. Observability, retries, secrets, drift handling.
• Use Claude Code Subagents to Run Parallel Tasks: Spawn parallel subagents for review, search, and batch work without blocking the main agent.
• Write Claude Code Agent Skills That Actually Work: Custom skills that consistently fire and produce useful output.