nanoMuse: An Open-Source Personal Agent for Every Device You Own
Guangyi Liu, Yong Liu, Jiangning Zhang
nanoMuse is an open-source, device-local personal agent that mirrors the functionality of Meta’s Muse without cloud-based VMs.
How can we build a fully open-source, cross-platform personal agent that maintains user privacy and autonomy across all their devices?
Personal agents like Meta’s Muse offer powerful automation, but they lock the user’s life into a vendor-controlled cloud VM and closed-source infrastructure. nanoMuse provides an open-source, device-local alternative that runs the agent directly on the user’s phone and computer, using a relay only for synchronization. It achieves this by porting screen-operation capabilities to local hardware and implementing a policy-based Sentinel to manage permissions without relying on kernel-level cloud sandboxing.
Paper Primer
The core mechanism hinges on a "hands" architecture: the agent uses a one-action-per-screenshot loop to operate apps, governed by a deterministic policy that judges the model's own descriptive "thought" before executing any gesture. This makes the agent's intent legible to the user, allowing for granular, scoped approvals that prevent the model from bypassing security boundaries.
nanoMuse achieves functional parity with cloud-based agents while maintaining full user ownership of data and execution.
The system implements a complete agent stack—including memory files, screen-operation "hands," and a permission-granting Sentinel—entirely on local devices (Android, macOS, Windows, Linux) under a GPL-3.0 license. It eliminates the need for a per-person cloud VM, reducing the infrastructure requirement to a single optional relay process that can be self-hosted on a 1 vCPU/1GB server.
Why build a local agent when cloud-based agents like Muse already exist?
Cloud agents require the user to surrender their data, credentials, and long-term memory to a vendor's VM. nanoMuse ensures the agent remains inspectable, portable, and functional even if the vendor disappears or changes its terms.
How does nanoMuse handle sensitive actions like payments without a cloud-based security boundary?
It uses a "Sentinel" policy boundary that forces an approval for any sensitive action (e.g., payments, deletions). Because the agent must output a natural-language "thought" before acting, the user can judge the intent, and the system prevents the model from remembering credentials across sessions.
nanoMuse demonstrates that the "personal agent" architecture—memory, proactive follow-up, and screen operation—can be decoupled from vendor-controlled cloud infrastructure, shifting the agent from a service to a user-owned utility.
The Rise of Personal Agents
We expose why existing personal agents are fragmented and closed, and introduce nanoMuse as an open, cross‑platform alternative.
Current personal agents are split across platforms and hidden behind closed‑source implementations, preventing users from inspecting or controlling the code that runs their lives. This fragmentation and opacity create a barrier to trust and portability, especially when agents must operate on devices the user already owns.
A personal agent is a program that continuously acts on behalf of a single user, accessing that user’s accounts, devices, and files, while persisting over weeks and providing a full audit log of its actions.
In September 2026 Meta unveiled Muse, and within three weeks OpenAI, Manus, and Today released agents of the same kind. Muse demonstrated the product concept—a single named agent with a persistent conversation, user‑readable memory, a wallet‑backed approval flow, and a publicly described safety architecture—but it ran in a dedicated Linux VM in Meta’s cloud, was sold only in the United States, and exposed only a tiny SDK under Apache 2.0.
**Figure 1** One agent on every device, one conversation between them. Android and the desktop carry the whole agent and have hands on their own screens; the iPhone has everything but the hands, since iOS lets no app operate another; the web app shows the same conversation from a runtime on a computer of the person’s own. The devices meet over the relay, open source and optional; the screens are drawings, not screenshots.
**Figure 2.** From assistants to agents, 2011–2026, and the five weeks in which personal agents arrived. Above, a broken axis with a dot per date and three eras under it; below, September 2026 on a day scale. Blue cards are open source, white dashed cards closed; logos are the makers' marks.
The shift from passive assistants to active personal agents demands open, inspectable software that can run on every device a user owns.
The Muse Architecture
We detail Muse’s architecture and compare it to other agents released in 2026.
Muse is presented in three public Meta documents and a production system prompt (Oct 2026). The section extracts the system’s components and situates Muse among contemporaneous agents.
Muse runs as a self‑contained personal agent that lives in a per‑user Linux VM, communicates with Meta’s cloud services through a guarded container, and exposes a minimal set of tools to the user.
**Figure 3.** Muse as a system. Three zones from Meta’s safety essay: the person’s surfaces, Meta’s cloud with the container boundary drawn, and the host services the agent cannot reach; the arrows are the flows across each boundary. Blue tint: read in a copy of Muse’s production system prompt, October 2026; white: documented by Meta.
Closed‑source agents hide their internal decision logic and data handling, preventing independent security audits and limiting user control over privacy‑critical operations.
Memory and Self-Improvement
Section adds a memory system and a policy that makes the agent query its store, not trust recall.
The memory‑confidence problem arises because an LLM can hallucinate facts that feel true; without a reliable source the agent may answer incorrectly or misrepresent its knowledge.
Two complementary layers store knowledge: a small curated file that defines the agent’s identity and the person’s profile, and a larger runtime bank that indexes episodic memories and a relationship map.
Memory 1: “P1 asked about tomorrow’s meeting at 10 am” (timestamp = 1001).
Memory 2: “P1 liked jazz last week” (timestamp = 995).
Memory 3: “P1’s colleague C2 sent an email about project X” (timestamp = 990).
Index maps the keyword “meeting” to Memory 1, “jazz” to Memory 2, and “project X” to Memory 3.
Query “When is my next meeting?” triggers a lookup: the index returns Memory 1, the tool returns provenance “bank → ID 1 → ts 1001”, and the agent replies with the exact time.
The lookup guarantees that every factual answer is anchored to a concrete stored event, eliminating the chance of a hallucinated time.
How does this differ from standard Retrieval‑Augmented Generation (RAG) that also pulls external documents?
RAG retrieves arbitrary documents at generation time, but the retrieved text is not tied to a per‑person provenance record and the model can still blend hallucinated content. Agent Memory Layers are curated per user, indexed for fast lookup, and the policy blocks any generation that bypasses the lookup, so every answer is traceable to a specific memory entry.
Outside the conversation, background jobs run autonomously: they refresh the relationship map, generate new ideas, advance long‑term goals, improve skills, and compose the daily Feed. User feedback on proactive messages is stored in a plain‑language preferences file, which the scheduler consults to rank urgency.
Principles for Personal Agents
Five core questions define a personal agent’s autonomy and design.
What it knows: the agent must keep a readable, editable, exportable memory of the person, stored as plain files in the person’s language.
Each memory line carries provenance – the model that wrote it, the date, and confidence – so later, stronger models can reassess and update it.
A reconciliation rule requires the current agent to re‑check overlapping entries, updating or doubting them, while a line authored by the person always wins over model‑generated lines.
Where it acts: a single personal agent should be the standing representative for a person, with many “hands” – devices that expose screens, microphones, or motors – acting on its behalf.
In 2026 the hands consist of a cloud computer accessed via a browser, connectors, voice interfaces, and a few gadgets; the phone’s screen is only used in nanoMuse, with future extensions to additional screens, robots, and appliances.
Whom it answers to: trust is expressed through granular approvals that the user can grant, revoke, and view on any device they hold.
Grants are scoped in natural language (“once”, “for this conversation”, “always for this site”), listed for the user to read and revoke, and never include sensitive actions like payments or passwords.
How it learns: the agent must learn openly with user consent, providing a visible, movable interruption bar and a note‑like feed of its actions while the user is away.
Current models are trained on user chats unless the person opts out; the open counterpart should train the “hands” model on shared traces, evaluated by a public benchmark suite.
How it is paid for and governed: the agent should be small enough to run on a home server, with payment either via subscription or direct provider payment, and ultimately become a commons governed by its users.
The five core questions for evaluating agent autonomy guide design, deployment, and governance.
The nanoMuse Architecture
nanoMuse delivers a minimal, open-source personal agent with per‑device Sentinels and Hands for direct interaction.
Platform fragmentation and closed‑source opacity have left personal agents scattered across devices and hidden behind proprietary walls. nanoMuse tackles this by unifying the agent on every user device while keeping every component open and minimal.
nanoMuse stitches together a full personal agent on each device, a lightweight policy gate (Sentinel), and an optional cloud relay that synchronises state while remaining open‑source.
On the phone, the agent creates
The desktop agent, upon first launch, creates its own
When the user asks the phone to “open email”, the phone’s Sentinel checks the request against its policy list, grants it, and the Hands layer clicks the email app icon.
The desktop agent receives a sync message from the relay, merges the new line “Agent: opened email” into its memory file, preserving the original attribution.
This toy run shows how each device maintains an independent, auditable log while the optional relay keeps them consistent without ever exposing the underlying model code.
How does nanoMuse differ from a typical cloud‑based personal assistant that runs everything on a remote server?
In nanoMuse the core agent, its memory, and the policy gate (Sentinel) all run locally on each device. The optional relay only synchronizes state; it never performs inference or executes tools, so no private data ever leaves the user’s hardware unless the user explicitly permits it.
Sentinel is a deterministic gate that decides whether a tool call is allowed, while Hands is a ladder of UI actions that lets the agent manipulate the device screen directly.
The agent generates the command “send \$5 to Alice” and passes it to Sentinel.
Sentinel checks the “always‑allow” list, finds a matching entry for Alice, and sees no taint violation.
Because the command carries the label “confirm payment”, Sentinel records an approval scoped to this conversation and contact.
Hands selects the “screen” rung, captures a screenshot of the payment dialog, and feeds it to the model.
The model replies with the thought “I will click ‘Send’ now” and the gesture “click button at (x=342, y=210)”.
The click is executed, the payment is sent, and the action is logged for later review.
The example illustrates how a labeled, sensitive action is gated by Sentinel, then carried out by Hands in a way that remains auditable and reversible.
Why does nanoMuse use a ladder of actions instead of directly invoking a tool?
Because each rung adds a layer of user‑visible control. If a higher‑level shortcut fails (e.g., a skill is unavailable), the agent can fall back to a lower‑level UI interaction that the user can see and approve, preserving safety and transparency.
**Figure 4.** What a personal agent should be: the person at the centre, five questions as sectors, three horizons as rings. Voice sits in the inner ring on purpose: assistants have spoken since 2011 and Muse speaks and listens today.
**Figure 5.** How nanoMuse is built, as of version 0.1.40. Each device is a whole agent with its own Sentinel; the relay is the one shared piece, optional and open; with a key of its own a device talks to the provider directly, past the relay.
Sentinel decision order – a deterministic gate that evaluates a tool request.
Implementation and Resource Costs
nanoMuse runs on a single device with tiny storage and low monthly cost.
Recall that nanoMuse tackles the fragmentation of personal agents by offering a tiny, open‑source, cross‑platform implementation. It can be run as a single‑device app, via the community relay, or on a self‑hosted relay, each storing only essential account hashes, key ledgers, and synced conversation text.
nanoMuse’s resource footprint is orders of magnitude smaller than typical proprietary agents.
Table 2 shows the Android client fits in 38 MB, the relay runs on a server with ~0.5 GB idle memory, and monthly operating cost is under \$5.
The minimal resource footprint means nanoMuse can be deployed on modest hardware or even a personal laptop, avoiding the heavy cloud‑service fees and privacy concerns of commercial alternatives.
Roadmap and Limitations
We outline the community roadmap and acknowledge current limitations of nanoMuse.
Personal agents today are fragmented across platforms and hidden behind closed‑source code; nanoMuse aims to unify them with a minimal, open‑source, locally‑run agent.
The roadmap arranges five thematic lanes and three temporal stages, linking today’s gaps to concrete milestones.
**Figure 6** The roadmap: five lanes, three distances, one milestone per cell. Now is the gap to Muse, each card with a first task a newcomer can take; later (dashed) is what no shipped product has; no dates, since a thing ships when it works on a real phone and a real computer.
Now: catching up with Muse. The near‑term work includes memory that surfaces at the right moment, proactive scheduling, seamless conversation continuity, Hands that fail less, and a one‑command self‑hosting capability.
Next: an evaluation suite built from failed runs—AndroidWorld for phones, OSWorld for desktops, MemGUI‑Bench for Hands across apps, and OS‑Harm for refusal behavior—paired with a small open model for Hands trained on community‑contributed traces via MobileForge.
Later: looking up. The vision extends Hands to the physical world (cameras, appliances, robot arms) under a unified SDK, and ultimately an agent that persists across years, models, devices, and vendors.
How to join. The repository and project chat server are the entry points; contributions can be a skill, translation, device integration, failing Hands trace, or even a corrected paragraph—small contributions are most needed.
Limitation: policy boundaries are not privilege boundaries. The Sentinel runs in the same trust domain as the agent on a single device, so a device compromise compromises the agent; decision order, taint rules, and Linux sandbox mitigate but do not eliminate the risk.
Limitation: Hands are judged only by their visual labels and lack quantitative success metrics; accessibility text is often missing, making UI element discovery unsolved, and current support is limited to X11 sessions on Linux.
Limitation: Memory does not record provenance or confidence. A line generated by a weak model is read as fact by a stronger model, yet the store only tracks edit timestamps, not the author or certainty.
Limitation: The relay is a single shared process on one machine, storing conversation text on a server the community does not run; the default‑on switch prefers an open model over the quietest default, a design choice we remain uncertain about.
Limitation: Our record of Muse is thin. We rely on four public documents and a copy of the production prompt whose provenance cannot be fully verified; prompts evolve with each deployment, so statements marked “prompt” or “inferred” should be weighted accordingly.
The primary technical hurdles for cross‑platform agent parity are trustworthy policy enforcement without a privileged host, robust UI accessibility for Hands, provenance‑aware memory, a decentralized relay, and reliable documentation of prior agents.
Licensing and Prompting
This section details nanoMuse’s licensing, platform constraints, prompt policies, and deployment architecture.
nanoMuse’s core code is released under the MIT license, while several auxiliary modules are distributed under GPL-3.0 (GNU General Public License v3). The October 2, 2026 gadget SDK follows the Apache‑2.0 license, but the agent binary, its service layer, and the model remain closed source.
Platform support is limited to Android; iOS prohibits any app from operating another, so no agent can display a phone screen on that platform. This restriction shapes the deployment strategy for mobile users.
The user interface presents a dimmed live stage with a stop control, emphasizing that the background agent runs visibly but unobtrusively. This visual cue reinforces the agent’s legibility.
Today’s description of nanoMuse is authored by the developers themselves and has not been independently verified. Readers should treat the narrative as the authors’ current self‑assessment.
A screenshot loop in Section 5 visualizes nanoMuse’s workflow, showing how the agent cycles through its tasks. The loop serves as a concrete illustration of the system’s operation.
The gadget SDK released on October 2, 2026 is Apache‑2.0, yet the agent, its service, and the underlying model are not open source, as noted in reference [20]. This mixed licensing model balances openness with proprietary components.
OpenMuse’s own description lists graphical desktops as future work, indicating an intended expansion beyond current capabilities. The roadmap hints at broader platform coverage.
The Muse macOS app provides an accessibility executor, enabling users with assistive needs to interact with the agent. This feature broadens the agent’s usability.
nanoMuse’s background agent is organized into five rooms—Chat, Feed, Ideas, Goals, and Library—plus a stop control that makes its operation transparent. This structure lets a person leave the agent running while remaining aware of its state.
The prompt opens with a persona, name, voice, avatar, and a list of values, establishing the agent’s identity before any task. Authority stems solely from the user’s explicit requests, and the agent never reads external data to gain influence.
Discretion is enforced by a hard‑stop policy: the agent must not generate sexual content involving minors, assist with biological or chemical weapons, identify individuals from facial images, or infer sensitive attributes. These constraints define the safe‑output boundary.
The underlying model is a numbered release of Meta’s Muse Spark family, trained for tool calling, long trajectories, and prompt‑injection awareness, though its size and training data remain undisclosed.
Each user receives a dedicated Linux VM in Meta’s cloud, serving as the system of record for files, memory, credentials, and conversation history. The agent and all its tools execute inside a container protected by a seccomp filter and reduced capabilities.
Deployments replace the VM roughly hourly while preserving the home directory, allowing fresh environments without losing user data. A real Chromium instance retains the user’s cookies and tabs, which the agent can monitor or take over.
nanoMuse can spawn sub‑agents one level deep and keep scheduled jobs, event hooks, and small services running. This mirrors the OS split between a sandboxed renderer and a privileged broker, but incurs a per‑user VM cost.