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.

On this page27 sections

At a glance

Section	Key takeaway
1. Execution loop	MUSE describes a harness that assembles context, executes permitted tools and inspects results around model decisions. Continuity comes from coordinating execution with retained state.
2. Tools and connections	MUSE reports on-demand function schemas and document-driven connector commands, with Skills guiding both. Its 112-name catalog counts executables, not model functions; capability loading, action approval and service authorization are separate.
3. State and memory	MUSE reports PostgreSQL records alongside persistent files, while only selected material enters model context. Corrections must update source records and dependent summaries: useful memory requires selection and maintenance as well as storage.
4. Background work	MUSE distinguishes triggers (Cron/Hooks), retained purpose and progress (Goals), and reading or proposals (Feed/Ideas). Continuing work combines these separate responsibilities; a saved goal is not itself a trigger.
5. Spaces continuity	Meta describes revisitable personal features. Dots observed one note and its completed state survive reopening and a heading-only rebuild in the synthetic app. This demonstrates that limited case; restart recovery and schema migration were not tested.

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.

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.

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.

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.

Layer	Information reportedly supplied to the model	When and how it is loaded	What it enables, and what it does not establish
Native function tools	Function names and JSON schemas for core capabilities, such as chat, browser operations, artifacts and schedules	The interview describes namespace-level lazy loading; tool_search loads the relevant schema when needed	The model can select a function and form its arguments. This is not the same inventory as the 112 filesystem names. Exact request encoding and complete schemas remain unavailable.
Service connector CLI	CONNECTOR.md: command syntax, flags, account selection, permissions, output format and operating rules	The interview describes reading the relevant document for the task; the model then constructs a command for a shell-execution tool	The executable calls the service and returns a tool result, often structured JSON. The memo explicitly says this is not a wholesale dump of --help into context.
Skills	Short descriptions for discovery, followed by a Markdown procedure in SKILL.md; optional references and scripts	The Skill answer describes descriptions in context, choosing the most specific applicable Skill, and skill_search when needed. The package comparison reports separate skill.yaml metadata including include_in_prompt	A Skill guides decisions and tool use; its existence does not make it an executable or prove Agent Skills conformance. The separate-metadata layout is a reported difference from the specification.
Core context and retrieved detail	Core identity, user and memory files plus compact indexes; relevant detailed records and documents	The context answer distinguishes routinely supplied core context from on-demand retrieval	TOOLS.md is described as environment guidance, not as the full list of machine-readable tool schemas. Retained content is not necessarily included in every inference request.
Results returned to the model	Tool outputs, often JSON; for large outputs, bounded pages or file paths with coverage information	The service-connection answer describes interpretation of returned structured results; the context-management answer describes paging and retrieving only relevant portions	A returned result supports the next decision. It does not by itself prove success, authorized side effects or complete coverage.

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.

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:

Reported class	Count	Representative names
External-service connector CLI	66	hatch_gws_cli, github, slack, gumroad-mcp
Internal runtime	19	hatch-execd, hatch-vault, spawnd
Functional tool	27	web-search, browser-service, media-generation

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.

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.

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.

Reported table	Columns	Role
chat.chats	12	Chat identity and lifecycle
agent.sessions	5	Session identity, originating request and archive time
agent.context_items	21	Ordered context with message/tool references and content
agent.compactions	7	Summary and the history range it replaces
agent.runtime_restart_checkpoints	8	Per-agent restart state

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.

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.

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.

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.

Mechanism	Reported role
Cron	Scheduled instructions wake an agent, rather than merely launching a shell command.
Hooks	Check state changes, including through polling; event-oriented behavior does not imply push delivery.
Resident services	Processes that keep running.
Goals	Persistent purpose, progress and associated work; jobs can be linked to a goal, which is not itself a clock.
Feed	Generated reading material based on context and research.
Ideas	Proposals that can lead to execution when the user selects 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.

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.

Reported boundary	Description
web_static	Hosted build-time page; browser JavaScript can run, but this type does not save visitor input.
web_fullstack	Interactive application with server/storage support, saved state and live data.
Files	Current application area workspace/ts-spaces; older documentation uses workspace/spaces. File artifacts use workspace/your_files/<slug>/ or a goal’s files/ area, with a .src marker for builder-created directories.
Actions	Dedicated build/edit/inspection interfaces and typed application actions, also normalized into HTTP APIs; the conversational agent is described as using these rather than directly reading app source, logs or database contents.
Application database	An app-specific app.db, associated with its slug and described as retained across updates/restarts. The filename alone does not identify an engine.

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 changes and background updates

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.

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 operation	Result observed by Dots
Request creation from MUSE, then add and complete a note in the UI	The app opened and displayed the note, a checked state and 1/1 done.
Close and reopen	The same note and completion state remained.
Request a heading-only v2 change and reopen	LAB NOTEBOOK V2 — SYNTHETIC DATA ONLY appeared; the same note, checked state, 1/1 done and original displayed creation time remained.

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.

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.

