Inside a Persistent AI Agent: Reading MUSE Through Its Harness

A personal AI agent needs continuity: recovering a task, remembering a correction, using a connected service and returning to work later. A model call alone does not provide these capabilities. A surrounding execution system—the harness—selects context, runs tools and retains the state needed for another turn.

Scope and evidence. This unofficial study combines Meta’s public information, a supplied MUSE interview memo, and research and follow-up interviews that Dots, an AI assistant, conducted with MUSE. MUSE answered the documented questions about its own operation; receiving an answer is not independent verification or publication permission. Dots also operated and observed the limited Spaces experiment in §5 at the user’s request. Internal descriptions remain MUSE’s account unless a cited official source or identified UI observation supports the specific claim. Dates and roles appear in Sources and scope, with terms-review limits below; the private research archive is neither reproduced nor linked.

At a glance

The five sections follow the work from a model decision to retained state and a revisitable application. This map highlights what each layer contributes, with links to the mechanisms and evidence behind it.

The central distinction is between retaining information and bringing the right information back into an execution. The Spaces experiment provides a concrete, limited example of that continuity; the preceding sections explain the surrounding responsibilities.

1. Architecture and the execution loop

Meta’s Muse overview describes a persistent VM and browser, connected applications, background work and permission controls. MUSE’s interview account assigns the surrounding loop to a harness that assembles context, runs permitted tools and checks results. The model chooses a next step; the harness connects that choice to execution and retained state.

From a request to the next decision

In the reported loop, a request leads to context assembly, model selection of an action, tool execution and inspection of the returned result before the next decision. Delegation and JavaScript workflow execution are available in the account, without implying that every request follows a fixed graph or uses several agents. Tool selection and a successful operation are separate events.

Execution and retained resources

The execution environment, durable stores and model input have different roles. The reported PostgreSQL records organize conversations and runtime state; persistent files hold memory and work products; browser state and job definitions have their own lifetimes. The harness connects these resources to inference. A checkpoint and the records it references may both be needed to resume work; the interview supplies no transaction or recovery guarantee across them.

Following an execution

The memo also describes execution identifiers, parent–child agent relationships, tool records, token counts, job history and diagnostic logs. These provide a reported basis for tracing the loop, without establishing a user-facing trace viewer, complete audit coverage or tamper resistance.

2. Tools and connections to external services

MUSE describes two routes for supplying tool instructions: load a native function schema when needed, or read connector documentation and construct a CLI command. Skills guide both routes, while browser, Computer Use and private-network access reach different environments. These capabilities remain distinct from approval and service authorization.

Two routes from capability discovery to execution

A machine-readable function schema and a connector command are different ways to make a capability usable. The table separates those routes from the Skills that guide them, the context that informs them and the results returned afterward.

For example, the reported Gmail connector document covers connection, account choice, permission checks, reading, drafts, sending, organization and result reporting. It is operational guidance as well as syntax, rather than a full --help dump in every request. The Agent Skills specification puts YAML frontmatter in SKILL.md; MUSE instead reports separate skill.yaml metadata, including include_in_prompt. This difference prevents inferring conformance from similar names. The MCP architecture distinguishes hosts, clients and servers; a wrapper or -mcp suffix alone does not identify transport or deployment.

An executable catalog, not a function catalog

The reported /opt/hatch/bin/ inventory contains 112 executable names, not 112 model functions. The original classification and complete inventory in Appendix A are retained:

An installed name does not establish a connected account or current support, and a runtime helper is not necessarily model-callable. Complete per-command contracts were not supplied.

Cloud browser, paired Mac and private-network access

The cloud browser belongs to the execution environment and retains its own browser state. Computer Use is described as a paired Mac application that obtains UI state, performs a local UI action and returns another observation, using macOS accessibility and screen-recording permissions. Background interaction, excluded apps and the absence of an arbitrary local shell are reported constraints. Tailscale is a separate, optional runtime-proxy route to private TCP services, not an established transport for Computer Use. Outbound-only operation, destination approval and restrictions on UDP, incoming traffic and exit nodes describe this integration; they are not a definition of Tailscale itself.

Approval is not service authorization

