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

Standing Directives and the Problem With Removing Yourself From the Loop

Yesterday's diary entry starts with a document that's been sitting at the top of the estate repo since August: the Mac Foreman standing directive, revision 2. The changelog note on that revision is the interesting part — "CB removed himself from the loop." One person, one boat, one small ops stack, and a decision to let an unattended, recurring agent run on the estate Mac with a single objective: increase realized revenue, one meaningful unit of work per run, executed completely, including the send.

That last clause is the whole ballgame. It's easy to write an agent that finds opportunity. It's much harder to trust one to close the loop — to actually push the follow-up, generate the proposal, queue the message — without a human re-reading every line first. So the rules that bound the directive matter more than the objective itself: plan-billed only, no new spending, and every client-facing send lands as a draft in a local folder, never auto-sent. The agent gets full authority to think and build. It does not get authority to speak to a guest without a human clicking send.

That draft-only boundary showed up again in a second pattern from the same day: the "bridge-foreman" runs. These are one-shot directives fired from a phone, routed through what the estate calls The Bridge, each one scoped to a single task on the Mac. Every one of them opens with the same paragraph of standing rules restated verbatim — plan-billed, drafts only, no new spending, crew notified through the same channel. Repeating the constraints in every directive instead of trusting them to be remembered is deliberate. A phone-dispatched agent doesn't get the benefit of context carried over from a prior session; it gets a clean slate and the full list of guardrails, every time. Redundant, but redundant is cheap and a wrong send to a real guest is not.

The other build worth logging is the PDF proposal skill, because it's a good example of minimizing where the model is actually needed. Charter proposals — private charters, celebrations, memorials at sea — go through a fixed pipeline: gather about ten facts, fill a template, run deterministic scripts for layout, rendering, link-fixing, and QR codes. The model's job is narrowed to roughly three short bespoke copy blocks. Everything else is scripted and repeatable on purpose. The fewer places the model has creative license, the fewer places a proposal can drift off-brand or get a fact wrong. "Deterministic except one step" is a nice design target for anything client-facing.

Then there's the nightly code reviewer, which reviews the day's diff against a narrower and blunter question than most review prompts: not style, not architecture — just, could this diff send a guest the wrong message, mis-charge a payment, or break a deploy. For a solo-operator stack touching client SMS, payments, and AWS, that's the review that actually matters at 2am when nobody's watching the terminal.

The lesson isn't new, but it keeps re-proving itself: autonomy and authority to send are two different grants, and the second one should be the harder one to get.