What Goes Wrong: Muse Failure Modes and How to Recover

I trust Muse with a lot of my week. That trust is earned, and it was earned the hard way: through the misses. There is the Tuesday it approved its way through a task I never looked at. The morning it sent a summary so polished I forwarded it before noticing the dates were wrong. The routine that quietly ran twice a week longer than it should have. None of these were malfunctions. They were failure modes, and every one of them has a warning sign and a fix.

Meta’s own documentation is honest about this: Muse can still make mistakes, and prompt injection remains an open problem. The architecture (a Sentinel that approves outside actions, an audit trail of everything done) exists precisely because the people who built it know it will get things wrong. This lesson is the practitioner’s version of that honesty: what goes wrong in daily use, how to spot it early, and how to recover.

Failure mode 1: Approval fatigue

Sentinel is the sole permission authority for connector actions: Muse proposes, Sentinel allows, denies, or asks you. Approvals can be granted once, for a session, for a task, for a limited time, or permanently. That flexibility is the trap. Grant approvals freely enough and a dialog pops up every few minutes. You stop reading. You tap approve. The safety system keeps running, but the human in the loop has checked out, which is the failure mode the system was built to prevent.

Warning sign: you approve a request without reading what it actually says. The moment an approval dialog is a reflex tap, you have approval fatigue.

Fix: move the decision to the right place. Low-risk reads (checking a calendar, looking up a price) can run unattended. Anything that sends, spends, deletes, or publishes waits for your yes, one at a time. This is exactly what the specialist setup is for: each specialist sets its own approval line, so the expense review asks while the news brief runs alone. Never grant a permanent approval to a job you would not trust to run at 3am while you sleep.

Take the wheel when: an approval dialog surprises you, meaning the request does not match what you thought you asked for. Deny it, ask Muse to explain what it was trying to do and why, and check the audit trail. The surprise is the signal.

Failure mode 2: The vague brief

Give Muse a vague brief and it does the most dangerous thing an agent can do: it fills the gaps with confident guesses. The output comes back polished, structured, and wrong in the details. Wrong names, wrong dates, wrong assumptions about what you meant. The fluency is the problem. A rough draft that is obviously rough gets corrected. A confident draft gets forwarded.

Warning sign: the output looks great on first read. If you find yourself nodding at the structure before you have checked a single fact, slow down. My rule now: if I cannot find the decision I made in the output, the brief was the problem.

Fix: the brief is the whole job. Our task-brief lesson has the full format, but the short version is this: what the task is, what done looks like, what is off limits, and what Muse should ask you before doing. Add a proof requirement to any research output: “cite your sources.” A Muse that has to show its work invents less.

Prompt 1: The brief repair

When a brief produces bad output, do not fix the output. Fix the brief. Paste this:

That output missed the mark, so let’s fix the brief instead of editing the result. Tell me exactly what was ambiguous in my instructions: what you had to guess, what you assumed, and what a better brief would have specified. Then rewrite the brief for me in the [context, job, done-criteria, off-limits, ask-me-first] format so I can reuse it.

This turns a failure into a reusable asset. Save the rewritten brief. You will need it again.

Failure mode 3: Context rot

Long conversations decay. A thread that started as trip planning becomes a research session becomes an email draft, and somewhere in the middle Muse starts working from assumptions that were true two topics ago. It remembers the wrong thing, or it remembers the right thing from the wrong context. The memory lesson warned about mixed buckets; this is the same problem in real time, inside a single conversation.

Warning sign: Muse references something you said “earlier” that does not belong to the current task, or its tone and assumptions feel like they drifted from a different job. Also: you catch yourself scrolling up to remember what you actually asked.

Fix: one thread per job. When a conversation changes purpose, start fresh and hand the new thread a one-paragraph handoff instead of the whole history. If you do run long sessions, end them with a checkpoint: “Summarize where we are and what is left, in five bullets.” That summary becomes the handoff. And audit memory weekly: our memory lesson shows how corrections that compound in the wrong place become their own failure mode.

Failure mode 4: Runaway jobs

A scheduled routine that should take ten minutes runs for an hour. A task loops on a retry. A routine quietly keeps running long after the job stopped needing it, doing redundant work on your behalf. Agents do not get tired or bored, so a job with no end condition does not stop. It just keeps going, at your expense.

Warning sign: you notice the same routine mentioned in its reports with no new findings, or a job you set up “temporarily” is still running weeks later. The subtler version: a report lands every morning and you stopped reading it, so you would not know if the work underneath had changed.

Fix: every routine needs three things written down: what success looks like, what it must never do without asking, and when it expires. Put an end date on every experiment. And read the reports. A routine whose reports nobody reads is a routine that is not supervised.

Take the wheel when: a job runs longer than it ever has before, or its report looks different from the usual pattern. Stop it, ask what changed, and do not restart it until you understand the answer.

Prompt 2: The Friday failure audit

Once a week, ten minutes, this is the single highest-value habit in this lesson. Paste it:

Review this week’s work and give me the failure audit: three moments where I gave you a vague brief and you had to guess, two approval requests I waved through that deserved more scrutiny, and one standing instruction or memory note that is now stale or wrong. For each, tell me what to change. Flag anything you’re unsure about instead of guessing.

Expect it to be uncomfortable the first time. That is the point. Every item it names is a correction you can turn into a durable rule, which is how memory is supposed to compound.

A named setup: The Friday Debrief

Here is the concrete workflow that holds all of this together. Mine runs every Friday at 4pm as a scheduled routine, and it has a name I say out loud: “The Friday Debrief.”

Job: A ten-minute end-of-week review of everything Muse did for me that week.

Needs: Chat only, plus read access to the week’s routine reports. No connectors that can act.

Procedure: 1. List every routine that ran and what each one produced. 2. Run the Friday failure audit (Prompt 2 above). 3. Check each routine against its written success criteria: did it earn its keep this week? 4. Flag any approval request I approved without discussion. 5. Propose updates to standing instructions and memory notes, and wait for my yes before changing anything.

Won’t lines: Never change a standing instruction without my explicit yes. Never mark a routine as “fine” without evidence. Never skip a week.

Approval rules: Runs fully unattended through step 4. Step 5 always waits for my yes, one change at a time.

The Debrief is the difference between running Muse and supervising it. Ten minutes a week, and it catches the drift before the drift costs you anything.

What can go wrong

The honest note on this lesson: the recovery itself can become a failure mode. After a bad miss, the temptation is to clamp everything down: approvals on every action, check every output, read every report line by line. That lasts about three days. Then the fatigue returns, worse than before, because now there are more dialogs to wave through. I did this after the Tuesday incident mentioned at the top. A week of approving everything taught me nothing except how fast I could stop reading.

The fix is the opposite of clamping down. Loosen approvals on the low-risk jobs (reads, lookups, drafts) and keep the approval line only where it matters (sends, spends, deletes, publishes). Fewer approvals, each one taken seriously. A small number of meaningful approvals beats a large number of rubber stamps. That is the whole philosophy: supervise less, but supervise what counts.

Supervise what counts

Muse is a good operator with bad judgment at the edges. It will do exactly what you asked, confidently, even when what you asked was vague. It will ask your permission a hundred times until you stop reading. It will keep running a routine long after you stopped needing it. They are the shape of the tool, and the shape does not change. What changes is the supervisor.

Start with the Friday failure audit. Run it once, act on what it finds, and set up the Debrief. Ten minutes a week is the cheapest insurance in your entire workflow.