Operation approval and service authorization are distinct. OAuth scopes can permit a service operation while leaving approval for particular content or an action unresolved; approval in the agent interface cannot supply a missing scope. MUSE reports a separate credential store and protected credential references. Meta describes permission and credential protections at product level, while these internal mechanisms remain interview claims rather than a credential-isolation audit.

3. State, memory and context

Saving information is different from including it in model input. In MUSE’s account, PostgreSQL records and persistent files retain state while the harness selects core context, relevant detail and compacted history for inference. Memory correction also requires updating dependent summaries and checking later retrieval; storage alone does not keep every derived view current.

PostgreSQL: structured conversation and runtime state

The five reported tables divide continuity into chat identity, session identity, ordered context, summarized history and restart state. The overview below shows those responsibilities before the column-level definitions in Appendix B.

The 53-column definitions in Appendix B preserve SQL types, constraints and reference distinctions. These are reported contents of a generated schema reference, not validated live DDL. Declared foreign keys enforce a different relationship from described logical or “soft” references; several targets lie outside the five-table excerpt. The chat/agent schema is not the Spaces application database.

Files: persistent home and replaceable system tools

The memo describes a persistent home containing USER.md for user information, IDENTITY.md and SOUL.md for agent attributes and tone, AGENTS.md and TOOLS.md for working conventions and environment notes, MEMORY.md for selected lasting facts, preferences and commitments, and PROACTIVE_PREFERENCES.md for unsolicited-contact preferences. User-created files and supplied system tools have different update lifetimes. These are reported conventions, not instructions to edit platform internals directly. The reported filesystem tree in Appendix C preserves the selected layout and role annotations supplied in MUSE’s answer.

The simplified layout below groups files by responsibility. The home directory holds user-specific state; /opt holds shared programs and definitions replaced on deployment, according to MUSE. It is a reading guide to the reported layout, not a newly captured filesystem listing.

~/                              User-specific persistent state
├── USER.md, MEMORY.md          User context and lasting memory
├── AGENTS.md, SOUL.md, …       Working conventions and agent identity
├── memory/                    Daily notes, people and derived memory
├── dreams/                    Reflections and alignment summaries
├── docs/                      Product documentation
└── workspace/                 Work products and task resources
    ├── your_files/, goals/    Deliverables and goal-specific work
    ├── custom-skills/         Learned procedures
    └── custom-connectors/     Added integrations

/opt/                           Replaceable system programs and definitions
├── hatch/bin/                 Connector, runtime and functional executables
├── hatch/connectors/          CONNECTOR.md guidance
└── muse/skills/                System SKILL.md procedures

Memory: source records, derived summaries and corrections

Daily notes retain events and changes; person/group pages organize relationships. Background processing produces derived memory and broader summaries, separately from the search index. A current summary expresses the latest understanding, while detailed records preserve how it changed. Correcting memory therefore requires identifying and correcting the source record, recording its replacement, refreshing dependent summaries and checking later retrieval. A scheduled task may also depend on the superseded information. MUSE describes propagation through background processing, but supplies no delay or consistency guarantee.

Context: compaction and selective retrieval

For long conversations, MUSE describes compaction: summarize older history while retaining recent material. Its accounts differ on the trigger, so no exact window, threshold or retained-tail size is adopted here. Compaction changes active conversation representation; it is separate from updating long-term memory or training weights. Lost detail can only be recovered when its source remains stored, accessible and findable.

Search serves several audiences: conversation/artifact search helps the user, memory retrieval supplies agent context, and external search/browser tools obtain outside information. Their coverage and freshness differ. Reported feedback, background reflection, procedure reviews and health checks can update operating context and workflows; they do not establish model-weight changes or measured benchmark gains.

4. Work that continues outside a conversation

MUSE distinguishes triggers that start a run, Goals that retain purpose and progress, and artifacts, Feed and Ideas that result from work. Cron and Hooks supply timing or state checks; a Goal is not itself a clock. This separation explains how work can continue beyond a chat without making every proposal an authorized action.

Triggers, retained goals and generated outputs

Background work is easier to understand when the mechanism that starts it is separated from the information it carries forward and what it produces. The table places the reported mechanisms in those roles, rather than treating them as interchangeable forms of automation.

A scheduled run can use a Goal’s saved progress and produce an artifact, reading material or a proposal. Those outputs do not themselves define the next trigger, and an Idea remains a proposal until the user selects an action.

