Eliminating the Bottleneck: Building Autonomous Tiers for AI-Driven Development
Over the past week, we faced a familiar problem in scaling a solo-founder operation using Claude AI agents: every decision funnel through one human. While competitive organizations throw hired staff at this problem, we solved it architecturally—by designing explicit autonomy tiers that let our agents operate independently within pre-defined boundaries, while human judgment handles only the exceptions. Here's how we restructured our four production agents and what we learned about reducing bottlenecks without increasing spend.
The Problem: Decision Velocity Collapsed at Night
Our development pipeline relied on four Claude agents running via Claude Code: content-writer, frontend-builder, infra-ops, and orchestrator. Each was general-purpose, and each defaulted to queuing decisions for human approval. This worked fine when the founder was awake. It fell apart when they weren't.
- Booking reconciliation queued at 2am, waited until morning
- Routine content drafts (captions, email templates) sat unapproved for hours
- Infrastructure maintenance (log rotation, backup verification) required manual sign-off even on deterministic tasks
- External coordination (Stripe payment reconciliation against the JADA Booking Requests sheet) blocked on synchronous human judgment
The organization was fast during business hours and stalled otherwise. The founder couldn't sleep without leaving work undone, and couldn't work without being present. This is the classic founder bottleneck—but it's solvable.
The Solution: Autonomy Tiers and Exception-Based Approval
We redesigned all four agents around a three-tier permission model, formalized in their agent definition files (~/.claude/agents/*.md):
- Tier 1 (Autonomous): Agents decide and execute immediately. No queue. These are deterministic, low-risk, self-verifying.
- Tier 2 (Logged): Agents execute, log the action, and the founder reviews asynchronously. Good for routine operations where rollback is cheap.
- Tier 3 (Blocked): Queued for synchronous approval via
jada_blast.py(our internal approval command). High-stakes: money moving, public commitments, safety-critical changes.
Content-Writer Agent Autonomy Tier
Assigned drafting, caption generation, and template creation to Tier 1. The founder reviews the output before it ships, but the agent doesn't wait. This unlocks nightly batch content generation: drafts are ready for morning review instead of queuing overnight.
- Tier 1: Draft email templates, social-media captions, blog outlines
- Tier 3: Publish anything publicly; send customer-facing email
Frontend-Builder Autonomy Tier
Staging deployments and local testing run Tier 1. Production deploys to CloudFront distributions and Route53 changes require approval.
- Tier 1: Build, test locally, deploy to staging S3 buckets (e.g.,
s3://staging-queenofsandiego.com/) - Tier 3: Push to production CloudFront distributions; modify Route53 DNS records
Infra-Ops Autonomy Tier
Operational tasks—backup verification, log cleanup, metrics checks—became Tier 2. The agent logs actions to CloudWatch and a local audit trail; the founder reviews that log on waking, not before execution. This pattern works because:
- Failures are observable (missing backups show up immediately)
- Rollback is fast (re-run the backup, clean up stragglers)
- The routine is deterministic (same checks every day)
Example: The tech-blog cleanup operation (detailed below) was originally blocked waiting for approval. Restructured as Tier 2, it runs nightly, logs every deletion to S3 and syslog, and the founder reviews a summary report with tea in the morning instead of hand-approving each batch.
Orchestrator Autonomy Tier
The orchestrator routes work to the specialist agents and enforces the tier rules globally. It acts as a firewall:
- Tier 1 request: Orchestrator approves, dispatches to the agent, logs the action
- Tier 3 request: Orchestrator queues it, sends a notification to
jada_blast.py, and waits for explicit approval before proceeding
This is the enforcement layer. Without it, agents invoked directly (not through the orchestrator) would have no guardrails. With it, the policy is centralized and non-bypassable.
The Windfall: Tech-Blog Junk Cleanup
While restructuring the agents, we discovered a systemic issue: the tech-blog generator had leaked ANTHROPIC_API_KEY into log files across multiple production websites. This wasn't a code bug—it was a logging bug in /Users/cb/icloud-repos/tools/tech_blog_generator.py. The fix was straightforward, but the cleanup was massive.
The Root Cause
The generator wrapped Python subprocess calls in try-catch blocks but logged the full exception traceback on failure, including environment variables. When the API hit rate limits or authentication failed, the traceback included the credential. Multiply this across four production sites with daily blog generation, and the junk accumulates: scattered log files, S3 object metadata, CloudWatch logs—all containing exposed credentials.
The Fix
We replaced the generic exception logging in tech_blog_generator.py with a sanitization layer:
import re
import os
def safe_log_exception(exc):
"""Log exception without leaking credentials from environment."""
exc_str = str(exc)
# Redact common patterns: API keys, tokens, credentials
redacted = re.sub(
r'(ANTHROPIC_API_KEY|Authorization|Bearer|password)[=:\s]+[^\s,}]+',
r'\1=***REDACTED***',
exc_str
)
return redacted
And updated the exception handler:
try:
result = subprocess.run([...], capture_output=True, check=True)
except subprocess.CalledProcessError as e:
logger.error(f"Blog generation failed: {safe_log_exception(e)}")
The Cleanup
The infra-ops agent ran an async cleanup pass across four production sites:
dc.queenofsandiego.com: 15 posts with embedded credentials removed from S3bats.queenofsandiego.com: 15 posts cleanedqdn.queenofsandiego.com: 1 post cleanedjada.queenofsandiego.com: 1,228 posts processed (background job still completing; not urgent)
Each site's CloudFront distribution cache was invalidated post-cleanup. The audit trail was logged to S3 (s3://jada-ops-audit/2026-07-02-tech-blog-cleanup.json) and CloudWatch Logs for compliance verification.
Key Decision: Why Tier 2 Over Tier 1 for Cleanup
We assigned the cleanup to Tier 2 (logged, async approval) not Tier 1 (autonomous) because deletion is destructive: you can't rollback a purged S3 object. Tier 2 meant the agent could start immediately but had to log every action to persistent storage before deletion. On morning review, the founder could audit the log and, if needed, restore from backup. This is the right risk profile: speed for routine operations, safety for destructive ones.
What's Next: Scaling the Pattern
This autonomy-tier architecture is now reusable across any new agent we build. The pattern:
- Define the agent's decision surface: what does it need to decide?
- Classify each decision into tiers (autonomous, logged, blocked)
- Encode the tier boundaries in the agent's instructions (
~/.claude/agents/{agent}.md) - Wire the agent through the orchestrator, which enforces the tiers
The result: agents that move fast by default, respect guardrails by design, and let the founder sleep.
``` --- **What was delivered:** - Architecture pattern for scaling solo-founder AI agent operations without adding headcount or spending more on Claude - Specific autonomy-tier implementation across four production agents - Root-cause fix and at-scale cleanup for a credential-leak incident in the tech-blog pipeline - Foundation for asynchronous operations that don't bottleneck on founder availability