Muse wants to do the work. Who holds the controls?

The task continues after the chat

Imagine asking an assistant to prepare a weekend trip. The useful result is a workable plan, a shortlist that fits your constraints, and help completing the steps you approve. Each step requires the system to carry context forward and interact with something outside the conversation.

Meta introduced Muse on September 8 as a personal agent for tasks and longer-running goals, with a US rollout across mobile and web. The company describes a dedicated virtual computer with its own browser, connections to everyday services, and conversations through the Muse app or WhatsApp. These are Meta’s product claims; this article is a reading of the published design, rather than a hands-on performance review.

The interesting shift is how responsibility changes when a product can keep working. A helpful suggestion can be ignored. An action needs a clear owner, a defined scope, and a record that someone can check.

Permission becomes part of the interface

Meta’s technical explanation describes a separate component called Sentinel. It checks connector actions and network traffic against policy. The working agent receives substitute credentials; real secrets are supplied at the network boundary. The design separates proposing an action from having the authority to execute it.

Meta also describes approval for sensitive actions, controls over connected services, and an activity history. That creates a useful lens for evaluating the product: can a person understand the proposed action before approving it, and reconstruct what happened afterward?

The diagram below summarizes Meta’s published architecture. It is a conceptual map of the checks, not a claim that every action always follows one rigid sequence or that the system cannot make mistakes.

A better test than a spectacular demo

For a trip-planning example, start with a reversible research task. Ask for options and inspect how the agent handles a missing date, a conflicting price, or a website it cannot access. Those ordinary failures reveal more about a workflow than a perfectly staged booking.

Then examine the moment of commitment. The person approving a purchase needs the destination, total price, relevant conditions, and payment scope in one understandable view. A vague request for permission pushes the reasoning burden back onto the user.

Our evaluation checklist is deliberately practical:

• Scope: can you see which services the agent can read or change?
• Approval: does the request explain the concrete action and its consequence?
• Evidence: can you inspect the sources and the activity record?
• Control: can you stop ongoing work, disconnect a service, and edit remembered information?

Keep the privacy promises precise

A dedicated VM is useful isolation, but the current Secure VM should not be confused with the planned Confidential VM. Meta’s safety explanation says the current service does not cryptographically prevent Meta from accessing data when necessary to operate it. Confidential VM was described as coming later in 2026. The same explanation acknowledges that errors and attacks remain possible.

The September Connect announcements also broadened the roadmap, including additional connectors and payment integrations. Glasses support was still described as arriving in the coming months. A launch announcement, a limited rollout, and a feature available to a particular account are different things; availability should be checked in the product.

The controls are part of the capability

Our reading of Muse is that the interface for personal AI is expanding: goals, permissions, memory, and activity history now matter alongside the conversation. The ability to keep working creates value only when the person delegating the work can understand the arrangement.

That is a useful standard for every agent builder. Make progress visible. Make authority specific. Make the next irreversible step easy to recognize. An assistant earns a larger role one understandable action at a time.