Continuing work without confusing a proposal with an action

Saved progress supports a later run, while an artifact is a work product and a proposal is still a proposal. Editing a projected job file does not establish that the scheduler’s authoritative definition changed. Generation intervals, ranking, expiry and state names belong to the reported environment rather than a current public specification. Ownership, cancellation propagation and recovery behavior require separate tests.

5. Testing continuity through Spaces

Meta’s Spaces announcement describes personal features created and refined through chat, connected information, and notes or checkmarks retained on revisit; sharing was being explored. Dots used a synthetic notes app to observe reopening and heading-only rebuild retention. The implementation descriptions below remain MUSE’s reports, separate from the official experience; the SQLite/action path is specific to that prototype.

Application types, files and data

The announcement also describes arranging Spaces in the sidebar or main tabs, hiding them or making them appear at relevant times, and refreshing connected information in the background. MUSE’s account adds the application-level boundaries below: a build-time page or interactive app, its files, its actions and its separate data store.

MUSE describes an asynchronous builder with follow-up instructions, relayed questions and cancellation. Artifacts are reportedly hosted in the user’s environment and require online access; this does not identify a shared VM process or isolation boundary. Static HTML export is described for static artifacts, not fullstack apps. Appendix D retains file, database, snapshot and prototype inspection details.

Application lifecycle: builds are not user data

MUSE described the builder request as its authoritative input, along with a prebuilt tutorial artifact and its management executable. These are reported interface contracts.

Two lifecycle limits matter more than a generic claim of version history. Restoring a version reportedly restores files and the build, not application data, settings or schedules. Changing between static and fullstack types requires a new artifact, without automatic data inheritance. A restored screen therefore must not be assumed to represent restored data. Neither version restoration nor type conversion was tested.

Muse described no hosting-only stop operation: revoking a public snapshot is distinct from deleting the artifact. Deletion was described as irreversible, removing the application and its data, hosting, catalog entry, managed schedules and public share. The ordinary workspace-file trash period was said not to apply, and deletion during a running build was said to be rejected. These are consequential lifecycle claims from the interview, not operations performed or validated in this research.

Capabilities and background refresh

The reported capability manifest declares web-reading capability and the connector methods an app needs; the server validates those declarations against the shipped connector catalog, and undeclared connector use was described as disallowed. A read approval may be requested before a build. Muse distinguished an artifact-scoped, persistent read approval from write authorization checked at execution time. These statements describe claimed enforcement behavior. They are not an authorization audit, a guarantee about every connector, or evidence that a conversational permission automatically authorizes all future application activity.

Refresh triggers are reportedly declared at creation/edit time: a natural-language frequency is translated by the builder into a schedule. Background updates reportedly reuse the scheduling infrastructure described elsewhere in this article. A space_action job runs without a chat message; failures remain in its history, and the same scheduled invocation is not automatically replayed. A regular agent job can instead call an application's action and report through chat; Muse also described call identifiers for background results written through actions. Schedule changes and suspension are managed through the scheduling interface, while deleting the application removes its managed schedules. Muse reported no artifact cron jobs in the inspected account, so timing, failure handling and replay behavior were not exercised.

Prototype operations and observed results

At the user’s request, Dots asked MUSE to build a private fullstack lab-notes app using synthetic data only. MUSE built the app; Dots used Computer Use to operate its UI and observe the following results in the native Muse application:

Dots’s observations demonstrate reopening persistence and data retention through one presentation-only rebuild in one app. It is not a restart-recovery or database-migration test; a browser reload was not separately tested. No external connector, share, deletion or scheduled job was exercised. The private app and synthetic record were retained; its URL and host are omitted.

The prototype’s reported action and database path

MUSE’s builder and separate inspection reported TypeScript 5.6.3, React/React DOM 19.2.5, TanStack Query 5.100.10, Tailwind CSS 4.1.13, Zod 4.4.3, Drizzle 0.45.2 and SQLite app.db for this prototype. SQLite was attributed to schema declarations, migration dialect and table SQL, not inferred from the filename. Bun 1.3.10 was reported for build/install, not established as the production server. These reports were not independent source or database inspection.

