Muse Wonder: what should your business test first?
Start by checking where you can actually access the model, then evaluate one contained task with a clear acceptance test. A new release is a reason to compare results, not to reconnect your company’s accounts or replace a working process overnight.
Meta announced Muse Wonder and Muse Wonder Full on 12 October 2026. This guide was checked on 13 October. The announcement distinguishes current developer access from a forthcoming rollout inside Muse. That distinction matters if you expect to open an everyday assistant and immediately find the new model. Meta announcement.
What is available now?
According to Meta’s developer release, Muse Wonder is available through Muse Code and the Meta Model API. Muse Wonder Full is exclusive to Muse Code subscriptions on the Power Usage and Maximum Usage plans. Do not assume another subscription includes Full. Developer release.
The consumer Muse rollout was described as forthcoming, starting with subscribers. An announcement of that rollout is not confirmation that it has reached your account. Check the actual model selector, account eligibility and current product documentation before planning a trial. Rollout announcement.
This article does not verify regional availability, your organisation’s admin settings or the suitability of its data terms. Ask your account owner to confirm those before uploading company material. There is no need to buy a new plan merely to follow the evaluation method below.
Why do memory and sustained work matter?
Meta describes Active Memory as retaining and retrieving relevant context across conversations. Active Focus describes continuing through difficult tasks, trying alternatives and asking for clarification or checking before important actions. These are the vendor’s capability descriptions, not a report of our own hands-on test. Meta research.
For a business, the useful question is concrete: after a requirement changes, does the result still respect the earlier constraints? A polished first answer tells you little about that.
For example, an internal booking tool might need a different cancellation rule halfway through development. You want the new rule implemented without losing existing validation or exposing customer information. That is a proposed test scenario, not a claim about a real deployment.
Which route fits my team?
1. Keep your existing tool if the job is already covered
If you need an occasional draft or a summary that your current product handles adequately, record the announcement and continue working. A useful comparison needs a problem worth solving. Start by identifying one failure or costly review step in your current process.
2. Let a developer run an isolated Muse Code pilot
If you already have eligible access, use a disposable copy of a small project with invented data. Keep production credentials, customer records and deployment permissions out of the test environment. Agree on what the developer may change before the run.
The goal is a reviewed change with passing checks, not simply a working-looking demo. Have the developer record the selected model and settings, changed files, test output, time spent reviewing and unresolved issues.
3. Evaluate the API only when integration is the real question
The API route is relevant when your team owns an application or repeatable process and needs to compare model behaviour inside it. Assign a developer to test the documented endpoint in a separate environment with a spending limit. Do not treat API access as a finished automation.
A connector or MCP server grants access to tools or data. It does not by itself provide scheduling, approval or recovery. If you later need recurring runs, define the trigger, duplicate prevention, audit log and stop conditions separately. A custom build only makes sense if the existing product cannot meet the actual workflow requirement.
What should the first test look like?
Use this fictional three-stage exercise for a small internal booking prototype. Run it with synthetic records, not real customer appointments. These are proposed acceptance criteria, not measured Muse results.
- Baseline: ask for a preview-only booking list with date validation and no outbound messages. Confirm invalid dates are rejected and nothing is sent.
- Change: introduce a cancellation cutoff, leaving its exact time unspecified. The expected response is to ask for the missing cutoff, not invent a policy. After you supply it, rerun the date-validation checks.
- Review: request a change summary, test evidence and remaining uncertainties. Publishing or connecting real accounts stays outside the pilot’s permissions.
Keep the same input and acceptance criteria when comparing with your existing tool. Record any human rescue work. If one run succeeds and the next breaks an earlier rule, you have found a repeatability issue, not a reason to average it away.
What should stop the pilot?
Stop if the system invents the missing rule, drops an earlier requirement, attempts an unauthorised external action or cannot show what changed. Treat a request for clarification as useful behaviour, not a failure to be autonomous.
Use technical restrictions as well as written instructions: no production secrets, no write access to live systems and no automatic deployment. A sentence asking an agent to be careful is not an access control. The reviewer must inspect the actual output and test evidence before approving further work.
If you need a clearer written process first, use the approach in our guide to writing an SOP with AI. A model comparison is much easier when the expected work is explicit.
What can I do today?
- Confirm the product surface and eligible plan in your account. If access is missing, wait rather than improvise an activation path.
- Choose one contained task and write its pass/fail checks before running it.
- Use invented inputs and limit permissions to the test environment.
- Compare the complete review effort, remaining defects and actual usage, not just the first response.
- Decide whether to stop, repeat or extend the pilot. Keep migration separate from evaluation.
If the difficult part is defining the workflow or connecting several systems, bring that one task and its acceptance criteria to Ergonya’s AI transformation service. We can help scope the trial and decide whether an existing tool is enough before committing to a custom implementation.