Most of what happens on this stack happens while nobody's watching. The static sites rebuild themselves, DynamoDB tables get written and read by scripts that never sleep, and launchd fires jobs at hours I'm not awake for. Yesterday's work was about tightening the loop between "unattended" and "useful" — making sure the things that run without me still move the business forward, not just churn.
I've been running a recurring, unattended Claude job on the estate Mac — call it the Foreman. It has one job: find and finish one meaningful unit of work per run that increases realized revenue, then leave a log. No back-and-forth, no approval loop, because there's nobody on the other end to approve anything at 4am. That constraint is the whole design problem. An agent that can ask questions is easy to build. An agent that has to make a good call alone, every time, on a fuzzy objective like "increase revenue," is not.
The fix isn't a smarter prompt, it's a narrower one. "One meaningful unit of work, executed completely" beats "help out where you can." Vague directives produce busywork — an unattended agent with no scope will happily reorganize files instead of touching anything with real leverage. The rev-1 version of this directive is deliberately blunt about the single objective so the agent can't drift into feel-good tasks that don't move a number.
The lesson holds outside this one job: for any process that has to run without a human checkpoint, the safety mechanism is a narrow, falsifiable goal — not extra caution baked into the prompt. Caution without a target just produces an agent that does nothing.
Separately, a crew member asked a very ordinary question — which upcoming charters he's confirmed for, and which ones still don't have a first mate. That's a two-minute lookup against the crew dispatch table, but it's the kind of two-minute lookup that happens weekly, differently phrased, for whichever crew member texts in that day.
So it became a skill instead of a one-off answer: pull live from the crew-dispatch table, render one person's confirmed charters plus the open slots for their role, write the draft out, and stop. It never sends on its own — a human sends the text. That last part isn't a nice-to-have. Anything that touches a real person's phone gets a human in the loop before it leaves the machine, full stop. The value of automating this isn't removing the human from the SMS, it's removing the human from the lookup.
The pattern is the same one showing up everywhere in this stack now: deterministic script does the data work (query DynamoDB, format the message), the model writes the two or three sentences that need judgment, and nothing ships without a person's thumb on it. Draft-only by default, sent by exception.
Both of yesterday's builds are really about the same question: what's the smallest, safest unit of autonomy you can hand to a process that runs when you're not looking? For the Foreman, that unit is "one revenue action, fully executed, logged, no permission needed." For the crew-schedule skill, it's "one accurate draft, zero unsupervised sends." Different domains, same shape: narrow the scope until the failure mode is boring instead of expensive.
foreman: one revenue unit / run, no approval, full log crew-sms: live DDB read -> rendered draft -> human sends shared rule: autonomy scales with how boring the failure is
Tomorrow's candidate for the same treatment: the follow-up pipeline, which still has a human eyeballing every queue item before it fires. Worth asking whether that's caution earning its keep, or caution that's just slow.