The reported request path connects App.tsx query/mutation calls through @hatch/space-sdk’s action client and POST ./actions to defineAction, host-injected ctx.db, Drizzle and SQLite. Its actions were listNotes, addNote and toggleNote. The database was described as outside .space-build, associated with the slug. MUSE said only the heading in App.tsx changed, with the same action-level record ID, values and creation time afterward. The visible retention is consistent with this separation of build output and application data; it does not verify the placement or platform-wide contract.

The useful distinction is between changing an application, refreshing connected information and saving user actions within it. The initial two migrations were reported as applied during initial creation, not a demonstrated migration of deployed user data. Detailed files, versions, metadata and the four-column notes table remain in the appendix.

Conclusion

MUSE makes the harness a useful unit of analysis: continuity depends on state storage, selective memory, executable tools and the ability to resume work with relevant context. Conversation identity, ordered history, compaction ranges, checkpoints, working files and scheduled instructions serve different responsibilities. Their presence explains an architecture for continuing work without making persistence synonymous with sending everything to the model.

Spaces makes that continuity tangible as a personal application. Dots observed one synthetic note survive reopening and a heading-only rebuild, while MUSE’s reports supplied a specific account of actions and application data. Together, the product description, interview and narrow experiment show why an agent is more than answer generation: the surrounding harness connects retained state and selected context to useful execution across time.

Appendix A. Complete executable catalog

Each row groups one reported class, with every executable name preserved as a comma-separated entry. Classification is inherited from the memo; per-command contracts and present-day availability remain unverified. The descriptive Google note attached to hatch_gws_cli in the source is retained below the table. This is a name inventory, not a tested support matrix.

The source annotates hatch_gws_cli as “Gmail / Google-related.” Totals: 66 + 19 + 27 = 112 distinct names. Entries such as gumroad-mcp retain their original connector classification; a name ending in -mcp is not by itself a verified statement about deployment or transport.

The Gmail connector document was reported as 228 lines in that environment. The interview’s illustrative syntax was:

hatch_gws_cli gmail +triage --query '...' --format json

This is syntax documentation, not mailbox activity or a current support contract.

Appendix B. Reported persistence schema

The five tables and all 53 columns below preserve the interview’s SQL types, order and constraints. “Nullable” follows omission of NOT NULL; an unlisted constraint is unknown. The generated reference was reportedly inspected on November 3, 2026, 22:59 JST. No live records were queried.

Declared foreign keys and logical references are listed separately below. No cardinality, cascade or extra external-table columns are inferred.

chat.chats — chat identity and lifecycle

This table records a chat’s identity, lifecycle and presentation metadata, alongside fields describing its source. The column list keeps those source fields distinct from the session relationship discussed below.

Primary key: chats_pkey(chat_id). No declared foreign key was reported. source_session_id was described as a soft reference to agent.sessions.session_id.

The SQL type of chat_id is text, not uuid. The interview separately describes its value as a UUID shared with the root agent's session ID. That description of value format does not change the SQL type, and actual values were not inspected.

agent.sessions — session identity and origin

A session record retains its identifier, originating request and lifecycle timestamps. Its reported foreign key links the originating request to a runtime table outside this excerpt.

Primary key: sessions_pkey(session_id). Declared foreign key: sessions_root_request_id_fkey, from root_request_id to runtime.requests.request_id. The table retains the session identity, originating request and archive timestamp.

agent.context_items — ordered context items

Context items combine an ordered position with content and optional references to messages or tool activity. The fields below distinguish that ordering from the payload and the records to which an item refers.

Primary key: context_items_pkey(context_item_id). Unique constraint: context_items_agent_id_seq_key(agent_id, seq), with the columns in that order.

Reported declared foreign keys:

• message_id → runtime.messages.message_id
• tool_call_id → runtime.tool_calls.tool_call_id
• tool_output_id → runtime.tool_outputs.tool_output_id

Described soft references, not declared foreign keys:

• agent_id → agent.agents.agent_id
• call_id → runtime.workflow_agent_calls.call_id

This structure separates an item's position in context from its role, content and links to messages or tool activity. The names of the three foreign-key constraints, enum members and JSON-string structure were not supplied.

agent.compactions — summarized history ranges

A compaction record associates a summary with a history range and an optional context checkpoint. Keeping the range boundaries alongside the text makes clear which part of history the summary is intended to replace.

