All columns

COLUMN · INSTAGRAM / FACEBOOK

Muse asks permission. What exactly are we agreeing to?

An assistant’s permission can last for one action, a task or indefinitely. This detail in Meta’s documentation matters more than the number of questions with a Yes button.

Editorial illustration: three prepared actions awaiting human approval
Editorial illustration, not an app screenshot.

In the September 29, 2026 Muse announcement for small businesses, updated October 8, Meta promises not to publish, send or spend without permission. The phrase is reassuring. It does not promise a new question before every action.[1]

Meta’s September 8 technical description lists one-time, session, task-scoped, time-bounded and perpetual permissions. A separate Sentinel system checks whether an action matches the permission granted. This is an important safeguard built into the design: the main assistant should not decide for itself how generously to interpret an instruction.[2]

For the business owner, the crucial question is what they have already authorised. Constant prompts offer little protection if nobody knows what each Yes covers.

Opening hours and refunds are different instructions

Imagine a workshop authorising an assistant to tell customers its opening hours. Offering a discount, setting a repair deadline and agreeing to a refund are different decisions. They all fit inside the convenient word “reply”, but the owner is unlikely to consider them one instruction.

Meta’s document describes permissions tied to a service or destination and a task. That gives the system something specific to check: is the assistant sending what was authorised, to the intended destination? “Be careful” would be much harder to verify. The owner still needs to understand where their chosen boundary lies.[2]

Asking again before every action is no solution either. An assistant that keeps interrupting to ask whether it may read information soon creates more work. Meta recognises this problem and allows low-risk or previously authorised actions without interruption. The owner needs to understand the assistant’s authority; the number of confirmation prompts is a poor measure of that control.[2]

Could a colleague understand the permission?

Suppose the owner hands over to a colleague. Can that colleague tell from the current permission what the assistant may do alone? If so, the instruction can be discussed and changed. If answering requires rereading a week of chat, it depends too heavily on one person’s memory.

Muse is interesting for its attempt to check consent before action, rather than simply promising to make work easier. Documentation does not prove the assistant will never make a mistake. It does provide a precise question: does the owner understand not just the draft post, but the permission under which it might be published?