Butler

Before Butler, I handled my own admin by hand: reading mail and paperwork, deciding what needed a task or a date, and keeping the rest in notes.

The parts worth automating were narrow: sorting incoming mail and documents, tracking dates and tasks, and drafting routine phrasing. The parts worth keeping manual were anything that commits me to something, or costs money, or leaves the house.

The design question was never "can a model do this," it was which of these 20 tools a given task actually needs, and what a model with those tools could do wrong.

Three model tiers, chosen by call site. Haiku classifies incoming mail and reads scanned documents and photos first-pass, as a one-shot call holding zero tools: its output is text a human or deterministic code checks afterward.

Sonnet runs the interactive chat, briefs, and nudge phrasing, and is the only context with write tools and web access. Opus handles the vision adjudicator's escalation path and the monthly finance review, both low-frequency and high-judgment.

Every context (interactive, ceremony, finance, ingest) carries its own tool allowlist, not one shared list. Ingest, which reads whatever a document or email says, gets no tools at all. Text from outside the owner's own typed input is wrapped in a labelled fence with an explicit instruction that it is data, never a directive, before any model sees it.

A prompt or tool-allowlist edit does not ship on green CI alone. Every prompt file and every context file is hashed; a test fails until a live run against the real service has signed a receipt for that exact hash, and CI itself only ever runs the deterministic half of the test set, on purpose, so the model subscription never sits behind an automatic push.

Rules

• No send tool exists; outbound messages live in transport code the model cannot reach
• Ingest classification and document/vision reads run with allowedTools: [] and no MCP server
• db_read accepts only a single SELECT statement, rejected in code if it contains a write verb
• A document- or mail-derived proposal is staged; only a human tap on "Save" writes the row
• A kill switch is checked before every model call and stops all of them at once

Evals

• 59 golden cases across canaries, documents, email, factual answers, refusals, and RSS
• 53 run deterministically in CI on every push; 6 need real credentials and run on the box
• A dedicated canary asserts untrusted text is fenced, with an instruction attached, everywhere it reaches a model
• Editing any prompt or context file changes the hash CI checks, so an untested change cannot pass silently

There is no rollout to describe: I am the only user of this system, running on a box I administer myself. There is no adoption story here beyond my own use, and the site does not claim one.

PLAN.md is the decision record every change is checked against. AI coding agents write the code; a local gate (typecheck, tests, the eval set, a web build) must pass before deploy, and deploy itself refuses a dirty tree or unmerged work. A prompt or tool-allowlist change carries one more gate: a live run against the real service, on the box, before CI accepts it.