Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Building Agent Autonomy Tiers to Eliminate Founder Bottleneck in JADA Operations

The Problem: Single Human as SPOF

When a solo founder is the approval gate for every decision—content drafts, infrastructure changes, customer communications, crew scheduling—the business stalls every time that founder sleeps, travels, or is simply exhausted from the previous day's charters. This isn't a scaling problem you can solve with more Claude API calls; it's an architecture problem. You need scheduled, autonomous agents operating within explicit policy boundaries, not smarter humans doing the same gatekeeping work faster.

What Was Built: Autonomy Tier Architecture

We restructured four existing Claude agents (content-writer, frontend-builder, infra-ops, orchestrator) from general-purpose "ask permission for everything" to role-specific autonomy tiers:

  • Tier 1 (Just Do It): Tasks with zero safety downside. Content-writer drafts social captions; frontend-builder updates non-customer-facing UI; infra-ops runs diagnostics and logs output.
  • Tier 2 (Queue & Notify): Actions that need policy check but not full approval. Money changes, pricing, public commitments, safety-critical infrastructure changes get tagged with needs-you and queued to a progress-board card.
  • Tier 3 (Human-Only): Decisions above the agents' grade. Major architecture changes, customer refunds, legal/compliance decisions.

Agent Configuration Changes

Each agent in ~/.claude/agents/ was updated with explicit policy rules. Example structure:

---
name: content-writer
tier: autonomous
boundaries:
  - can_draft: true
  - can_publish_public_channels: false
  - can_commit_to_deadlines: false
  - needs_approval_if: any change to pricing, promises, or customer-facing dates
---

The orchestrator agent became the policy enforcer. It now:

  • Intercepts outbound messages and checks them against jada_blast.py approval gates
  • Routes high-stakes actions (Stripe charges, public commitments) through an approval queue at progress.queenofsandiego.com instead of blocking the agent
  • Logs all actions to an S3 decision log for audit and learning

Scheduled Dispatch Automation: The Nappi Charter Example

To test autonomy in production, we automated crew dispatch for the Jul-18 Nappi double charter. Previously, this was a manual bottleneck:

  1. Check JADA Booking Requests sheet (Google Sheets)
  2. Query SMS utility for crew phone numbers
  3. Compose and send SMS to captain, first mate
  4. Compose and send SES email to deck crew
  5. Mark dispatch as sent in ops log

The automation chain:

$ python3 charter_provisioner.py --days 30
# Reads from JADA Booking Requests (Bookings tab, not Sheet1)
# Pulls contact metadata from icloud-jada-ops SMS utility
# Returns JSON: [charter_id, captain, crew, contact_methods]

$ python3 crew_dispatch.py --charter-id nappi-jul18
# Sends SMS to captain (Darrell +16199923487) confirming role
# Sends SMS to first mate (Travis +15302625427) with offer
# Sends SES email to deck crew (Rick, Angelia via SES to admin@queenofsandiego.com)
# Stores MessageIds and timestamps in /icloud-jada-ops/drafts/

The crew dispatch succeeded at 9:03 AM without human intervention. SMS to Darrell and Travis delivered and logged; SES email to Rick/Angelia queued (MessageId: 0100019f28b991c9…). Magic links intentionally withheld—those follow the 72-hour TTL rule and go out ~Jul 15–16, closer to event date.

Infrastructure: Three Layers

  • Sheet API Layer: jada_google.py module wraps Sheets v4 API. Reads from JADA Booking Requests (SID: 1--kOrRP4WKN2Uu862ZbIZkJcJfv3qrBy2fuDDD9bltA). Credentials managed via repos.env.
  • SMS Layer: ~/bin/read-sms utility queries SMS history for crew contact numbers. Supports --limit flag (50 recent messages shown). Integrates with local phone contact metadata.
  • Email Layer: SES via boto3. Sends from JADA ops account to crew, Bccs admin@queenofsandiego.com for audit. MessageIds logged for delivery tracking.

Scheduling happens via cron. Crew dispatch runs at 9:00 AM on charter day. Morning digest (not yet built) will reconcile overnight bookings at 6:00 AM and queue urgent items.

Key Decisions: Why This Approach

No more plan tier spend. This runs on your current Haiku 4.5 plan. The "spark of creativity" gets spent once—designing the autonomy tier policy—and then it scales free.

Visibility without bottleneck. Instead of real-time monitoring, you review a decided log once when you wake. Progress board shows what happened overnight, what's waiting on your judgment, what already resolved itself.

Cron-scheduled beats human-triggered. The organization keeps moving on a clock (6 AM digest, 9 AM crew dispatch) whether you slept eight hours or crashed at 9 PM. Work stops waiting for your consciousness.

Policy, not approval. Most "should I do this?" moments get answered by a rule you set once while rested. Agents operate inside that boundary without waking you for every call.

What's Next

Three priorities in order:

  1. Morning digest (6 AM): Automated Stripe reconciliation against Booking Requests sheet. Flags new bookings, failed payments, refund requests. Queues anomalies to progress board.
  2. Reactivation email engine: Queries historical guest data; sends targeted "ready to book again?" email to lapsed customers via SES. Campaign metrics logged to S3.
  3. Autonomy tier audit: Walk through your agent definitions one more time. Anything tier-2 that could be tier-1 (fewer interruptions)? Anything tier-3 that should stay tier-2 (you didn't realize you could delegate it)?

The guest-page draft (rendered) and vendor order (wreaths, petals, champagne, cannoli) are still waiting on your review. Everything else is running on the clock now.

```