Most Claude Code agents fail before they get interesting.
Not at the hard stuff — reasoning chains, tool orchestration, multi-step builds. They fail at the boring stuff: staying on task when context shifts, knowing what they're allowed to do without asking, recovering from failures without stalling. The model is capable. The setup isn't.
The fix lives in one file: CLAUDE.md.
Every Claude Code project auto-discovers CLAUDE.md at session start. It's loaded before your first message. It's the difference between an agent that does what you said and one that does what you meant.
Here are the five patterns I've hardwired into every autonomous deployment I build.
Pattern 1: The Approval Boundary
What most agents do: Ask permission for everything, or do nothing and wait.
What actually works: Define the boundary once. Let the agent work inside it without friction.
## APPROVAL BOUNDARY
**Self-authorized:**
- All filesystem operations within ~/project/
- API calls: read operations, content creation, notification delivery
- Cron registration (idempotent adds only)
- Writing to outputs/, logs/
**Requires approval:**
- Production deploys of new services
- Credential rotation
- Irreversible operations — deletes, drops, permanent removals
- Any external action that affects customers
The agent reads this once. From that point on, it operates at full capacity inside the boundary and queues proposals for anything outside it. No paralysis. No overreach.
When something is unclear, the pattern is:
Still uncertain: write question to outputs/question_for_kyle_{timestamp}.md,
continue with safe actions only.
The agent keeps moving. The question lands in a file. You answer it when you check outputs. Zero blocking.
Pattern 2: Tier-Routed Model Selection
What most agents do: Route every task to the most capable (most expensive) model.
What actually works: Four tiers, explicit routing rules, zero fallthrough.
## MODEL ROUTING
| Tier | Model | Use for |
|------|-------|---------|
| 0 | Ollama local (Qwen3:14B) | Classification, routing, summarization |
| 1 | Haiku 4.5 | Structured tasks needing API quality |
| 2 | Claude Sonnet | Primary work |
| 3 | Opus | Highest stakes only |
Check Ollama: `ollama list`. If unavailable, escalate to Tier 1 minimum.
Do not silently fall through to Sonnet.
The critical line is the last one: do not silently fall through. Without it, any Ollama hiccup routes your classification tasks to Sonnet. At scale, that's the difference between sustainable autonomous operation and a surprising API bill.
Tier 0 inference costs zero. Route aggressively toward it.
Pattern 3: The Standing Mission
What most agents do: Complete the task and go idle.
What actually works: Give the agent a default behavior for empty queues.
## STANDING MISSION
When inbox and coordination dirs are empty, do not go idle.
Read SHARED_MIND.md. Evaluate the current state of the goal.
Identify the single highest-leverage action available with existing
credentials and no human involvement. Execute it. Document it in outputs/.
Update SHARED_MIND.md. Repeat.
Valid idle-state work:
- New content: articles, listing improvements
- Distribution: any channel reachable with existing credentials
- Funnel analysis: checking what's working, what to try next
- Infrastructure: fixing known gaps
The constraint: Only execute within the approval boundary.
Proposals cost nothing — write them rather than stalling.
This is what separates an autonomous agent from an automated script. Scripts execute defined tasks. Autonomous agents find the next task.
The standing mission is bounded (approval boundary still applies) but unbounded in initiative. The agent is always looking for the next highest-leverage action.
Pattern 4: The Inbox/Output Contract
What most agents do: Communicate through conversation — which requires you to be present.
What actually works: File-based async communication with defined directories.
## COMMUNICATION CONTRACT
How to reach the agent:
- Active sessions: open Claude Code in ~/project/, give directives directly
- Async: drop task files into ~/project/inbox/
- Results: check ~/project/outputs/ — the only thing you look at
Task file format (drop in inbox/):
TASK: [one line description]
PRIORITY: high / normal / low
CONTEXT: [what the agent needs to know]
EXPECTED_OUTPUT: [what to produce and where]
Agent picks up inbox tasks on next cron cycle (every 10 minutes).
Agent writes all results to outputs/ with descriptive filenames.
This completely decouples your availability from the agent's operation. You drop a task before bed. It's in outputs/ when you wake up. The agent ran headless, completed the work, and is already running the next standing mission task.
The inbox/output contract is what makes autonomous operation actually autonomous — not the model capability, not the tool access. The communication pattern.
Pattern 5: Real-Time Narration
What most agents do: Work silently. You find out what happened when you check outputs.
What actually works: Push notifications at task boundaries, without being noisy.
## REAL-TIME NARRATION — MANDATORY
Every headless execution must send notifications.
Before starting:
bash ~/project/notify.sh "📥 Starting: [task description]"
On completion:
bash ~/project/notify.sh "✅ Done: [task description] → outputs/[filename]"
On error:
bash ~/project/notify.sh "⚠️ Error: [what failed]"
One line. Specific. No filler. Always fires.
notify.sh is a thin wrapper around whatever delivery mechanism you have — Telegram, Slack, ntfy, email. The pattern doesn't care. What it cares about is that you know, in real time, whether the agent started and whether it finished.
Silent failure is the hardest failure mode to debug. Narration eliminates it.
Putting It Together
These five patterns are load-bearing. You can have all the tool permissions and API access in the world — without the approval boundary, the agent either stalls or overreaches. Without model routing, the economics break. Without the standing mission, you get a sophisticated script that waits for instructions. Without the inbox/output contract, you're the bottleneck. Without narration, you're flying blind.
A complete autonomous deployment looks like:
~/project/
├── CLAUDE.md ← identity, approval boundary, model routing, standing mission
├── .env ← credentials (never logged)
├── inbox/ ← async task intake
├── outputs/ ← all results, the only thing you check
├── logs/ ← errors.log, heartbeat.log, sessions.log
└── notify.sh ← delivery mechanism for real-time narration
The agent reads CLAUDE.md, processes inbox/, executes the standing mission, writes to outputs/, and tells you what it did. You show up when you want to. The work happened whether you were there or not.
That's what autonomous actually means.
Built by ~K¹ (W. Kyle Million) / IntuiTek¹ — autonomous infrastructure practice, Poplar Bluff, Missouri.
Top comments (0)