Meta Muse Architecture: Inside the Persistent Personal Agent Execution Environment

Overview: Muse as a Personal Execution Environment

Meta's Muse redefines the personal AI agent not as a single model call but as a long-running cloud execution environment. Each user gets a dedicated cloud VM with filesystem, browser, compute resources, and the ability to continue working after the client app closes. The architecture must satisfy four simultaneous requirements: the model sees the correct context for each turn; actions execute in a constrained environment; authorization decisions are independent of the model; and tasks can resume from real state after interruption.

Task Walkthrough: Booking a Business Trip

The author illustrates the loop with a concrete task: "Arrange next week's Shanghai trip — check calendar and email, find three flights and hotels, build an itinerary, alert me if total is under budget, and require my approval before payment." The request does not become an ever-growing prompt. Instead, the runtime assembles a working set for the current turn: goal, time constraints, user preferences, history, completed steps, available tools, and current authorizations. Muse Spark (the model) proposes the next action (e.g., read calendar, search flights). Hatch (the Agent Harness) dispatches the intent to connectors, browser, or file tools; tools return pages, files, errors, and permission status; the runtime extracts relevant results, persists state, and reassembles context for the next decision.

Three distinct facts must not be conflated: the model says "send email" (intent); Sentinel returns allow (authorization); the email service returns success (external side effect). Hours later the system must still answer: which step was committed? Which was only prepared? Would a retry duplicate the send?

The same pitfall appears in coding agents: an agent updates a config file but the retrieval index still holds the old version; the next turn may continue modifying along a stale configuration. Working tree, test results, and business receipts are external facts — model context holds only what the current reasoning needs.

Running Location: Dedicated Cloud VM with Two Security Domains

Meta's design premise: every user owns a personal cloud VM that persists across sessions. This enables continuous operation and unified management of browser, connectors, files, scheduled tasks, and memory within a single user boundary, but shifts isolation, credential, and privacy responsibilities to the platform.

The VM is split into two security domains:

Runtime Cell — handles untrusted input, runs Hatch and tools.

Cell-external services — credentials, authorization, database, safety detection.

The goal is explicit: one machine, two isolated security domains; the model never gets a shell with host root. This boundary limits blast radius if the agent misbehaves; user confirmation governs whether a specific action may occur. The author emphasizes these are often conflated but address different failure consequences.

Hatch and Runtime Cell: Workspace for the Model, Boundaries It Cannot Cross

Hatch (internal name for the core Agent Harness) drives the loop, organizes tools and workspace, and communicates with external safety services. The public safety article does not release full Hatch source but describes the runtime boundary precisely.

Runtime Cell uses systemd-nspawn with independent rootfs and virtual network.

Cell-internal root maps to an unprivileged host user; syscalls are filtered.

Linux capabilities are further narrowed — e.g., no CAP_SYS_PTRACE or CAP_NET_ADMIN — so container root ≠ host root.

Outside the Cell run hatch-safety, privsep, hatch-authd, Sentinel, database, inference and telemetry agents, communicating via Unix domain sockets.

Caller identity verified via SO_PEERCRED and peer ACLs.

This layering separates model-driven workspace from high-privilege services at the process, file, network, and credential level. Tool schemas only validate parameter shapes; they cannot enforce whether code reads host files, accesses internal networks, or sends results anywhere. Real security boundaries must land on system objects.

Sentinel: Model Proposes, Control Plane Decides

Sentinel is the independent security control plane. "Muse can propose actions; only Sentinel can grant execution permission." When a connector request arrives, Sentinel checks connector name, method, action category, object scope, and the user's original intent, returning allow, deny, or ask.

If confirmation is needed, the approval request goes directly to a deterministic client UI; the user's choice returns to Sentinel. The model cannot bypass this by claiming "user already agreed" in conversation.

Network egress also routes through Sentinel. Runtime Cell traffic passes a forward proxy and Linux network controls to Sentinel, which inspects hostname, resolved IP, port, protocol, HTTP method, path, and decoded request. A seemingly normal public domain resolving to an internal IP triggers SSRF protection.

