Meta's new models check in before following through on anything important.

On October 12, Meta introduced Muse Wonder and Muse Wonder Full, its new frontier models for agents, and said they check in “before following through on anything important.” That is a good habit for a model to have. It is not a gate. Meta’s page does not say what counts as important or who decides. This post covers the new gap, and a test that shows you where it sits.

This post reads Meta’s announcement through the Of One method. It adds no facts about the models, and every description of them below is company-reported.

What Meta announced

Two models. Muse Wonder is available through the Meta Model API and Muse Code. Muse Wonder Full is available to Muse Code subscribers. Meta says Muse Wonder will soon power experiences in Muse, rolling out to subscribers first.
Active Memory. Meta says the models carry what matters to you across conversations and bring back the relevant details.
Active Focus. Meta says the models keep working when a task gets hard, try other approaches, recover from errors, ask for clarification when needed, and check in before following through on anything important.
The jobs it names. Meta’s examples are navigating an insurance claim, understanding a lease and making sense of someone’s finances, plus coding for people building everything from a game to an app for a new business.
Safety. Meta says the models were trained to avoid sharing private information without permission and to turn down requests to assist in performing actually harmful acts. It says its evaluations follow the Meta Superintelligence Scaling Framework and that a full report is coming soon.

What the page does not say: what “important” means, who sets it, or whether a developer can change when the model checks in.

Every example sits on a gate list

Look at the three jobs Meta chose. An insurance claim involves money and often law. A lease is a legal document. Someone’s finances are money. Of One’s skill file requires human review for legal, financial and money matters, among others (SKILL.md, “Human Gates”). The repo’s rule 7 says these moves need “a named human reviewer before release.”

So the launch examples are not edge cases where a check-in might help. They are core cases where the method already says a person signs. The open question is whether the model’s sense of “important” lands on the same steps.

A check-in is not a gate

The difference is who holds the decision.

A check-in is the model deciding a step matters enough to ask about. It rests on the model’s judgment, which you cannot see in advance.
A gate is written down before the run. It names the step, the category that puts it there and the person who signs. In Of One, even accepting an unresolved unknown takes a named person with a role, an authority basis, an expiry time and the conditions that would reopen it (Question Geometry PROTOCOL.md).

A model that checks in often is better than one that does not. But “the model asked” and “the right person approved” are different events, and only the second leaves a record a reviewer can check later.

The two-list test

You can run this test this week on any agent, Meta’s or another. Use a sandbox copy of the data, not live accounts.

Pick one real process an agent could handle end to end, such as sorting a claim file or summarizing a contract before renewal.
Write List A before the run. Break the process into steps. Mark each step that touches law, money, health, safety, rights, jobs or reputation, or that you cannot undo. Put a name next to each marked step.
Run the agent on the sandbox. Record every place it stops to ask, and every step it takes without asking. That record is List B.
Compare the lists. Sort every step into one of four boxes.

	Agent checked in	Agent did not check in
On List A	Match: keep the gate anyway	Miss: the gap that matters
Not on List A	Extra pause: is your list too short?	Routine

The decision rule: List A wins. A miss means the agent treated a gated step as routine, so that step needs a stop that does not depend on the model’s judgment. An extra pause is a reason to reread your own list, because the model may have spotted a step you underrated. Either way, write down what you found and the date. A model update can change List B without notice.

One run is a sample, not proof. An agent that paused at the right step once may not pause there next time, so read a clean result as “no miss seen yet.”

What is still unknown

Meta’s full safety report has not been published. Until it is, the public page does not say how the check-in behavior was evaluated, how often it fires, or whether it can be configured. On a decision map those are open unknowns, and the trigger is simple: when the report comes out, rerun the two-list test against what it says.

What to do this week

Write List A for one process before any agent touches it, with a named person for every gated step.
Run the two-list test on a sandbox copy and fill in the four boxes.
Put a stop outside the model on every miss, so the gated step cannot run until the named person signs.
Date the result and set a trigger to rerun the test when the model changes or Meta publishes its safety report.

If you want help drawing List A for the processes your team is handing to agents, that is the work of a consult: $400 an hour, in 5-hour blocks.