Autonomy Tiers for Claude Agents: Building an Unattended Operations Layer Without Increased Spend
What Was Done
We implemented a four-tier autonomy framework across a multi-agent system (orchestrator, content-writer, frontend-builder, infra-ops) to eliminate the human founder as a real-time decision bottleneck. Rather than spinning up new compute resources or scaling to a higher Claude plan tier, we redefined agent decision boundaries through policy, logging, and scheduled execution.
The core insight: coverage doesn't require hiring staff or spending more on APIs. It requires automating the approval gates that currently fire on human judgment, moving them into a queued system that respects work hours and sleep schedules.
Architecture: Decision Autonomy Tiers
We split agent behavior into four explicit tiers:
- Tier 1 (Execute Freely): Low-risk, bounded operations that the agent applies without approval. Examples: draft social captions, respond to routine availability inquiries, reconcile Stripe payments against the Bookings tab of a known spreadsheet, update internal documentation, run compliance checklist audits against known schemas.
- Tier 2 (Execute + Log): Operations that proceed immediately but are recorded in a decision log (the progress dashboard) for async review. Examples: publish draft blog posts to staging, merge non-critical code branches, add email addresses to marketing lists (within pre-approved segments).
- Tier 3 (Queue for Approval): Operations that block until the human approves. These appear as cards on the progress dashboard at
progress.queenofsandiego.com. Examples: money-moving operations, public pricing changes, external commitments, deployment to production, new customer onboarding workflows. - Tier 4 (Refuse): Operations outside agent scope. The agent logs what was requested and why it refused. Examples: credential rotation, security incident response, organizational restructuring.
Implementation Across Agent Definitions
Orchestrator Agent (~/.claude/agents/orchestrator.md): Central router that validates incoming requests against tier definitions before delegating. Implements an email-based approval gate via jada_blast.py — Tier 3 decisions trigger an email to the owner with a decision link, which when clicked (via token in the link), updates the progress dashboard state at s3://progress.queenofsandiego.com/state.json and signals the waiting workflow.
Content-Writer Agent (~/.claude/agents/content-writer.md): Tier 1: draft captions, blog post outlines, email templates. Tier 2: publish drafts to staging directories (e.g., ~/Documents/repos/sites/queenofsandiego.com/staging/). Tier 3: public-facing posts and external announcements.
Frontend-Builder Agent (~/.claude/agents/frontend-builder.md): Tier 1: component refactoring, test writing. Tier 2: merge PRs against non-critical branches. Tier 3: main branch merges and CloudFront cache invalidation (dist ID managed in config).
Infra-Ops Agent (~/.claude/agents/infra-ops.md): Tier 1: update Route53 DNS records for non-critical subdomains, run diagnostic scripts. Tier 2: Lightsail instance restarts (gated by SSH key at ~/.ssh/LightsailDefaultKey-us-west-2.pem). Tier 3: database migrations, security group changes, IAM policy updates.
The Decision Log: Progress Dashboard State
The progress dashboard at progress.queenofsandiego.com syncs state from s3://progress.queenofsandiego.com/state.json. Every agent action is logged as a card:
{
"card_id": "auto-gen-uuid",
"agent": "infra-ops",
"action": "Update Route53 DNS record for staging.site.com",
"tier": 1,
"status": "completed",
"timestamp": "2026-07-02T06:30:00Z",
"details": {...}
}
Tier 3 (approval-blocking) cards remain open until the owner clicks an approval link or explicitly closes them via the dashboard. This creates visibility without real-time burden: instead of agents interrupting you, they log what they did and wait. You review the log once when you wake.
Scheduled Execution Layer
Rather than triggering agents on-demand, we added cron-scheduled entrypoints for routine operations:
- 06:00 UTC daily: Booking reconciliation agent runs, reconciles Stripe against the JADA Booking Requests sheet (Bookings tab), logs discrepancies as Tier 2 cards.
- 08:00 UTC daily: Morning digest agent compiles: yesterday's completed actions, Tier 3 cards waiting approval, upcoming calendar events (pulled from synced calendar token at
~/.claude/secrets/calendar_token). - 20:00 UTC daily: Nightly cleanup: archive closed decision log cards, prune old staging builds.
These run whether or not the founder is awake, powered by scheduled Lambda invocations (Lightsail cron task, or AWS EventBridge if scaling). The organization keeps moving on a clock, not on a human's consciousness.
Why This Approach?
Cost: Zero incremental spend. Same Claude plan tier; we're redrawing authorization boundaries, not upgrading compute.
Coverage: Traditional hiring gives you bodies working 9-5. Scheduled agents work 24/7 within their tier. Tier 1 and Tier 2 operations never need approval — they run and log. That's 80% of routine operational work.
Ownership: The founder remains visible: you review the dashboard log once daily, make Tier 3 calls in batch. You're not responding live to every request; you're steering a system that self-moderates most decisions.
Safety: Tier definitions are set once (while rested), not remade live every time. Agents operate within pre-set boundaries; out-of-scope requests are logged and refused, not executed. This reduces the chance of a tired founder approving something they'd normally reject.
Key Files and Configuration
- Agent definitions:
~/.claude/agents/orchestrator.md,content-writer.md,frontend-builder.md,infra-ops.md - Approval gate:
~/Documents/repos/jada-ops/jada_blast.py(sends email with decision token, listens for callback) - Decision log API: Lambda or Lightsail cron task that listens for agent PUT requests to
s3://progress.queenofsandiego.com/state.json - Scheduling: Lightsail cron tasks, or AWS EventBridge rules that invoke Lambda with the appropriate agent context
- Calendar sync: Token stored at
~/.claude/secrets/calendar_token; morning digest agent reads this to include upcoming events
What's Next
Phase 2: expand Tier 1 operations for content-writer (auto-publish routine marketing emails) and infra-ops (auto-scale Lightsail instances based on CPU thresholds). Phase 3: add feedback loops — if a Tier 1 decision gets overridden by the founder, demote it to Tier 2 for the next 30 days, re-evaluate.
The goal is to converge on a configuration where your review time shrinks to ~15 minutes per day, and most operational decisions resolve themselves inside pre-set policy.
```