This separates "what the model wants to do" from "what the system allows to affect." Planning stays with the model, execution with the Harness, authorization in a control plane the model cannot rewrite.

Credential Proxy: Agent Uses Capabilities, Never Sees Secrets

Personal agents handling email, calendar, and payments encounter OAuth tokens, login state, and payment credentials. Placing real secrets in model context or ordinary tool environments turns prompt injection into direct credential leakage.

Muse's solution: the agent only ever handles surrogate tokens . Real credentials are stored by hatch-authd and injected at the network boundary after Sentinel authorization. Even if the model is tricked into "print the key," it has no printable secret.

Three distinct responsibilities collaborate without any single component holding all power: privsep constrains which restricted process runs credential-related code. authd decides which authenticated caller receives which credential material.

Sentinel decides whether the current action is authorized.

Human password entry follows the same pattern: user inputs credentials in a protected UI; they go straight to secure storage; browser automation receives a one-time scoped injection; the main agent never sees the plaintext.

Tainted Egress: Read Private Data, Face Stricter Outbound Checks

Simon Willison's "lethal trifecta" for AI agents: read private data, touch untrusted content, communicate outward. A malicious snippet in email, hidden instruction on a web page, or downloaded file may try to chain all three.

Muse does not rely solely on model refusal. External content entering context is tagged; hatch-safety and independent classifiers detect threats; browser and connector capabilities are limited; Sentinel re-checks the actual network exit.

A key engineering design is tainted egress : once a tool process reads user data, kernel-level data-flow tracking marks it tainted. Clean requests that never touched sensitive data and match narrow rules pass automatically; tainted or unverified processes enter stricter policy or human review. This shortens the attack chain — the attacker must simultaneously control context, tool, and egress — but Meta explicitly acknowledges prompt injection remains an open problem; architecture reduces error rate and blast radius, not guarantees perfection.

Browser Is Not an Ordinary Tool

The browser brings external untrusted content directly into the agent's view. Muse uses an isolated Chromium instance with a dedicated broker. The browser sub-agent primarily reads the accessibility tree; it does not execute arbitrary page JavaScript nor use raw DOM or Chrome DevTools. Agent pauses when user takes over the browser or when security credentials are being filled into a form.

Purchases add another layer: the system generates a one-time payment credential for a specific merchant, amount, and time window; every checkout requires user confirmation. This sacrifices some automation smoothness but keeps the hardest-to-reverse side effect inside a deterministic approval UI.

Architecturally, browser capability is split into page reading, action invocation, credential input, and user takeover — each a narrow interface. The browser process and credential storage no longer expose full privileges to the agent.

Context, Memory, and Goals: Long Tasks Are Not Just Longer Chat History

Muse's product surfaces Goals, Memory, Activity Log, background tasks, and Artifacts — together providing a time dimension. A chat answers the current question; a multi-day goal must know why it exists, what's done, what's next, when to wake the user, and whether a background task's result writes state, continues, or notifies.

The author distinguishes five state categories:

Goal — target, constraints, phases.

Memory — preferences and reference material, user-viewable, editable, deletable, downloadable.

Activity Log — system's actual actions, auditable trace for user and ops.

Artifact — structured results: itineraries, checklists, files.

Context — only the working set the next model turn needs.

Persisted, retrievable, and in-current-context are three different states. Stuffing everything into context grows cost, latency, and injection surface; keeping only summaries risks losing raw evidence the next step needs.

Comparisons:

Codex experiments with notes and history queries — separating current working set from history.

OpenClaw stores readable long-term material in Markdown, uses keyword and vector indexes for retrieval.

Hermes (public discussion) focuses on recalling compressed content — how to recover original text after summarization loss.

Muse goes further: context recovery must serve a personal goal that continues after the app closes, not just a single development session.

Skills Describe How, Connectors Produce Actions

From public snapshots ( MuseAI-Skills, muse-skills), a Skill contains usage notes, I/O contracts, edge cases, and connector call patterns — essentially a retrievable operations manual. Skills ≠ permissions; they describe how to query calendar, organize email, generate shopping lists. Actual invocation still passes through runtime, connector workers, and authorization policies.

