10 / Practices
Practices and tips: the resource core
Everything below was learned the expensive way, and each practice carries the receipt that bought it. None of it requires anything beyond Muse itself: chats, standing files, memory, and the discipline to write the rule down when it is learned.
Practice 01
Run a pre-flight before any question reaches the human
The rule: the agent checks every source it has before it spends the human's attention. In this household the checklist has seven steps: memory searched under several phrasings, direct relationship records, duplicate or stub identities, the last seven days of work files, the people pages, every comms channel, and, for photo questions, whether the person appears in the photos at all. Only when all seven come up empty may the question be asked.
Your memory search, saved files, and connected accounts are the pre-flight. A question that evidence could have answered is not diligence. It is a tax.
Practice 01 / 13
Practice 02
One question at a time, at the end, as tap options
The rule: a decision request is one question, placed at the end of the message, offered as tap options. Never bundled into a list, never buried in the middle of a report. If the choices are re-shown, the question is restated with them.
In Muse this is a formatting habit with an outsized effect: the human answers in fragments, often one word, and the work keeps moving. A batch of five questions gets none answered; five single questions get five.
Practice 02 / 13
Practice 03
Ask only for ground truth or genuine preference
The rule: the human is asked only for facts about their own life that no source can resolve, or for a real preference or consent choice. Everything else is the agent's job to determine from evidence.
This is a rule you write into the standing files, because a helpful agent's default is to escalate. Escalation feels safe. It is actually the most expensive thing the agent can do.
Practice 03 / 13
Practice 04
Verify uptake by claims and read-backs, never by status text
The rule: work is real when there is a work product or a recorded claim under the worker's name. A status that says "working" proves nothing.
The Muse equivalent: when the agent says a file was written, a job was scheduled, or a message was sent, ask for the read-back, or have the agent show it unprompted. The household rule for delegated work is that a dispatch counts only when a claim or a deliverable exists under that runner.
Practice 04 / 13
Practice 05
A fix is not done at commit, merge, or deploy
The rule: done means verified live, in production, doing the thing it was built to do. Every earlier stage is a progress report, not a completion.
In Muse this changes how you let the agent close work: the closing message names the live check performed, not the steps taken. Merged is a claim. True is one live check away, and the check is the job.
Practice 05 / 13
Practice 06
Treat background numbers as unverified until spot-checked
The rule: any aggregate an agent reports from a background process is a lead, not a fact, until a fast foreground check reproduces it.
In Muse this applies to every summary, census, and digest the agent hands you. Pick one number, ask how it was produced, and have it re-derived in front of you. The habit is cheap, and it catches what confident formatting hides.
Practice 06 / 13
Practice 07
Probe capacity; do not remember it
The rule: whether a model lane, a worker, or a service is available is a fact you check now, not a state you recall from yesterday.
This shows up as routing decisions: work was steered around a lane believed to be exhausted for a full day after its usage window had already reset. A stale belief about capacity is indistinguishable from a real limit until someone probes it, so the probe is part of the routine. The correction is doctrine: a capacity belief expires, and the transition is reported the round it is observed.
Practice 07 / 13
Practice 08
Never accept a fabricated absence
The rule: "not found" must state the scope of the search. An absence inside one index is not an absence in the world.
When the agent reports that something does not exist, the follow-up is mechanical: where did you look, and what would it look like if it were somewhere else? Occupancy reporting in this household runs on the same principle: unknown while dark, never a fabricated absent.
Practice 08 / 13
Practice 09
Pre-register kill criteria, then honor a negative result
The rule: before an experiment runs, write down what result would kill it. When that result arrives, kill it, even if the signal looks interesting.
In Muse this is how you keep a tireless agent from turning every prototype into a permanent resident. The criteria go in the chat or the project file before the run, where enthusiasm cannot edit them afterward.
Practice 09 / 13
Practice 10
Ingest before you delete
The rule: nothing gets retired, deleted, or replaced until its history is proven to exist somewhere durable, at entry level, not by summary.
This is the safe way to close chats, retire tools, or switch providers: prove the archive holds the material first, then delete. The proof is a count and a sample, not a green checkmark.
Practice 10 / 13
Practice 11
Restate the question when you re-show the choices
The rule: tap options never travel alone. Every re-presented choice carries the plain-text question it answers.
In Muse this sounds trivial until a widget fails to render or a conversation compacts, and the human is staring at three buttons with no idea what they decide; the household's name for that failure is "completely unhelpful."
Practice 11 / 13
Practice 12
Convert a refused manual step into tracked work
The rule: if the human declines to do a step by hand, the agent does not argue and does not drop it. The step becomes a tracked work item with the exact specification attached, plus a note of what is already done.
The human's "I'm not doing that" is information about where their effort belongs, not an obstacle. The agent files the work, states the one blocked step plainly, and pre-does everything around it.
Practice 12 / 13
Practice 13
Corrections land in standing files the same day
The rule: a correction, a preference, or an agreed behavior is written into the standing files or memory the day it is agreed. A promise that lives only in one chat's transcript does not exist for the other chats.
This is the mechanism underneath everything else on this page. Chats snapshot their instructions at the start; an old chat runs an old copy. The standing files are the only place a lesson becomes permanent.
Practice 13 / 13