Meta’s launch post for Muse Wonder describes a behavior it calls Active Focus: the model keeps working toward a difficult goal, tries alternative approaches, works through blockers, and, in Meta’s words, asks for clarification when needed and checks in before important actions. Meta also recommends human confirmation before consequential actions, and its coding-agents guide ships Muse Code with approvals and a sandbox on from the first run.
That is the right design. It also raises a question every team running agents in parallel already knows: when the model stops to ask, who is there to answer, how fast, and with what context? A check-in that lands in a terminal nobody is watching is a stalled run. A check-in that lands in a shared Inbox, attached to the Task it came from, is a review step. This post is about building the second kind.
What Active Focus produces
Meta trained for three behaviors and measures them on an internal benchmark it calls FocusBench, where Muse Wonder Full leads at 54.2% and the API-available Wonder sits at 44.9%, behind GPT-6 Astra and Claude Opus 5.5. Set the scores aside; the behaviors are what matter for a board:
- Persistence. The model keeps going through failures. On SWE-Marathon, the long-running coding benchmark, Wonder scores 53.1 against 46.3 for Opus 5.5. Longer runs, more attempts, more to review.
- Clarification. The model asks when the Task is ambiguous instead of guessing. On a board that is a comment on the Task; in a terminal it is a prompt waiting for a keypress.
- Check-ins. The model pauses before an action it judges important. Meta’s own guidance is to make that a human confirmation for anything consequential.
Each one changes the shape of the review queue. Persistence adds volume per Task. Clarification adds interrupts. Check-ins add decisions that block a run until someone makes them.
Where the check-in lands
In Muse Code, an approval prompt appears in the subscriber’s terminal and the run waits. Headless runs (muse exec) have no interactive prompt, so Meta’s docs say to choose a policy that can complete unattended or expect held actions to stay unresolved. That is the honest trade: either a person is at the keyboard, or the model runs with approvals off, or the action waits forever.
On a Sharkly board, the run is a Task assigned to an Agent on a Computer. When the Agent stops to ask, the question returns to the Task as a comment and routes to the Inbox. The Task holds the context: what was asked, what the Agent has done so far, the execution log of tool calls and Runtime events. Whoever picks it up answers on the Task, and the run has somewhere to resume from. The check-in is still a human decision; it is a human decision with a record, a queue, and more than one person who can take it.
That is the difference between a safeguard and a stall. The model behavior is identical. The system around it decides whether a check-in costs a minute or a day.
Writing the Agent so check-ins are useful
A check-in is only as good as the question. Put the standard for a good one in the Agent’s instructions:
Stop and ask before anything destructive, anything that sends data outside the
attached repositories, any payment or external account action, and any change
to CI, deploy or access configuration.
When you ask, state in one comment: what you are about to do, why the Task needs
it, what you considered instead, and what happens if the answer is no.
Do not ask about reversible edits inside the repository. Make them, test them,
and report.
If you have waited for an answer and the Task has a deadline, say so in a second
comment rather than proceeding.
The first rule sets the line. Meta’s model decides for itself what counts as important; the instruction tells it what the team counts. The second rule makes the comment answerable in thirty seconds by someone who did not watch the run. The third rule stops the model from asking about everything, which is the failure mode that turns a careful agent into an annoying one. The guardrails post for Opus 5.5 covers the same boundary from the prompt-injection side: the review gate is the control, whatever the model promises.
Sizing the queue
Persistence means more review per Task, not less. Plan for it.
| Lane | Typical run | What reaches the queue |
|---|---|---|
| Muse Wonder on a long Task | Many steps, several reverted approaches | A longer diff, a longer log, zero to three check-ins |
| Opus 5.5 on the same Task | Fewer steps, more decisive | A shorter diff, or a Task returned half done |
| Any model, unattended overnight | Whatever the policy allowed | Either held actions, or actions nobody confirmed |
Three practices keep the queue moving. Route check-ins to a named reviewer per lane rather than to everyone, so a question is not waiting on a group. Set the Agent’s per-Task timeout so a run blocked on a check-in fails visibly instead of sitting at running for hours. And read the log, not only the diff, for Wonder runs: the path through three failed approaches is the part a persistent model adds, and it is where the subtle mistakes live. Coding agents while you’re away covers the overnight case, and human review is the bottleneck covers why none of this gets cheaper with a better model.
What a good check-in looks like on the board
Here is the shape the instructions above produce, as a Task comment a reviewer can act on from a phone:
Check-in before action.
About to: drop the legacy `orders_v1` table in the migration.
Why: the Task says remove v1 read paths; the table is the last reference.
Considered: keeping the table and removing only the code. Rejected because
the nightly job still writes to it and would fail silently.
If no: I will leave the table, remove the code paths, and note the job in
the report for a follow-up Task.
Four lines, one decision, both branches already planned. The reviewer types “yes” or “no, keep it” on the Task, the run resumes, and the log records who decided. Compare that with a terminal prompt that says Allow? [y/N] to a person who did not watch the preceding forty steps.
Two refinements once the lane has run for a week. If one reviewer is answering most check-ins, give that lane’s Agent a second named reviewer so an afternoon meeting does not stall every long run. And if the Agent is asking about the same class of action repeatedly, that class belongs in the instructions as a standing yes or a standing no, not in the queue.
The computer-use case
Meta lists computer use among Wonder’s capabilities: operating browsers, desktops and mobile apps. That is where check-ins matter most and where a terminal prompt is least adequate, because the action is a click on a screen the reviewer cannot see. The same rules from the Astra computer-use post apply: the Agent runs on a Computer the team chose, the check-in names the screen and the action, and the person confirming can see the Task’s log before saying yes. A model that asks permission to press Submit is only safe if someone can tell what Submit does.
What this is not
Active Focus is a model behavior, and model behaviors are not guarantees. Meta’s own card says the models can make mistakes in unfamiliar multi-step tasks, and its full safety report is still pending. The check-in is a feature that makes a good review system better; it does not replace one. A team that reads “checks in before important actions” as permission to run unattended has misread it. A team that gives every check-in a Task, a reviewer and a timeout has built the thing the feature was designed for.
None of this lands on Sharkly’s bill. Model usage runs through the Meta key configured on the Computer. The model changed on October 12. Context, progress, blockers, results, and human review stayed visible from request to release. You can build this manually with worktrees, or use Sharkly to manage the workflow.