Primary key: compactions_pkey(compaction_id). Declared foreign key: compactions_checkpoint_context_item_id_fkey, from checkpoint_context_item_id to agent.context_items.context_item_id. agent_id was described as a soft reference to agent.agents.agent_id.

The table associates a summary with a replaced history range. The reported range columns are integer, whereas agent.context_items.seq is bigint; their types are not normalized here. This definition does not establish how recovery reconciles partially written summaries and context items.

agent.runtime_restart_checkpoints — saved restart state

The restart-checkpoint table records mode, payload and recovery-related fields under an agent identifier. Its structure describes saved state; the limits of what can be inferred about restoration follow the definition.

Primary key: runtime_restart_checkpoints_pkey(agent_id). No declared foreign key was reported. recovery_owner_id was described as a soft reference to agent.recovery_owners.owner_id.

The reported primary key implies at most one row per agent in this table. That is an interpretation of the key definition, not a guarantee about checkpoint freshness, retention or successful restoration. Columns ending in _json were reported as SQL text, not JSON or JSONB.

Relationship and verification boundaries

The five tables describe different aspects of continuity: chat identity, session identity, ordered context, summarized ranges and restart state. They do not constitute a complete schema. Several declared foreign keys point to tables outside this five-table excerpt; soft references must not be treated as database-enforced integrity.

Only the reported primary-key and unique-constraint information is available for indexes. Additional indexes, index methods, partial conditions, foreign-key deletion/update actions and deferrability were not supplied. The units and epoch of bigint time columns, sequence names, enum values, JSON-string layouts and additional checks remain unknown. The interview also describes restricted projections for reading records, but no row query or enforcement test was performed here.

Appendix C. Reported filesystem tree

The following reproduces the selected filesystem view supplied in MUSE’s original answer, with its role annotations translated into English. It is MUSE’s account of the major parts, not a captured tree invocation or raw shell output. Large runtime-internal directories such as agents/ were omitted in that answer; the ellipsis and combined file-name line below retain its shorthand. Dates, empty-file status, missing person pages and context-inclusion notes describe the answer at that time, not the current environment.

~ (home: described as retained even when the VM is replaced)
├── AGENTS.md                  Operating manual
├── SOUL.md                    Personality and tone
├── IDENTITY.md                Agent profile
├── USER.md                    User profile
├── MEMORY.md                  Long-term memory summary (always included)
├── PROACTIVE_PREFERENCES.md    Proactive-contact preferences
├── TOOLS.md                   Environment notes (empty at the time)
├── HEARTBEAT.md
├── memory/
│   ├── 2026-10-23.md … 2026-11-02.md   Daily notes (audit trail)
│   ├── bank/                  Automatically generated derived memory
│   │   ├── world.md / experience.md / opinions.md / reflections.md
│   ├── people/INDEX.md        Relationship map (no person pages yet)
│   ├── groups/INDEX.md
│   └── shopping/PROFILE.md
├── dreams/
│   ├── 2026-10-23.md          Nightly-batch reflection
│   └── alignment/
│       ├── derived/ALIGNMENT_SYNTHESIS.md   Integrated user understanding (always included)
│       └── repair/REPAIR_THREADS.yaml
├── docs/                      Product documentation (muse.md, memory.md, etc.)
├── workspace/                 Working area
│   ├── your_files/            User-visible work products
│   ├── goals/                 Per-goal folders
│   ├── custom-skills/         Learned skills
│   ├── custom-connectors/     Added connectors
│   ├── email/                 Saved email copies
│   ├── system/system_prompt.md
│   └── …
└── .ssh/                      SSH keys (confidential contents)

/opt (system: described as read-only and replaced on each deployment)
├── hatch/
│   ├── bin/                   CLI executables (112 reported names; see Appendix A)
│   └── connectors/            CONNECTOR.md files
└── muse/
    ├── skills/                System Skills (SKILL.md files)
    └── assets/

The answer distinguishes user-specific files retained under the home directory from shared programs and definitions replaced under /opt. Those are reported update and retention roles, not an independently tested VM-replacement or recovery guarantee. The bin/ annotation uses the complete inventory’s classification: 112 executable names across connectors, runtime components and functional tools, not 112 model functions or 112 connectors alone. The tree lists paths and purposes only; it does not reproduce file contents, messages, keys or credentials. Structured conversation records remain a separate store, described in Appendix B.