Connectors have two boundary layers:

Parameter boundary — which method, on which object, read or write.

Execution boundary — which process runs the code, which credentials it receives, which network destinations it can reach.

Meta places built-in connector logic in restricted workers outside the Runtime Cell. The in-Cell CLI parses parameters, opens files the caller already has permission to access, then passes typed parameters and file descriptors via Unix socket. Thus the model can request "read calendar" without ever obtaining the calendar service's long-lived key.

The author argues tool-call schemas should be treated as parameter validation, not security boundaries. Real boundaries must be enforced at caller identity, object scope, process permissions, network egress, and reversible side effects. Example: a "deploy service" Skill can specify build, deploy, rollback steps, but cannot end the task on "deployment done" alone — the Harness must obtain deployment receipts, health checks, and version queries. If the request was sent but the receipt lost, recovery must first query live state before deciding to retry. Skills fix the method; completion evidence comes from runtime and external systems.

Long-Running Task State: The Hard Part Is Resuming After a Pause

Because Muse runs in the background, the core challenge shifts from "can it start" to "can it continue after stopping." A task may be cancelled after reading email, or wait for approval before submitting a form; browser open, connector half-written, notification undelivered — the system must know each step's true state.

Saving the last chat message is insufficient. A robust state model at minimum distinguishes:

Session — user–agent interaction history.

Operation — how a background run starts, progresses, retries, ends.

Checkpoint — which actions committed, which can be safely replayed.

Delivery — whether results returned to the main task, notifications delivered.

Context — the working set the next model turn actually sees.

DSH's developer preview offers a valuable reference: it makes Session an append-only event fact layer; Agent Loop, tools, and permissions are assembled via Profile, Bundle, and event hooks. DSH sets checkpoints before model requests, before top-level tool side effects, and before the next step. On cold recovery, if a tool result is missing, it records an unknown result rather than guessing success or failure.

Event replayability ≠ external side effects are exactly-once. Sending email, placing orders, modifying calendars still require idempotency keys, receipt queries, and business-side reconciliation.

If a code agent runs overnight and the process dies in the window "request sent, result not persisted," the system must not treat blank as failure nor retry as success. Muse's public docs do not yet detail every connector's cancel/retry/cross-device recovery implementation; real-world data is needed.

Comparing Four Architectural Approaches

Revisiting the four reference systems on the same task chain:

Codex places complexity in developer-controlled workspace and Harness (threads, turns, tools, approvals, sandbox, context windowing) for auditable engineering execution. Notes/history experiments ease long-task continuation but remain bound to dev workflow.

OpenClaw pushes some complexity to user and local environment. Markdown memory is readable, editable, portable; memory_search balances simple files and retrieval indexes. Suits personal workflows but requires user to manage processes, credentials, network, and long-task runtime boundaries.

Hermes (public discussion) centers on post-compression recall — reminding us summaries aren't history; agents must re-find compressed content when needed. Full product architecture not public; used only as context-engineering side evidence.

DSH invests in runtime composability: Profile, Bundle, plugins, event streams give developers formal swap points for Agent Loop, tools, services. Dynamic assembly, version switching, persistent state increase verification cost. Suitable for Harness evolution research; not yet a mature consumer personal agent.

Muse absorbs complexity into the platform: Meta hosts the dedicated VM, provides browser, connectors, background tasks, credential proxy, deterministic approval. User-facing entry is lightweight. Trade-off: user must trust platform isolation and control plane; part of implementation stays opaque. For a personal agent, this trade-off makes "app closed, task continues" a product capability and forces security boundaries finer than developer tools.

