← Queen of San Diego — Tech Blog
2026-09-02

Estate Board: What Happens When Two AI Agents Show Up to the Same Job

Today's entry starts with an org chart problem, not a code problem. A second AI agent (running on a different stack) got looped into JADA ops, and the first question out of the gate was the right one: how do two autonomous agents avoid duplicating work on the same boat, the same guests, the same DynamoDB tables?

The answer that emerged wasn't a new microservice, it was a protocol — check a shared status board before touching anything, claim a task by writing to it, and treat "in progress" as a lock. I've started calling this file the Estate Board. It's dumb on purpose: one line per active job, updated at session start, read before any agent picks up new work. No queue, no broker, no distributed consensus. Just a text file both agents agree to respect. The lesson: when you're about to reach for infrastructure to solve a coordination problem, check whether a shared, boring file solves it first.

SMS as the universal API

A recurring pattern today: almost every real task terminated in a text message, not a dashboard. Domain name suggestions for a family member's new venture, queued to SMS with a "reply with your favorite" prompt, then registered in Route53 the moment she approved. Payment links for upcoming bills, pushed to SMS so late fees don't happen. A charter guest's photo gallery, sent to SMS first so I could personally verify the scrub before it went out.

That last one matters more than it sounds. The guest-photo pipeline pulls the charter's shoot, and before any gallery link goes to a guest, it has to run a pass to strip any frames that happen to include my own kids. That's a manual gate for a reason — no amount of face-detection confidence gets to skip a human look before a stranger gets a link to family photos. The gratuity nudge on the guest page is automated; the privacy check isn't, and it stays that way.

The 136-file catalog

Separately, I pulled a personal Google Takeout export into a working directory along with an old agent session's zipped conversation history and asked for it to be read end-to-end and cataloged. That turned into a straightforward but satisfying scaling exercise: a subagent read all 136 files, built a five-section index, and wrote it to a single CATALOG.md so future sessions don't have to re-read the raw archive to find anything. The interesting part wasn't the cataloging itself, it was watching a subagent report back with a clean summary ("all files read, catalog written") instead of dumping the raw contents into the main context. That's the whole point of delegating to a subagent — it does the expensive reading, the parent session keeps a clean, cheap pointer.

The FedEx gap

The least glamorous entry, and maybe the most important: a charter went out today with only the trip sheet printed. The waiver and guest manifest — required paperwork — hadn't gone anywhere. That's a process gap, not a code bug: the pipeline that generates these documents runs fine, but nothing forces the "send to FedEx" step before a boat leaves the dock. Deterministic pipelines only help if every required output actually gets triggered. Next build item: a pre-charter checklist that blocks "trip sheet printed" from counting as done until waiver and manifest have shipped too.

Housekeeping

Also spent a few minutes untangling a model-pinning surprise — switching the default model at the CLI layer doesn't override a project's settings.json pin, which quietly wins back control on restart. Worth remembering before assuming a model switch "took."