Appendix D. Spaces contracts and experiment details

The following preserves MUSE’s reported contracts and application-specific inspection details; these were not independently audited. The direct operation results are in §5.

Application types and execution

According to Muse's summary of its product-side documentation and tool contracts, Space is the newer name for a web artifact, with two types:

Muse said artifacts and their data live in the user's Muse environment and are served from there, rather than being installed on the user's device; pages were described as requiring online access. This provides a reported connection to the personal environment, not an independently verified hosting topology or proof that every application shares a particular VM process, network namespace or trust boundary. Muse could not identify the language/runtime, routing mechanism, or whether execution is long-lived or request-driven.

Files and the application database

The reported identifier is a lowercase kebab-case slug. Muse described workspace/ts-spaces as the current application area and workspace/spaces as an older path appearing in its tool documentation. It separately described file artifacts under workspace/your_files/<slug>/ or a goal's files/ area, with a .src source marker for builder-created directories. These are reported environment conventions, not public stable paths or instructions to bypass application tooling. Because the catalog was empty, the newer path's creation timing could not be established.

For an interactive app, Muse described an application-specific database named app.db, retained across restarts and updates. The engine and concrete schema format were not disclosed: the name app.db is not evidence of SQLite. The builder defines each application's data model, and model changes are requested through its editing interface. The account's existing five chat/agent tables above are not a schema for this database.

Muse also described a deliberate access boundary: the ordinary conversational agent does not directly inspect Space source, logs or database contents. It uses dedicated inspection/editing interfaces and the application's declared actions. Static pages can reportedly be exported as self-contained HTML under the file-artifact area; fullstack apps are not covered by that export contract. The initial interview performed no export or direct database read; the later experiment edited the application through Muse.

Static snapshots are not proof of a public sharing feature

Muse's tool-contract account included a static public snapshot operation requiring approval for each share, with later edits excluded until another share, an unshare operation, and no fullstack publication. It said application database records are not included in that snapshot. This must not be read as confirmation that Spaces sharing is publicly released. Meta's announcement says sharing is being explored. The interview describes a narrower, reported artifact operation; no snapshot was created, published or revoked, and its availability or behavior for Spaces was not independently established.

Stack reported from the generated application

The builder and follow-up inspection identified the following versions in this one generated app, not a required stack for all Spaces:

This narrows the earlier database uncertainty for the tested app: SQLite now has multiple reported supporting artifacts. It does not justify retroactively labelling every Space database SQLite or treating an app.db filename alone as proof.

Files, typed actions and the database boundary

Muse reported a client entry at client/dist/index.html, client implementation in App.tsx and client/src/api.ts, action definitions in server/src/actions.ts, and built server actions at dist/actions.js. Its account of the request path was:

App.tsx: useQuery / useMutation
  → client/src/api.ts: @hatch/space-sdk createActionClient
  → POST ./actions with { action, args }
  → server/src/actions.ts: defineAction
  → host-injected ctx.db
  → Drizzle
  → SQLite app.db

The declared operations were listNotes, addNote and toggleNote. According to the inspection, application code contained neither a direct database-file open nor a connection string: the host supplied ctx.db. The database was described as outside the .space-build artifacts and associated with the application's slug. This is a concrete reported separation of generated build output from application data, consistent with the successful heading-only rebuild. It is not an independent audit of file placement or isolation.

The reported application table was small enough to show completely:

Muse's inspection reported a two-entry __drizzle_migrations record: the first creation migration generated an entries table, and the second replaced it with notes, with both applied during the initial build. This is not a demonstrated migration of user data between deployed schema versions. The later v2 edit deliberately left the schema and migrations alone. The reported configuration also had an empty managedCronJobs list, matching the experiment's no-scheduling scope.

Further verification

Useful next tests are restart recovery without duplicate effects, correction propagation into later retrieval and scheduled work, denied writes, cancellation, connector revocation, conflicting refreshes and schema-changing migrations. Process launch, routing, authentication, cross-app isolation and egress enforcement were not independently inspected.

Interview premise and terms

