Meta Muse Wonder: what business teams should test

Meta released Muse Wonder and Muse Wonder Full on October 12, 2026. For a business team considering a new AI provider, the useful questions are specific: which version can the team access, what can it do inside the chosen application, and how will an operator know that a task actually finished? Meta: Muse Wonder launch, October 12

This article explains the launch and proposes an evaluation for a freight operations assistant. The example, outputs and acceptance criteria are illustrative. We have not benchmarked Muse Wonder or deployed it for a client. I would use the launch to identify a candidate for testing, then decide against the operating team's own cases.

Muse Wonder, Wonder Full and Muse are different choices

Muse Wonder is a model; Muse is the assistant product, and Muse Code is the coding agent. Meta says the new models will reach Muse experiences first for subscribers. That rollout statement should not be read as universal availability in every account. A team building its own operations software should check the developer surface it intends to use. Meta: model availability and Muse rollout

Meta's model documentation identifies the API model as muse-wonder-1.0. Setting its reasoning effort to max does not select Wonder Full. The distinction matters when comparing results: record the variant, surface and settings so another engineer can reproduce the test. Meta Model API: Wonder variants and access

What Active Memory and Active Focus mean for operations

Meta describes Active Memory as carrying relevant details across conversations, and Active Focus as persisting with a goal, recovering from errors and checking before important actions. These are vendor descriptions. They do not establish that an API call provides a complete persistent case store or that a particular customer workflow will recover correctly. Meta: Active Memory and Active Focus

In a freight desk, memory might help the assistant retain a customer's preferred collection window. The transport system must still determine today's booking and shipment status. A remembered preference can become obsolete when an employee changes the order. I would give each remembered fact a source, observation time and scope, and require a fresh read when the next action depends on it.

Persistent work also needs an owner. An assistant that tries another approach after an error should remain within the same authorized job. If a quote lookup fails, reading another approved source may help. Booking a different service changes the commitment and needs its own release decision. Recovery behavior belongs in the test cases, including the point at which the assistant should stop.

A large context window helps only with the right evidence

The developer overview lists a 1,048,576-token context window and marks Muse Wonder as preview. It describes compatibility with existing API clients. Those features can make an integration easier to explore, but compatibility of request formats does not establish identical tool behavior or output quality. Meta: API overview, context window and preview status

For the freight pilot, I would retrieve the active shipment, valid carrier offers and the relevant operating rule. Loading an entire customer archive would add expired quotes and irrelevant correspondence. The application should retain source identifiers alongside the extracted facts, so the operator can inspect why a candidate was proposed. Test contradictory evidence explicitly; adding more context can add more disagreement.

Walk one freight exception through the proposed agent

Our fictional case F-72 concerns a missed collection. Shipment version 12 permits a replacement service up to a specified ceiling, but requires a dispatcher to approve the carrier and pickup window. Carrier quote Q-19 fits the ceiling and expires at 16:00. A customer's message asks for collection before 15:00; the carrier's reply only confirms a window ending at 17:00. The assistant has a feasible price and an unresolved service requirement.

The first task is to prepare that discrepancy for review. The agent can identify the cheaper offer, point to the conflicting windows and draft a question for the carrier. The application should expose the unresolved field. Treating the latest email as proof that the customer accepted the later window would create an unsupported fact.

case_id: F-72
shipment_version: 12
quote_id: Q-19
quote_expires_at: 16:00
customer_latest_pickup: 15:00
carrier_window_end: 17:00
service_conflict: unresolved
next_step: dispatcher_review
carrier_booking_performed: false

Now introduce a second event. Before the dispatcher responds, an employee assigns another carrier at shipment version 13. A proposed update based on version 12 is stale. The application should retrieve version 13, show the employee's assignment and invalidate the old release item. Test that behavior with a real source-system change in a sandbox. A model's explanation of freshness is weaker evidence than observing that the stale booking never happened.

The model can propose tool calls, while the integration determines which calls actually run. I would keep the initial pilot read-only, then add a narrow write endpoint that checks the current record, exact reviewed payload and allowed fields. A generic browser session with broad account access would make it harder to enforce and audit the same contract. Our document-agent article explains the separate risk of instructions embedded in incoming material. Read: document text and execution permission

Check the data mode before uploading company records

Meta documents Standard mode as excluding submitted content from model training. Muse Code subscriptions also offer Contributor mode, enabled by default, which allows training use in exchange for more usage. Wonder's pay-as-you-go API uses Standard mode. Confirm the actual setting before supplying company records. Meta: Standard and Contributor modes

Training use and retention are separate questions. The team's review should cover what it uploads, the contractual handling of that data, workspace access and the retention needed for the application. Start with synthetic cases while those questions are unresolved. Do not infer a retention promise from a statement about training.

Compare complete workflows, with the settings recorded

Keep the same source records, tools and allowed actions when comparing Wonder with the current provider. Test routine cases and deliberately difficult ones. Record whether the operator could finish the case, how much correction it required and whether any forbidden update occurred. Published benchmark rankings answer questions about their own test sets; they cannot establish the outcome for this desk.

Calculate the cost per accepted case from model charges, tool usage, retries and operator time. A longer run can consume more calls even when the final answer is correct. Count cases still awaiting review separately from completed work. If Wonder improves difficult cases but adds cost on routine ones, the team can test a narrower assignment instead of moving the whole queue.

Begin with one exception queue whose operating rules and owner already exist. Agree the acceptable error types and rollout limits before running the comparison. Keep the current provider available until the candidate passes those cases and the operator can recover a failed job without an engineer interpreting the conversation. Our model-adapter article covers the integration contract behind that comparison. Read: model replacement and application contracts