Muse Spark, Muse Code, and Glimmer: Meta’s Full Agent Stack

Meta’s 2026 agent work is easy to misread as a sequence of model releases. It is better understood as a vertically integrated agent stack: a hosted frontier model, an open local model, a coding harness, a personal-agent product, an inference platform, perception and embodiment models, connected services, and distribution through messaging and glasses.

The stack matters because it shows where agent differentiation is moving. The model supplies reasoning and tool-use priors. The harness supplies state, coordination, permissions, recovery, and evidence. The product supplies durable goals and user controls. Connectors and devices decide where the agent can perceive and act.

This article maps what was public through September 26, 2026. It does not benchmark Muse Spark, install Muse Code, or run Muse Glimmer. Performance numbers are Meta-reported unless explicitly labeled otherwise.

The stack in one view

The useful unit of analysis is not any row in isolation. It is the model–harness–tool–policy–device combination that completes a task.

Spark moved from a model into an agent substrate

Meta introduced the original Muse Spark in April, Spark 1.1 in July, Spark 1.2 with Muse Code in August, and Spark 1.3 on September 2. The public arc emphasizes agentic tasks rather than only chat or static benchmark performance.

Spark 1.1 was presented as a multimodal reasoning model for tool and computer use, coding, and long-running work. Meta says it can orchestrate parallel subagents, manage and compact a one-million-token context, mix scripting with interface interaction, and adapt across coding harnesses.

Spark 1.2 concentrated on long-horizon coding and arrived with a harness built to expose that behavior. Spark 1.3 then emphasized sustained open-ended work, fewer unnecessary turns, cleaner code, stronger prompt-injection resistance, and better calibration around irreversible actions. Meta reports that internal engineer comparisons against 1.2 used roughly 20% fewer tool calls and 25% fewer tokens. Those figures are a vendor-reported paired product claim, not a portable cost guarantee.

The engineering inference is narrower and more useful: Meta is co-designing the model for the runtime patterns it expects the model to inhabit. Training includes tools, skills, long trajectories, context management, multi-agent roles, and recovery. That can reduce friction in the favored harness. It also makes cross-harness evaluation more important, because a model optimized for one event vocabulary or coordination style may behave differently inside another.

Muse Code is an event-sourced harness, not a chat wrapper

Muse Code began as a beta on August 5 and left beta on August 31. Its current documentation describes a terminal and CI agent with two independent control layers: approvals before risky effects and an OS-enforced sandbox around shell commands.

Its most important design decision is the append-only session log. Model calls, tool requests and results, approvals, edits, agent lifecycle events, and control operations become ordered records. That log supports:

• inspection of who did what and when;
• session resume after interruption;
• trajectory export;
• forks and safe conversation rewind;
• recovery of retained multi-agent workflows;
• reconstruction of subagent identity and activity;
• reconciliation when an effect began but its completion is uncertain.

Meta’s recovery recipe says an effect with a committed terminal record is treated as complete, while an announced but unconfirmed effect is verified before retry. That is a better recovery model than “replay the last prompt,” although the public recipe is not evidence that every external tool is idempotent.

An event log is necessary but not sufficient. It can prove what the harness recorded. It cannot automatically prove that an external provider committed an effect, that a log was not truncated before durable storage, or that an evaluator interpreted the result correctly. High-consequence tools still need operation identities and independently observable postconditions.

Multi-agent operation has three distinct forms

Muse Code exposes several coordination patterns that should not be conflated.

Child agents inside one tree

A lead session can spawn bounded children and grandchildren. The documented default capacity is eight concurrent agents including the root, configurable up to 64. Children inherit the tree’s effective tools and permission boundary. Spawns, status changes, and controls are journaled.

This is useful for parallel research, implementation, and review. It also increases token use and the number of information-transfer boundaries. A child with inherited tools should still receive a narrowed task and should not interpret delegation text as new user authority.

Persistent background observers

Muse Code documents four default observer roles: memory recall, skill recall, goal tracking, and verification. Each watches one quality axis and proposes a short advisory. A reconciler decides whether that advisory reaches the main agent.

This is an interesting alternative to having one monolithic prompt remember every concern. It resembles an always-on review layer, but “verification observer” should not be read as independent correctness proof. The observer shares the surrounding runtime and may rely on the same incomplete evidence.

Workflows and independent sessions

Workflows coordinate parallel groups and dependent stages, with a control room for pause, resume, cancellation, restart, status, and usage. Separately, independent local sessions can exchange bounded messages while retaining separate transcripts, workspaces, permissions, and tasks. Peer messages are labeled as unverified agent-provided data and cannot grant consent or change permissions.

That last property is especially valuable: coordination is not authorization. A peer can report a finding or request a review; the receiving boundary retains ownership of any effect.

Skills and hooks make the harness programmable

Muse Code bundles skills such as planning and design review and lets teams add reusable skills, hooks, MCP servers, headless runs, and CI integration. This turns the harness into an extension platform.

