Meta introduced Muse on 8 September 2026 as a personal AI agent that works from a dedicated cloud computer. Its launch announcement describes an initial US rollout on the web, iOS and Android, with messaging through WhatsApp. The product can continue work after the user closes the app. Meta says a stronger Confidential VM option is planned for later this year, rather than available as part of the initial system.

For Australian readers, that US launch boundary is important. The announcement is not confirmation of local availability. It is nevertheless a substantial development in the personal-agent category: a service intended to carry out continuing work, rather than simply provide an answer to the next question.

A continuing relationship with unfinished tasks

In Meta's product-design account, Muse has a main conversation, optional side chats and a Goals view for tracking longer-running work. Users can inspect activity and permissions, and read or edit memory files. The account also describes generated artefacts such as documents and interactive outputs. These features aim to make background work visible instead of leaving it hidden behind a chat reply.

That visibility matters because delegation creates a different kind of uncertainty from ordinary search. The user needs to know not only what the system found, but what it has already done, what it intends to do next and what remains blocked. An attractive summary is not enough if it is difficult to distinguish a proposal from an action that has taken effect.

Our assessment is that a useful personal agent should make those states easy to recognise. A task awaiting permission should look different from one awaiting new information. A failed attempt should remain visible, with an explanation of what did not happen. Those are evaluation criteria for users, not a claim that this launch eliminates every ambiguity.

The permission authority sits outside the main agent

Meta's technical security explanation describes a separate Sentinel that authorises connector actions and outbound network requests. The main agent runs within an isolated runtime, while credential handling and other security services sit outside it. Meta says the agent receives substitute tokens rather than seeing actual credentials. Approvals can be scoped, and the system can ask the user when an action needs permission.

The important architectural idea is separation of responsibility. A model trying to complete a task should not also be the only component deciding whether every proposed action is acceptable. If the model misinterprets an instruction, an independent enforcement layer provides another opportunity to stop an inappropriate operation. That is a design advantage, not evidence that failures are impossible.

Meta itself acknowledges that Muse can make mistakes. Users should assess the behaviour of the complete system, including the permission interface and connected services. The fact that a password is hidden from a model does not mean every action performed with that account will be correct. Authorised access and correct judgement remain separate questions.

Start with a narrow permission boundary

A cautious first trial could involve organising public information or preparing a draft that the user will review elsewhere. Move to connected personal information only after understanding what the agent can read, what it can change and how to revoke the connection. This staged approach is our suggested evaluation method, not a statement about mandatory onboarding steps.

When reviewing an approval, look for the actual destination, the proposed action and the scope of access being granted. A one-off task should not casually become permission for an unrelated class of future actions. If the explanation is unclear, stop and narrow the request. Convenience should make an informed decision easier, not make approval automatic.

For background jobs, establish what would justify an interruption. A useful update might mean the task is complete, a material condition has changed or a decision is needed. Repeated messages that say nothing has changed can train a user to ignore the system. Conversely, silence should not hide an error that prevents the task from continuing.

Privacy promises need their own timeline

The distinction between the initial Secure VM and the planned Confidential VM is particularly important. A roadmap feature should not be used to describe the protection of data entered today. Before connecting a sensitive service, users should read the current product documentation and settings for the version they can actually access.

A practical evaluation should also include ordinary recovery questions. Can the user identify and stop a running task? Can they inspect what happened before an error? Can they remove access without losing track of unfinished work? Those questions are less dramatic than a product demonstration, but they determine whether a personal assistant remains manageable over time.

Muse brings a dedicated execution environment, continuing tasks and explicit controls into a consumer-oriented product. The promise is useful delegation without requiring the user to manage the underlying computer. The test is whether that delegation remains understandable and bounded in everyday use. Until broader availability is confirmed, Australian users should treat this as a US launch to watch, not an invitation to assume local access or future protections are already in place.