Meta Muse: give a personal agent a job you can verify

What the documentation establishes

Meta introduced Muse as a personal agent with a dedicated virtual computer and browser for acting across apps. The launch announcement describes a US rollout and user-controlled access. Source ↗

Meta's safety documentation says the agent can make mistakes and describes different permission levels for reading and acting. Product access does not make its output independently verified. Source ↗

On October 12 Meta announced Muse Wonder and Wonder Full. Developer availability and the coming personal-Muse rollout are distinct. Source ↗

The model card uses differing benchmark sources and evaluation configurations. Its results are not a uniform independent test of every assistant product. Source ↗

The walkthrough below is an original worked exercise. We have not independently tested this product’s performance.

What changed on October 12

Meta describes improved sustained work and use of prior context. Treat these as capabilities to evaluate on a task you know, rather than assuming a benchmark result predicts your personal assistant. The existing class-comparison exercise still works; the added correction exercise below makes a changed preference observable.

The model card mixes benchmark sources and configurations. Record the product surface, selected model if visible, date and settings before comparing runs. If the agent does not reveal a model identifier, write unknown. Do not label two runs a controlled model comparison when the surrounding tools or available context differ.

1. Start with an observable task

Choose a real decision: find three beginner pottery classes within a stated area, offered after work, within a fixed total budget. Give an actual neighborhood and date range when you use the brief. If a search cannot establish a price or schedule, the result should say unknown instead of quietly relaxing your requirements.

Before delegating, write down how long the task usually takes you. Afterwards, include the time spent correcting the result. This turns an impressive demo into a practical comparison of total effort. Do not use invented test results as evidence of reliability.

Find three beginner pottery classes near [location] for [date range].
My maximum total budget is [amount], including required materials.
Use public provider pages. Return a table with location, schedule, total
price, cancellation terms, and a source link for each important fact.
Mark unavailable information as unknown. Do not contact providers, create
accounts, reserve places, or spend money. Finish with the two tradeoffs
I must decide. Stop if none meet the constraints; do not widen them silently.

2. Check the evidence before ranking

Open the provider page for each proposed class. Check that the schedule belongs to the requested date range, not last season. Confirm whether the displayed fee includes materials and whether ‘beginner friendly’ is the provider’s wording or an inference. A polished table can hide one missing detail that changes the decision.

Keep eligibility separate from preference. First eliminate options that fail hard requirements. Then compare remaining choices by travel, schedule, and cost. If one option has an unknown cancellation policy, keep that uncertainty visible; it is not automatically worse, but it needs another check before purchase.

3. Add context only when it improves the result

If travel time is the decisive factor, provide a neighborhood or transit preference. If a calendar conflict matters, provide the few relevant busy windows. You do not need to expose an entire mailbox to test whether the agent can compare schedules. Add access in response to a concrete missing input.

Save a small preference note with explicit scope: ‘For evening classes, prioritize public transport and arrival before 7 pm.’ A preference for this task should not become a universal instruction that changes unrelated work. Ask the agent what assumptions it retained when starting the next task.

4. Turn the result into a controlled next step

After selecting a class, give a fresh instruction that names the exact provider, session, total price ceiling, and action you want. If you only want a draft inquiry, say so. The first research brief did not authorize a booking. Keep a copy of the option you chose and the supporting page so changes in price or availability can be recognized.

Test the same brief on a second category, such as a repair appointment or language lesson. If the agent repeatedly loses a constraint, revise the brief rather than giving it more access. If the correction effort exceeds the time saved, keep the task manual or reduce its scope.

Record: task / elapsed time / correction minutes / constraints missed / broken sources / final decision. Repeat on three real tasks before expanding the agent's standing responsibilities.

5. Test whether a later correction replaces an old preference

Use the following entirely fictional class records. They are test inputs, not real listings. Supply them in the same task context as a comparison request. This separates reasoning about your constraints from live search freshness. Save the initial answer before supplying the correction so you can see exactly what changed.

For the first pass, the budget is 120 including required materials and the class must start at or after 18:00. Clay A totals 105 and Clay B totals 95, so both qualify. Clay C totals 85 but starts too early. If the assistant selects Clay C, the low price has improperly overridden the time constraint.

These are invented fixtures, not real providers. Do not browse or book.
[A1] Clay A: Tuesday 18:30; tuition 90; materials 15.
[B1] Clay B: Thursday 18:00; tuition 95; materials included.
[C1] Clay C: Wednesday 17:00; tuition 75; materials 10.
[P1] Maximum total 120; start time must be at or after 18:00.
Return all eligible options with arithmetic and supporting fixture IDs.
Explain exclusions. Take no external action.

Now deliver a correction as a separate message. Lower the budget to 100 and exclude Thursdays. Under the updated constraints, none of the three choices qualifies. This is the important result: the agent must be willing to return no match instead of quietly reviving the old budget or ignoring a day conflict.

[P2] Correction: my total budget is now 100, and Thursdays are unavailable.
P2 supersedes P1 only for budget and available days.
The at-or-after-18:00 start-time rule still applies.
Re-evaluate A1, B1 and C1. Show each failed constraint and the fixture ID.
Do not suggest that any option qualifies if none does.
Do not contact a provider or change a calendar.

Ask the agent to restate the active constraints without adding new ones. It should retain the time rule while replacing the budget and availability. A correct answer within this conversation demonstrates this small context test only; it does not establish that cross-session memory, a future scheduled task or every connected app will behave the same way.

If you want to test a later session, retain the same fixture IDs and explicitly record what context the product actually carries across. Do not repair the answer before saving the failure. Repeat the correction with a different budget and day exclusion, then total the verification time. A strong assistant should make its uncertainty easy to locate, even when the right answer is that no option remains.

Guide history

Revisions preserve the original instructions. A source recheck alone does not create a new revision.

Revision 2 · Preserved the original class-comparison guide; added October 12 model/product availability distinctions and a fictional memory-correction test with exact arithmetic, expected exclusions and benchmark caveats.

Revision 1 · Initial documented guide

Continue learning