The interview method relies on MUSE answering questions in chat about its own operation. Meta’s memory-controls guidance invites direct questions about remembered information and viewing files such as MEMORY.md. Its security explainer presents architectural detail to help users assess trust. The data-policy section describes access to files stored for the user in their VM, including memory, using the phrase “inspect, edit and download these files freely.” These explain user controls and Meta’s transparency aim. No official explanation was identified for why MUSE gave these particular internal answers, or a promise to answer arbitrary internal questions.

An answer, its accuracy, permission to publish it and legal compliance are separate matters. The Muse Supplemental Terms, updated September 8, 2026, preserve existing user-content rights (§2(a)) and reserve rights in Muse (§3). They restrict concealing AI/automation (§4(l,p)), unauthorized access and rights violations (§4(r,s)), reverse engineering including outputs (§4(t), with an applicable-law exception), and overriding safeguards (§4(v)); §§7 and 11 address user oversight/responsibility and accuracy. The incorporated Meta Terms also restrict automated access/collection without prior permission (§3.2) and reverse engineering subject to stated exceptions (§3.4). These provisions are material review points, not publication clearance. The displayed terms, Meta AI Terms and Muse Privacy Policy were read in the official browser pages on November 12, 2026, after text-only retrieval returned login prompts. Exact regional/account applicability and all additional policies were not established. Connector-provider and model-API terms were not substituted. This study makes no finding that the interviews, automated UI operation or publication are lawful or contractually permitted.

Sources and scope

• Spaces update: Meta, Introducing Spaces: A New Way to Customize Your Muse App, published November 6, 2026; reviewed November 10, 2026. This newer official source supports the product-level Spaces section, not the older interview's internal implementation claims. A direct Spaces-specific follow-up was subsequently obtained; its distinct scope is documented below.

• Spaces experiment: private synthetic-data application, November 11, 2026, approximately 03:40–03:51 JST (November 10, 18:40–18:51 UTC). Dots requested the build from MUSE, operated the UI and observed note use, reopening and the v2 heading with retained data. Source, configuration, database and action-level details are Muse builder/inspection reports, not independently read artifacts. No private application URL or host is included.

• Spaces interview: follow-up questions posed by Dots to Muse on November 10, 2026, approximately 16:53–16:55 UTC (November 11, 01:53–01:55 JST), read by Dots in its native application. Dots observed the displayed answer; claimed documentation and environment checks were not independently repeated. The catalog was empty at the initial interview; the separately documented synthetic-app experiment followed later. This article paraphrases technical claims, not private instruction text or raw internal documents.

• Public product context: Meta's Muse overview, checked November 4, 2026. Used for product identity and broad advertised capabilities only.

• Interview material and roles: the user supplied the initial MUSE interview memo; its original interviewer is not established by the available conversation record. Dots conducted the documented November 3 follow-up questioning and later Spaces investigation. The user supplied instructions and assisted local access/setup; this assistance is separate from Dots’s reported §5 UI observations. The interview material and follow-up answers were organized on November 3, 2026. These contain edited self-reports and reported observations; raw outputs, internal document originals, environment version, and most observation timestamps were unavailable. The underlying research archive is private and is not reproduced or linked here. Only the technical synthesis and the explicitly requested catalog and schema definitions are included; they are not independent public specifications.

• Official interview context and review limits: Meta, Muse security and privacy, “Memory you control” and its memory FAQ; How We Built Safety Into Muse, September 8, 2026, introduction and “Our Policy Around Data”; checked November 12, 2026. These support the specific control/transparency statements above, not blanket interview or publication authorization. Muse Supplemental Terms (September 8, 2026), the displayed Meta Terms (effective January 1, 2025), Meta AI Terms (effective May 13, 2026) and Muse Privacy Policy (effective September 17, 2026) were subsequently read in the official browser pages; the regional/account-specific governing versions remain unconfirmed.

• General interfaces: Agent Skills specification, MCP architecture, and Tailscale overview, checked November 4, 2026. These explain their respective technologies, not MUSE compliance or integration guarantees.

The supplied illustrations summarize reported responsibilities, conceptual flows and the identified Spaces observations; none is a product screenshot or independent implementation evidence. Appendix letters and supporting-view references embedded in the supplied images reflect an earlier layout; use the current text links and appendix headings. The retained technical detail is in the main text and appendices.