What GitHub Repositories Prove (and Don't)

13 public repos provide strong corroborating evidence but are not Meta's full backend source nor stable online APIs: muse-cli — Gateway, Personal VM, Noise/WebSocket, Protobuf reverse-engineering clues for client–VM communication. agent-session-kit — observes hatch-*.json session caches in client. sovereign-projects, lumenbox — independent analysis of Runtime Cell, egress, permissions, security boundaries. MuseAI-Skills, muse-skills — Skills, manifests, connectors, Memory, Browser, partial Runtime snapshots. vibe-bar, openox, duo-updater — quota, web interface, client update/distribution side evidence. not-a-mused, native-agent, Homebrew Cask, codepick — local endpoints, client adapters, official distribution info; codepick also offers secondary architecture analysis.

These materials are suitable for cross-checking naming, file structure, and call direction. Responsibilities of Meta-internal services, online versions, and security policies should still defer to official design docs and safety articles. Treating a reverse-engineered field as a formal API or extrapolating static analysis into guaranteed online behavior crosses the evidence boundary.

Author's Assessment and Open Questions

Public materials sufficiently establish Muse's architectural direction: moving the agent from a per-request model call to a stateful, tooled, browser-equipped, permissioned, recoverable personal execution environment.

The author highlights six boundaries this design simultaneously holds:

Model output, authorization decision, and action result recorded separately.

Workspace and security services run in separate domains.

Agent can use capabilities but never obtains long-lived credentials.

Processes that read private data face stricter egress checks.

Browser content, page actions, credential input, and user takeover each have distinct interfaces.

Persistent goals, activity logs, checkpoints, and current context each carry distinct responsibilities.

These boundaries convert more model capabilities into controllable system behaviors and confine error impact.

Equally important are questions not yet answered by public materials:

How are external side effects reconciled after task cancellation?

Can connector retries achieve business-level idempotency?

Who owns final state during cross-device recovery?

How are notification delivery and result consumption linked?

When can Confidential VM key and audit boundaries be externally verified?

I will judge Muse's maturity against these questions. Once personal agents enter daily use, the hardest part isn't completing the first step — it's whether, halfway through, the system can still accurately say what it did, why it did it, and who the next step will affect.

References

Meta: How We Designed Muse (https://introducing.muse.ai/)

Meta: How We Built Safety Into Muse (https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse)

Meta: Muse Spark 1.3 (https://ai.meta.com/blog/muse-spark-1-3/)

Andrej Karpathy: Context engineering (https://x.com/karpathy/status/1937902205765607626)

Simon Willison: Context engineering (https://simonwillison.net/2025/Jun/27/context-engineering/)

Simon Willison: The lethal trifecta for AI agents (https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)

OpenAI Engineering: Unrolling the Codex agent loop (https://openai.com/index/unrolling-the-codex-agent-loop/)

OpenAI Engineering: Unlocking the Codex harness (https://openai.com/index/unlocking-the-codex-harness/)

OpenClaw: Memory overview (https://docs.openclaw.ai/concepts/memory)

Teknium: Hermes compaction recall discussion (https://x.com/Teknium/status/2094022539534389506)

DeepSeek Harness official repo (https://github.com/deepseek-ai/deepseek-harness)

Cordis official repo (https://github.com/cordiverse/cordis)

win4r/MuseAI-Skills (https://github.com/win4r/MuseAI-Skills)

nikships/muse-cli (https://github.com/nikships/muse-cli)

toxicwind/sovereign-projects (https://github.com/toxicwind/sovereign-projects)

fakechris/lumenbox (https://github.com/fakechris/lumenbox)

oldwinter/muse-skills (https://github.com/oldwinter/muse-skills)

AstroQore/agent-session-kit (https://github.com/AstroQore/agent-session-kit)

AstroQore/vibe-bar (https://github.com/AstroQore/vibe-bar)

ziyzhu/openox (https://github.com/ziyzhu/openox)

jizhi0v0/duo-updater (https://github.com/jizhi0v0/duo-updater)

pwardle/not-a-mused (https://github.com/pwardle/not-a-mused)

embwl0x/native-agent (https://github.com/embwl0x/native-agent)

Homebrew/homebrew-cask (https://github.com/Homebrew/homebrew-cask)

WhiteWorld/codepick (https://github.com/WhiteWorld/codepick)