Extension power creates a supply-chain question. A skill changes model behavior; a hook can observe or affect lifecycle events; an MCP server exposes capabilities; a project rules file can redirect work. Muse Code therefore asks whether a workspace is trusted before loading project instructions, rules, skills, and hooks. Its documentation says untrusted checkouts do not activate project AGENTS.md or CLAUDE.md files.

That is a sensible default. A mature release process should go further:

• pin every extension and model version;
• record the exact instruction and tool manifest in each run;
• scan extensions before activation;
• test skills with and without the intervention;
• keep high-risk policy outside editable project files;
• provide revocation and rollback when an extension is compromised.

Glimmer makes the deployment boundary a design choice

Muse Glimmer is a 30-billion-parameter open-weight model released under Apache 2.0 for always-on local agents. Meta describes a three-stage training process: logit distillation from Spark outputs, agent- and long-context-heavy mid-training, and post-training that combines supervised fine-tuning, on-policy distillation, and reinforcement learning.

The release targets local tool use, coding, multimodal input, failure recovery, controllable reasoning effort, and more than 100 languages. Meta says an approximately four-bit quantized language model fits under 20 GB and can share a 24–32 GB memory envelope with the visual encoder, KV cache, and a speculative-decoding drafter. The DFlash-based drafter proposes token blocks that the main model verifies.

Local execution can improve offline availability, latency control, data locality, and operator ownership. It does not automatically provide the hosted Muse harness:

• local weights do not create a credential broker;
• a local shell is not a sandbox;
• a local browser is not an authorization layer;
• a private machine does not prevent unsafe external actions;
• an open model license does not certify the skills or tools around it.

The deployment decision should therefore be explicit:

Voice, avatars, and glasses expand the observation plane

Muse Voice Transcribe provides streaming speech recognition, diarization, endpointing, code-switching, and long audio. Muse Realtime Voice and Realtime Avatar share speech tokens so the visual performance remains synchronized with the generated voice. Meta reports approximately 870 ms from the end of a user turn to the first byte of synchronized output under its described serving configuration.

At Connect on September 24, Meta announced that Muse would come to AI glasses, where it can act on what the wearer is looking at, converse while background work continues, and reach more shopping, travel, productivity, and payment partners. It also announced a separate email identity for Muse.

This is not merely a new input channel. It expands the harness’s responsibilities:

• visual context may include bystanders, private spaces, or ambiguous objects;
• voice can blur who issued an instruction and whether consent was captured;
• an agent email address becomes an identity that external systems may trust or spoof;
• background action can continue while conversation moves to another topic;
• an expressive avatar may increase user trust beyond the system’s measured reliability;
• real-time latency pressure can tempt teams to skip expensive checks.

The model may perceive more. The harness must decide what is retained, who authorized an action, which observation justified it, and when the system should ask instead of act.

The stack’s strongest and weakest ideas

The strongest ideas are architectural:

• co-train models for the runtime behaviors they will perform;
• use event sourcing for durable sessions and recovery;
• treat approval and sandboxing as independent controls;
• separate peer coordination from user authority;
• keep secrets out of the reasoning runtime;
• expose visible goals, activity, memory, and permissions;
• offer local and hosted execution as different trust and capability profiles.

The weakest claims are the universal ones. Multi-agent operation does not inherently preserve quality. A million-token window does not guarantee the right context. A verification observer is not an independent oracle. Open weights do not create a secure personal agent. A detailed first-party security post does not replace attack-rate evidence. A beautiful avatar does not make an action more reversible.

A practitioner’s adoption sequence

If evaluating the stack, begin with a narrow workload and make the release unit explicit:

release = model version
        + Muse Code or custom harness build
        + rules and skills manifest
        + tool and connector catalog
        + permission profile
        + sandbox profile
        + evaluator set

Then run five experiments:

1. Compare the same tasks with the same model in the target harness and a simpler baseline.
2. Interrupt tool execution before, during, and after a durable external effect.
3. Inject malicious content through repository files, tool output, web pages, and peer messages.
4. Run each skill present and withheld, including unrelated tasks that could trigger it incorrectly.
5. Upgrade only one of model, harness, skill bundle, or permission profile and replay the frozen suite.

Adopt the stack where the combination improves accepted outcomes under a declared budget and authority boundary. Do not select it from a model leaderboard alone.

Sources and evidence notes

The model timeline and claims come from Meta’s releases for Spark 1.1, Muse Code and Spark 1.2, Glimmer, and Spark 1.3. Runtime mechanics come from the current Muse Code documentation, permissions, extension, workflow, session-messaging, and recovery pages.

Embodiment and distribution claims come from Bringing Your Muse to Life and Meta’s Connect 2026 recap. All are first-party sources. The series ledger records evidence classes and limitations. No performance reproduction is claimed.

What to read next

• Meta Muse under the hood: architecture and security review.
• Harness Engineering on September 26: the latest field update.
• The personal-agent harness research roadmap after Muse.
• Why the deployed system—not the model—is the release unit.