Reported class	Executable name
External-service connector CLI (66)	aftership, agoda, asana, box-cli, calendly, canva, dropbox, duffel, etsy-cli, evernote, facebook-cli, figma, flightaware, github, granola-cli, hatch_gws_cli, hatch_igd_cli, hatch_messenger_cli, healthkit-cli, imap-email, instagram-cli, instagram-messages-cli, klaviyo, linear, meta-ads-cli, meta-catalog-search, moneyforward-me, muse-mail, notion-cli, onepassword, opentable, outlook-calendar, outlook-contacts, outlook-mail, peloton, philips-hue, plaid, printify, quickbooks, shopify, shopify-ucp-cli, slack, spotify-api, save-to-spotify, stripe, stripe-link, tailscale, tessie-api, threads-cli, threads-messages-cli, ticketmaster, todoist, vercel, withings, zapier, zoom, healthex, function-health, ghl, gumroad-mcp, readwise-mcp, runway-mcp, shopback-mcp, vidiq-mcp, lovable, replit
Internal runtime (19)	hatch, hatch-browser-lease-helper, hatch-connector-output, hatch-doctor, hatch-execd, hatch-healthd, hatch-multicall, hatch-rescue, hatch-rescue-systemctl, hatch-rescuectl, hatch-slide-style, hatch-vault, hatch-ws-client, hatch-zeitgeist, hatch_gws_auth, authdc, spawnd, ingress-rev-proxy, privsep-test-fully-isolated
Functional tool (27)	browser-broker, browser-service, web-search, local-search, image-search, places, geocode, media-generation, avatar-media-generation, media-library, tts, edits, shopping, shop-wallet-cli, device-data, native-comms-cli, health-cli, nutrition-cli, wearables-display, builtin-artifacts, genui-display-render, feature-request, subscription-status, remote-storage, share, pickup-briefing-animation, zbar-lib

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

Column	SQL type	Nullability / reported constraint
chat_id	text	NOT NULL; PK
origin	text	NOT NULL
lifecycle	text	NOT NULL
status	text	NOT NULL
thread_title	text	Nullable
source_session_id	text	Nullable
source_prompt_seq_upper_bound	bigint	Nullable
source_message_id_boundary	text	Nullable
created_at	bigint	NOT NULL
updated_at	bigint	NOT NULL
pinned	boolean	NOT NULL; default false
pinned_order	bigint	Nullable

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

Column	SQL type	Nullability / reported constraint
session_id	text	NOT NULL; PK
root_request_id	text	Nullable; FK
created_at	timestamp with time zone	NOT NULL; default now()
updated_at	timestamp with time zone	NOT NULL; default now()
archived_at	timestamp with time zone	Nullable

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

Column	SQL type	Nullability / reported constraint
context_item_id	bigint	NOT NULL; PK; sequence-generated
agent_id	text	NOT NULL
seq	bigint	NOT NULL
item_kind	agent.context_item_kind (enum)	NOT NULL
message_id	text	Nullable; FK
tool_call_id	bigint	Nullable; FK
tool_output_id	bigint	Nullable; FK
role	runtime.message_role (enum)	Nullable
call_id	text	Nullable
tool_name	text	Nullable
success	boolean	Nullable
message_source	text	Nullable
created_at	timestamp with time zone	NOT NULL; default now()
data_fbids	bigint[]	Nullable
data_message_ids	text[]	Nullable
data_cleanup_checked_at	timestamp with time zone	Nullable
data_summarized_at	timestamp with time zone	Nullable
data_thread_ids	text[]	Nullable
data_expires_at	timestamp with time zone	Nullable
text_content	text	Nullable
item_json	text	Nullable

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

Column	SQL type	Nullability / reported constraint
compaction_id	bigint	NOT NULL; PK; sequence-generated
agent_id	text	NOT NULL
checkpoint_context_item_id	bigint	Nullable; FK
replacement_history_first_seq	integer	Nullable
replacement_history_last_seq	integer	Nullable
created_at	timestamp with time zone	NOT NULL; default now()
summary_text	text	NOT NULL

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

Column	SQL type	Nullability / reported constraint
agent_id	text	NOT NULL; PK
mode	text	NOT NULL
payload_json	text	Nullable
created_at	bigint	NOT NULL
updated_at	bigint	NOT NULL
recovery_class	text	Nullable
recovery_owner_id	text	Nullable
execution_config_json	text	Nullable

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:

Reported type	Described behavior	Important boundary
web_static	A hosted page fixed at build time; browser-side JavaScript can execute	Visitor input is not saved by this type; it is not the persistent interactive-app contract
web_fullstack	A hosted interactive application with server/storage support, saved state and live data	The general interview did not identify its server runtime, database engine or isolation model

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:

Layer	Reported implementation	Scope of the evidence
Language	TypeScript 5.6.3	Generated-project report
UI	React / React DOM 19.2.5, TanStack Query 5.100.10, Tailwind CSS 4.1.13	Reported dependencies and client implementation
Validation and persistence adapter	Zod 4.4.3, Drizzle 0.45.2	Reported action/schema implementation
Build / install	Bun 1.3.10	Confirmed by the reported build/install inspection; not confirmation that the production server runs on Bun
Database	SQLite, named app.db	Reported SQLite schema declaration, migration-journal dialect and actual table SQL, rather than inference from the filename
Platform metadata	runtime: typescript, platformVersion: 28, package hatch-space-cvm-v1, cvm_runtime_version: 4	App/configuration metadata reported by Muse; these labels do not establish host process or isolation details

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:

notes column	Reported SQL definition
id	INTEGER PRIMARY KEY AUTOINCREMENT
text	TEXT NOT NULL
done	INTEGER NOT NULL DEFAULT 0
created_at	INTEGER NOT NULL

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.