On 12 October 2026, two models landed that are worth a look if you run automation in production: Muse Wonder and Muse Wonder Full, which Meta calls its most capable to date and built for agentic tasks instead of conversation. Two named behaviours are why the release matters. Active Memory carries what matters to you across conversations and brings back the details relevant to the task at hand. Active Focus stays on a goal when a task gets hard, trying other approaches, recovering from errors and following through, asking for clarification when needed and checking in before following through on anything important, per Meta's announcement.
What you can build against today is Muse Wonder, available through the Meta Model API and Muse Code. Muse Wonder Full is available today for Muse Code subscribers, and Muse Wonder will soon power experiences in Muse, rolling out first to subscribers. Meta positions the family for expert domains including law, finance and health, alongside frontier coding performance, and names three example jobs. Navigating an insurance claim is one, understanding a lease is another, and building a working app is the third.
What Active Memory and Active Focus actually change
Most production agent failures aren't wrong answers. They come from an agent that kept going when it should have stopped. It posted the credit memo, emailed the customer and opened the work order, all on an assumption nobody checked, and the mistake surfaced at reconciliation. The expensive part is never the token spend. It's the rework and the trust you lose with the operations team that has to clean up after it.
So the capability in this release I care about most is the dullest-sounding one. A model trained to pause before consequential actions and to ask for clarification when the task is underspecified is a different engineering object from one trained to be maximally helpful, because it changes where approval gates go and how many you need. Today we gate every write-back, which caps how much work automation actually removes, since a human still reads each exception. If a model reliably stops at the step where it's unsure, you can move gates from "every write" to "writes the model flagged plus a sample", and that's where the operating saving in agentic automation lives.
Active Memory addresses the other recurring cost. Long-running agents lose everything between sessions, so we rebuild state in the prompt on every run, from the policy text and the tool catalogue to the schema of the tables the agent may touch and the decisions the last run already made. Carrying what matters forward is a model-side answer to a problem we currently solve with plumbing.
Neither behaviour is something you take on faith. Both are claims you can test on your own tasks, which is the point of the close below.
The kind of work this lands in
We build data platforms and agents for distributors, manufacturers and commercial real estate operators, mostly on Databricks, and mostly sitting on top of an ERP that was never designed to be queried by a model. Order and inventory data arrives from Business Central through its API pages read incrementally on a lastModifiedDateTime filter, or through the open-source bc2adls extension, and lands in Unity Catalog where permissions can follow an identity. Document work, purchase orders as PDF attachments, maintenance logs, leases and their amendments, is the other half of the pipeline.
The bottlenecks are consistent across all three industries. Extraction is cheap and mostly solved, while judgement on the exception is expensive and still human. Multi-step runs that touch six systems break in the middle and someone restarts them by hand. And the approval gate in front of every write means the agent saves reading time instead of headcount time.
A frontier model attacks exactly one of those four, the judgement call, and makes a credible claim on a second, the gate. That's worth testing, and it's also the reason to leave the rest of the pipeline alone.
Put the frontier model on the judgement call
A distribution workflow shows the division cleanly. An order arrives as a PDF. Extracting line items, matching them to item numbers and flagging unit-of-measure mismatches is high-volume work with a known answer shape, so it belongs on a smaller, cheaper model, and much of it should be a deterministic tool call instead of a token. Then there's the hard case, where the customer ordered a discontinued SKU, the substitution is on allocation, and the standing contract carries a price protection clause. That step justifies a frontier model, and it's the step where you want it to check in before committing.
Manufacturing has the same split at a different tempo. Reading a maintenance log, a vibration trend and a supplier certificate together is multimodal document work. A production schedule change, though, has physical consequences, so it stays behind a gate however good the model gets.
In commercial real estate, understanding a lease is one of the jobs Meta names, and the subtlety is that a lease abstract isn't the deliverable. The deliverable is a CAM recovery calculation that survives an audit, so the agent has to cite the clause it relied on and the document version it read. If the model can take the lease and every amendment in one pass, that still leaves provenance to you. It doesn't store provenance for you.
I would wire this routing in on the first commit, with the model identifier in configuration instead of in code, because the cheap step and the expensive step have different lifetimes. The classifier you picked last quarter will still be fine next year, while the judgement model will change twice.
The parts that stay your engineering problem
A frontier model doesn't give you durable execution. An agent run that spans hours and a dozen systems needs a workflow engine underneath it so a crashed process resumes at the step it reached, and so an action taken twice doesn't post twice. Active Focus is a claim about persistence inside a task, and it's no guarantee about what happens when the host dies mid-run. Retries, backoff and idempotency keys remain yours to own.
It doesn't solve data access either. An agent reasoning about inventory, leases or work orders is only as good as the tables it can reach, which is why row and column permissions that follow the agent's own identity matter more than the model benchmark. We wrote about that pattern in Unity Catalog for AI agents in practice, and nothing in this release changes it.
Two things in the announcement are worth tracking before anyone plans a migration. Meta says the models were trained, evaluated and released in line with its Meta Superintelligence Scaling Framework, and that a full report with additional safety evaluations will be available soon, so the fuller safety evidence you want for a security review isn't out yet. And the announcement sets out capability and availability without per-token rates or rate limits, so find those figures before you commit a workload and price a representative run. The number that decides routing is cost per task, not cost per million tokens, as I argued in paying frontier prices to rename a variable.
Pilot it on a workflow that already has a human reviewer
Pick the process where an operations person already reads every agent output, because you get a free control group. Run Muse Wonder alongside Muse Spark on the same inputs with the same tools, and let the reviewer keep approving as usual. Build the evaluation set from your own documents with your own expected outputs, including the ugly ones, the amended lease and the order with handwriting on it. The thing you're watching for is whether the model's own hesitations land on the same cases your reviewer flags, because that correspondence is what earns a looser gate. If it holds, you can start moving gates. If it doesn't, you learned it cheaply, and your extraction pipeline never had to change.
If you want to talk through where an agent fits in an ERP-backed workflow, that's the work we do on AI.
Frequently asked questions
What are Muse Wonder and Muse Wonder Full?
They are two frontier models Meta introduced on 12 October 2026 as its most capable to date, built for personal and professional agentic tasks and for expert domains including law, finance and health, with frontier coding performance alongside, according to Meta's announcement. Meta describes them as built on the groundwork it laid with Muse Spark.
Where can I use Muse Wonder today?
Muse Wonder is available to developers and builders through the Meta Model API and in Muse Code, while Muse Wonder Full is available to Muse Code subscribers. Meta says Muse Wonder will soon power experiences in Muse, rolling out to subscribers first.
What is Active Focus?
Active Focus is Meta's name for the ability to keep working toward a goal when a task gets hard, try other approaches, recover from errors and follow through, asking for clarification when needed and checking in before following through on anything important. For production automation that check-in behaviour is the part that changes system design, because it decides how many human approval gates a workflow needs.
What did Meta say about safety for these models?
Meta says it trained the Muse Wonder family to avoid sharing private information without permission, to turn down requests to assist in actually harmful acts, and to work on security and defences against cyber attacks, while keeping the models able to find flaws in your own code. It adds that the models were trained, evaluated and released in line with its Meta Superintelligence Scaling Framework, and that a full report with additional safety evaluations will be available soon.