How Muse works: a breakdown of its architecture

Based on Meta's public documentation, checked September 27, 2026. This is a conceptual map of the product, not a complete internal specification.

Architecture at a glance

1. The client is how you direct the agent

Meta says Muse can be reached through mobile and web clients and through WhatsApp. You give it a task or goal, and it can keep working after you leave the app. The interface also exposes activity, goals, permissions, and approval requests, so you can see what it is doing and intervene. Read Meta's product design explanation.

2. The Secure VM is the working computer

Each Muse runs in a dedicated Linux virtual machine in the cloud, according to Meta. It has storage, a browser, compute, and a workspace where the agent can create files and tools. Meta describes the VM as the system of record for the user's Muse data. The main agent runtime sits in a restricted cell inside that VM. Sensitive services, including credential storage and permission checks, run outside the cell.

This separation matters because the agent reads web pages, files, and other untrusted material while completing tasks. Its runtime can work with those inputs without receiving unrestricted access to the host, real credentials, or the network. Meta provides the technical details in How We Built Safety Into Muse.

3. Muse Spark supplies the reasoning

The Muse Spark model family provides the reasoning and tool-use abilities behind Muse. Meta's launch material names Muse Spark as the model powering the personal agent, and its security write-up discusses Muse Spark 1.3. The product adds a long-running runtime, workspace, tools, and permissions around the model. Meta says model inference uses a constrained path out of the VM, so the model and the user's working computer are distinct parts of the architecture. See the Muse Spark 1.3 overview.

4. Browser, connectors, and skills turn plans into work

Muse can use a browser to navigate sites and complete web tasks. It can also use connectors for services with APIs and skills that explain how to use those tools. Meta says built-in connector logic runs with limited privileges outside the agent runtime, while a broker gives the browser subagent a controlled interface. Explore our source-linked connector directory for examples.

Meta also describes background schedules, multiple subagents, and the ability to build custom tools when a task requires them. These capabilities help explain how one request can become a longer workflow instead of a single model response.

5. Sentinel and credential services control access

Muse proposes a connector action or network request. A separate system called Sentinel decides whether it is allowed, denied, or needs your approval. Credentials are held by a dedicated service outside the agent's runtime, so the agent does not need to read real passwords or tokens to use an approved connection. Meta says approval requests go directly to the client and can be scoped to a particular action or period of time.

This adds a boundary between an agent's plan and an external action. It does not make every result correct: Meta says Muse can make mistakes and that prompt injection remains an open problem. See the security architecture write-up.

What happens when you ask Muse to do something?

This sequence is a simplified explanation assembled from Meta's published material. It is not a trace of every internal call for every task. For a way to assess an outcome, read our evaluation guide.

Primary sources

• Meta's Muse launch announcement
• How We Built Safety Into Muse
• How We Designed Muse
• Introducing Muse Spark 1.3