Agent Autonomy Tiers: Scaling a Solo-Founder Business Without Hiring
Running a complex operation as a solo founder means everything bottlenecks on your attention. When your AI agents ask "should I send this email?" fifty times a day, you become the decision gate. This session implemented autonomy tiers—a policy-based authorization system that lets Claude agents make pre-approved decisions independently, while queuing only the judgment calls that actually need you.
What Was Done
We split four existing Claude agents (content-writer, infra-ops, frontend-builder, orchestrator) into two autonomy tiers:
- Tier 1 (autonomous): Draft content, answer routine questions, reconcile Stripe payments against booking sheets, generate crew access tokens—anything low-stakes that follows a documented policy.
- Tier 2 (requires approval): Money changing hands, pricing decisions, public commitments, safety-critical actions, customer-facing communications that set expectations. These are tagged and queued to your approval inbox instead of executing.
The mechanism is explicit: each agent file now contains a policy block that lists what it can do without you, and what triggers the approval gate.
Technical Implementation
Agent Policy Definition
Agent definitions live in ~/.claude/agents/. Each agent's autonomy tier is declared upfront in its instructions. For example, infra-ops.md now includes:
## Autonomy Tier
**Autonomous actions** (execute immediately):
- Reconcile Stripe charges against JADA Booking Requests (Bookings tab)
- Generate crew access tokens with 72-day TTL via gen_crew_token.py
- Fix broken symlinks in /Users/cb/icloud-repos/.secrets
- Answer questions about deployed infrastructure and DNS state
**Approval-gated actions** (tag with needs-you, do not execute):
- Modify production CloudFront cache policies
- Change Route53 records that affect customer-facing domains
- Modify IAM policies or security groups
- Deploy changes to production without staging verification
This is not a code library—it's a contract. The agent reads it, understands the boundary, and self-enforces.
Approval Gate Mechanism
High-stakes actions go into a queue instead of executing. The orchestrator agent uses a jada_blast.py wrapper that checks action type. For instance, sending bulk email is gated:
#!/usr/bin/env python3
# Simulated gate (actual implementation handles authentication)
import sys, json
action = json.loads(sys.argv[1])
action_type = action.get("type")
if action_type in ["send_email_blast", "modify_pricing", "public_post"]:
print(f"ACTION QUEUED (needs-you): {action_type}")
# Write to queue file, exit with status 1 (don't proceed)
sys.exit(1)
else:
print(f"ACTION APPROVED: {action_type}")
sys.exit(0)
When an agent encounters a gated action, it writes details to your approval queue (housed on the progress dashboard at progress.queenofsandiego.com) and waits for your explicit approval instead of proceeding.
Key Implementation Details
- Token generation policy: The crew access tokens (used for crew member pages) now follow an explicit 72-day TTL rule, documented in
jada-darrell-sms-policy.mdmemory. This is enforced ingen_crew_token.py(default TTL 90 days, explicitly clamped to 72 for customer-facing tokens). - Stripe reconciliation: The infra-ops agent can read the JADA Booking Requests sheet (Bookings tab, not Sheet1) and reconcile charges autonomously, but cannot modify customer payment methods or refund thresholds.
- SMS dispatch rules: Stored in
jada-darrell-sms-policy.md; agents can queue SMS messages to known numbers, but cannot create new contact groups without approval.
Infrastructure: Scheduled Execution Without You
The real win: actions no longer wait for you to be at the keyboard. The orchestrator can be triggered via cron, scheduled tasks, or webhook events.
Morning Digest Pipeline
Scheduled to run at 06:00 UTC via ~/bin/morning-digest:
0 6 * * * /Users/cb/bin/morning-digest 2>&1 | tee -a ~/logs/morning-digest.log
This:
- Reconciles overnight Stripe charges against the booking sheet.
- Builds a summary of crew availability from crew pages.
- Checks for pending approvals in the queue.
- Generates a single digest email, queued for your approval (no sending until you've reviewed).
If you were asleep, this still ran. If your approval is needed, it's waiting on the dashboard when you wake.
Crew Dispatch Automation
The charter_provisioner.py script (in ~/icloud-repos/jada-ops) runs autonomously on a schedule to provision crew access and send magic links:
python3 charter_provisioner.py --days 30
This autonomously generates 72-day-TTL tokens, but emails stay queued until you review the dispatch summary. The policy lives in code, not in your head.
Key Decisions and Trade-offs
Why Not Just Hire Someone? A dedicated employee adds fixed overhead. Autonomy tiers give you the same effect (coverage while you sleep) at marginal cost—one upfront design effort, then reused forever.
Why Policy in Agent Markdown? Because agents read and reason about documentation. When the policy is in the same file as the agent's system instructions, it's part of the context every time the agent runs. No separate config parsing, no drift between intent and code.
Why Two Tiers, Not Three? Three tiers would fragment decision-making. With two, the boundary is simple: "Is a human judgment required?" Yes → approval gate. No → autonomous. Simpler rules scale better.
What's Next
Expand autonomy tiers to:
- Content-writer: Autonomous social media captions (low-stakes), approval gate for major campaign announcements.
- Frontend-builder: Autonomous staging deploys (with automated tests), production deploy requires manual approval.
- Email reactivation engine: Once built, runs on a nightly schedule sending to cold-lead segments autonomously, but review-after (not before) so morning digest shows you what went out.
The pattern is now established. Each new agent ships with a policy block; each policy saves you dozens of decision points per week.
```