# 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.

> **Receipt**
> the checklist is exercised constantly in the household's verification chat, where most candidate questions die in the pre-flight before they are ever asked.

**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.

> **Receipt**
> the verification chat has run on this format as a standing rule since October 19, 2026; the inbox triage surfaces exactly one question per pass the same way.

**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.

> **Receipt**
> when a test the agent had run showed a step failed 100% of the time, the operator's reply was "ok, so if the test showed that it failed 100% of the time, why are you even asking me?" The question was withdrawn and decided under the existing delegation.

**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.

> **Receipt**
> a dispatched worker pane reported "working" while it had no lane identity and its claim had been refused; the fix was verified by the claim landing.

**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.

> **Receipt**
> a committed and merged fix "rode the next shell cargo" that was never scheduled, while its tracking item was closed at commit time, erasing the debt. The chat's verdict became standing law: a fix is not done at commit.

**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.

> **Receipt**
> in one shipping session the agent misread truncated output, deleted a live snapshot, and quoted deployment identifiers that did not exist: the fourth fabricated identifier of that session. Corrections came from the on-disk logs, not the reports.

**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 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.

> **Receipt**
> a claim of "nowhere in your library" was narrowed on correction to "nowhere in one machine's text index," because another device's index had the item all along.

**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.

> **Receipt**
> a routing prototype scored 526 real requests and produced a genuine signal, an AUC of 0.804, and was still shut down because two free baselines nearly matched it. The verdict was "does not earn its keep"; the record was preserved, the prototype deleted.

**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.

> **Receipt**
> retiring two vendor fleets began with proving their histories were already in the household store: 926 sessions and 218,189 messages for one of them, including entry-level proof for every one of 557 distinct dead-letter items.

**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."

> **Receipt**
> after one such failure, the fix became a standing rule: options and question are always paired.

**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.

> **Receipt**
> a request to create an email filter by hand was refused in four words. The agent filed the item with the exact filter specification, so whoever implemented it later had only the single blocked step left.

**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.

> **Receipt**
> on October 20, 2026, a standing-rules note was propagated to 29 chats in five minutes, with the caveat recorded alongside: receipts prove delivery, not behavior change; behavior is proven later, by conduct.

Canonical page: https://www.niclydon.io/muse/deep-dives/practices.html