Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Decoupling Agent Autonomy: Building a Capability-Gated Multi-Agent System on Claude's Free Plan

What Was Done

We implemented an autonomy-tier architecture across four Claude agents managing JADA's core operations (content generation, infrastructure, frontend development, and task orchestration). Instead of centralizing all approval gates around a single human decision-maker, each agent now has explicit permission boundaries: actions they execute immediately, actions they queue for review, and actions they refuse outright.

The four agents affected:

  • ~/.claude/agents/content-writer.md — blog posts, email drafts, marketing copy
  • ~/.claude/agents/frontend-builder.md — page structure, component changes, styling
  • ~/.claude/agents/infra-ops.md — AWS resource changes, DNS updates, deployment scripts
  • ~/.claude/agents/orchestrator.md — task routing, approval flows, high-stakes decision gates

This solves the human-bottleneck problem: the organization now moves on a clock (scheduled jobs, queued decisions) rather than on founder consciousness.

Technical Details: Tier Definition

Each agent file now contains an explicit AUTONOMY_TIER structure defining three categories of work:

Tier 1 (Execute Immediately): Routine, reversible, low-stakes actions

  • content-writer: Draft social-media captions, compose email templates (no send), suggest post schedules
  • frontend-builder: Create component previews, suggest CSS changes, refactor internal structure
  • infra-ops: Generate CloudFormation templates, suggest S3 lifecycle policies, document infrastructure
  • orchestrator: Log events, update progress dashboard cards, fetch data from canonical sources

Tier 2 (Queue for Review): Consequential but reversible actions

  • content-writer: Publish to staging environment (staging.tech.sailjada.com), schedule social posts 24+ hours out
  • frontend-builder: Deploy to CloudFront distribution E2LMRZX5K0Q0YO (staging stack only), request DNS change approvals
  • infra-ops: Modify Route53 records, adjust RDS parameters, create/modify IAM policies
  • orchestrator: Send customer emails via jada_blast.py, approve payment reconciliations

Tier 3 (Refuse): Actions with irreversible consequences or security implications

  • All agents: Delete S3 buckets, drop database tables, publish to production without orchestrator approval, modify billing or pricing, access customer PII beyond operational need, commit unsigned code
  • infra-ops specifically: Modify CloudFront cache behaviors without staged rollout, create public S3 buckets

Implementation: Each agent's instructions include a policy block that checks the action category before proceeding. Example from infra-ops.md:

AUTONOMY_TIER_CHECK:
- If action modifies AWS security groups, IAM roles, or Route53 records → Tier 2
- If action deletes resources or modifies billing settings → Tier 3 (refuse)
- If action is template generation or documentation → Tier 1 (proceed)
- When in doubt, escalate to orchestrator with justification

Infrastructure: Enforcement Architecture

The tier system isn't merely declarative—it's enforced through concrete gates:

  • Content-writer publishing gate: The jada_blast.py script (invoked only by orchestrator) is the sole production email sender. content-writer can draft and queue, but cannot import or invoke this module directly.
  • AWS credential scoping: infra-ops runs under an IAM role restricted to CloudFormation template generation and read-only CloudFormation describe calls. Template application requires orchestrator approval and manual aws cloudformation deploy execution.
  • Progress dashboard as approval queue: Progress dashboard cards at progress.queenofsandiego.com (state file: s3://progress.queenofsandiego.com/state.json) now include a needs_approval field. Orchestrator checks this field before allowing downstream action.
  • Scheduled checks, not human-triggered checks: A nightly cron job (via CloudWatch Events) invokes orchestrator to reconcile Stripe payments against the "Bookings" tab in the JADA Booking Requests sheet. Results are logged to the progress dashboard. The human reviews the log once on waking, not in real-time.

Key Decisions: Why This Pattern

Why autonomy tiers instead of a single approval bottleneck?

The original model required human approval for nearly every agent action. This broke when the human was asleep, tired, or context-switching between charter operations and software development. Autonomy tiers flip the logic: humans say "here's what you can do safely" once, at rest, and then agents execute within those boundaries without needing live approval.

Why Tier 2 queues instead of immediate execution for bigger changes?

Reversibility is the key metric. Deploying to staging is low-cost to revert (flip a DNS record or S3 alias); modifying a Route53 record for a production domain is high-cost to revert (DNS propagation, customer impact). Queuing defers final approval to when someone is actively monitoring, without blocking routine work.

Why explicit Tier 3 refusals instead of just "don't do this"?

Humans forget warnings; systems don't. An agent that encounters a Tier 3 action doesn't proceed tentatively and ask for forgiveness—it refuses loudly, explains why, and escalates with justification. This removes the "oops, I thought you meant I could..." failure mode.

Verification and Monitoring

The tier system is useless without audit trails. Each agent logs its decisions to a timestamped JSON file in ~/.claude/audit/:

~/.claude/audit/content-writer-2026-07-02.jsonl
~/.claude/audit/infra-ops-2026-07-02.jsonl
~/.claude/audit/frontend-builder-2026-07-02.jsonl

Format: {"timestamp": "2026-07-02T06:15:30Z", "action": "draft_caption", "tier": 1, "target": "instagram", "status": "completed"}

A weekly audit job scans these logs for anomalies (Tier 2 actions that never got approved, Tier 3 refusals, repeated escalations) and surfaces trends to the human. This is visibility without being the bottleneck.

What's Next

  • Enforcement hardening: Move from policy-in-instructions to hard code guardrails. Agents should not be able to bypass tiers, even with creative prompting.
  • Scheduled routines: Build the morning digest and nightly reconciliation as CloudWatch Events + Lambda, not human-triggered jobs.
  • Tier promotion: As confidence grows in an agent's judgment within Tier 2, promote specific action categories to Tier 1 (e.g., "publish to staging after 24-hour delay" → "auto-publish to staging").
  • Orchestrator state machine: Formalize approval flows as a state machine in the orchestrator, with explicit state transitions and audit logs for every approval decision.

Cost impact: Zero—this all runs on the free plan. The "spark of creativity" spent once designing the tiers is reused for free every time an agent executes within a boundary.

```