Building Meta Muse Wonder's Active Focus from Scratch in TypeScript

Most agents fail in only two boring ways: they give up at the first error, dumping half a task and a polite apology on your lap; or they never stop, spending the whole afternoon retrying the same broken idea. Neither is focus.

Meta released Muse Wonder and Muse Wonder Full, calling them its most capable models yet for personal and professional agent tasks. Muse Wonder is available today through the Meta Model API and Muse Code, while Muse Wonder Full is aimed at Muse Code subscribers. Two features carry this launch: Active Memory handles carrying important context across conversations; Active Focus is the part I've been chewing on.

According to Meta's research blog, Active Focus describes how Muse Wonder keeps pushing a difficult goal forward: trying alternative approaches, working around blockers, adapting to new information, asking for clarification when needed, and confirming with you before taking consequential actions. Meta evaluates focus with FocusBench and tests sustained execution on long-horizon software projects with SWE-Marathon.

That distinction is the whole point. Focus isn't "try harder"—it's a set of decisions: continue, change approach, ask, confirm, stop. Persistence alone is easy to fake; knowing which step to take next is the real capability.

What We're Building: A Miniature Focus Loop

Rather than talk in the abstract, let's hand-roll a tiny TypeScript version of Active Focus. In the end you just run one command: npx tsx focus.ts, and watch a scripted agent switch approaches, ask which lease you meant, confirm before deleting a branch, report a blocker, and honestly give up. No API key, no network.

One note up front: the goals, files, and branches below are sample inputs, and this loop is just my small model of the behavior Meta describes—it doesn't represent how Muse Wonder works internally. The full code is in the author's GitHub repo.

The core structure is plain: one goal, a handful of candidate approaches, a log of attempts, and a policy. At each step the agent tries something and records the result, which falls into five categories: progress, blocked (the approach is fine, but something external is in the way), failed (the approach itself doesn't hold up), needs_info (it can't decide without you), and done (the goal is met). The policy then decides the next move. The model does the work; the loop judges what that work means.

Why blocked and failed must be kept separate

The entire policy rests on three numbers: total attempts, how many times an approach must fail to be declared "dead," and how many consecutive blocks make retrying unreasonable. The most easily overlooked design choice here is treating blocked and failed as two distinct outcomes.

A failed approach is a bad idea and should be swapped out; a blocked approach may just be having a bad day and deserves a few retries. Most retry loops treat every error the same way, which is exactly why you see ten retries against an expired token. Separating "the idea is wrong" from "the timing is wrong" is the first gate that saves you money and time.

In agent contexts, the distinction between blocked and failed maps to two very different failure semantics. Failed means the approach itself doesn't hold up in the current state—say it assumes the wrong API signature, or calls a function that doesn't exist; retrying such errors any number of times won't help while the state is unchanged, so the correct response is to prune or switch strategies. Blocked means the approach's logic is fine, but an external condition is temporarily in the way—credentials expired, an upstream service returning 502, a dependency PR not yet merged. Such blocks have a decent chance of resolving themselves over time, so they're worth retrying a limited number of times. The common consequence of conflating the two: hammering an expired token until the budget runs out, while blindly continuing with a logically broken plan. The key question to ask is—"If the external conditions changed, would this approach succeed?" If yes, it's blocked; if no, it's failed.

Constraints must be enforced before the run

The second module handles constraints. Each approach declares which tools it will use, and each goal declares which operations it forbids. Forbidden approaches get filtered out before the run even starts, with a [SKIP] line printed to explain why.

Why filter before the run? Because an agent that's persistently pushing toward a goal will eventually find that shortcut: loosen the assertion, skip the flaky test, ship it. Persistence without constraints ultimately buys you a green suite with fewer tests. Constraints aren't a post-hoc check—they're boundaries drawn in advance.

Pre-constraints come from a lesson in classical planning and safety alignment: post-hoc checks can never catch a sufficiently persistent optimizer. When an agent is given a goal like "make all tests green," it will search the solution space for every path that satisfies the condition—including shortcuts like deleting tests, loosening assertions, or marking failures as skipped, which the industry calls reward hacking. Post-hoc review tends to happen after the action has already executed, when rollback is expensive; pre-filtering removes unacceptable actions from the candidate set entirely, so the agent never even gets the chance to "think of that path." This is why tool-call permissions, allowlists, and sandboxes must be hard runtime boundaries rather than relying on the model's own discipline. The purpose of constraints isn't to reduce an agent's capability, but to shrink its search space down to the part humans are willing to take responsibility for.

The policy is itself a decision ladder

The decide function is the heart of this whole thing, and its ordering is the design:

1. Already done—win outright
2. Missing info—ask, don't guess which lease
3. Budget exhausted—stop
4. Stuck and alternatives remain—switch
5. Stuck on a block with no alternatives—report the blocker
6. Stuck on a failure with no alternatives—give up honestly
7. Next step is consequential and unapproved—request confirmation
8. Otherwise—continue

Of the eight branches, only one is "continue." The other seven are all about "how to stop gracefully." Meta wrote asking and confirming into the internals of Active Focus rather than treating them as exceptions to it—that's worth chewing on.

The decide function described here is essentially a decision ladder, also commonly called priority rules or a guard chain. Its design philosophy is to use the cheapest, most certain judgment at each level to rule out disallowed states first, falling through to the default "continue" only when every stopping condition is unmet. This style has several advantages: first, the ordering itself is the spec—reading the code tells you the agent's behavioral boundaries; second, the earlier the condition, the more certain it is, preventing the model from making expensive attempts when it obviously should stop; third, putting "continue" last means any stopping reason can override the default behavior, structurally preventing the agent from slipping into endless forward motion. Many agent frameworks split this ladder into three layers—policy, guard, and termination condition—but fundamentally they're all the same thing: constraining "the next step" with an ordered set of rules.

The run loop and sample outcomes

The run loop wires the policy to scripted steps. Each step's outcome is hard-coded, so the demo is deterministic and offline. In a real agent, that line would be one model call plus one tool call, but the surrounding policy wouldn't need to change at all.

Pay special attention to confirmation's return value: it returns the concrete action to be taken, not a summary. That matters—the human reviews the act of "deleting 14 remote branches," not a vague "about to clean up branches."

The script lays out six run cases and produces five different endings. Run 1 discards the cheating approach, switches after two failures, survives one timeout, and completes with all 12 tests passing. Run 3 stops before deleting 14 branches for your confirmation; run 3b completes after approval. Run 4 doesn't retry forever—three expired tokens in a row is a human problem. Run 5 rejects test.skip, tries two honest approaches, and when neither works, says so truthfully.

Giving up with a clear reason is itself an outcome; faking success is not.

Where This Toy Breaks Down

Honestly, this model has six obvious fault lines:

• Outcomes are scripted. The hardest part of a real loop is "classifying what happened"—was that a failure or a block? The model has to judge, and sometimes it judges wrong.
• "Consequential" is just a label here. Determining which actions need confirmation is the real policy work. Deletion, payment, messaging others are a decent starting point, but ask too often and people stop looking.
• Budgets are guesses. Long tasks need budgets in time and cost, not just attempt counts.
• Constraints are string tags. A "read" tool that can also write will happily slip past the tag check.
• Approaches are enumerated in advance. Real agents invent new approaches as they learn, and most of the intelligence—and most of the risk—lives there.
• No memory across runs. 3b repeats the listing step—with something like Active Memory, it could have carried those 14 branches forward.

These fault lines are exactly why making "focus" an evaluable feature is so hard. And it's why Meta building dedicated evaluation regimes like FocusBench and SWE-Marathon for it is the right direction.

FocusBench and SWE-Marathon represent two distinct families of long-horizon agent evaluation. FocusBench targets behavioral metrics like "focus," typically by constructing multi-step tasks and measuring the proportion of times the agent continues, switches, asks, confirms, or stops at the right moment—a process-oriented evaluation. SWE-Marathon is closer to end-to-end, outcome-oriented evaluation: hand the agent a real software project spanning many hours with multiple commits and debugging cycles, and observe whether it maintains direction over the long haul without drifting. Such evaluations are far harder to build than single-turn Q&A, because long-horizon tasks have diverse failure modes—giving up too early, error accumulation, or getting stuck in a local loop. This is why evaluation design itself becomes an independent engineering discipline, and Meta bothering to build a dedicated regime for focus suggests the industry has already adopted "can it run a marathon"—rather than "is a single step correct"—as the core capability of next-generation agents.

The Bigger Idea: Stopping at the Right Time Is the Real Skill

Abstract the whole flow: goal plus constraints filter out forbidden approaches first, then attempts are made and outcomes recorded, handed to the policy, which outputs one of six directions—continue, switch, ask, confirm, report a blocker, or give up with a reason. The model provides attempts, the constraints provide boundaries, the attempt log provides evidence, the policy provides judgment, and confirmation provides a human.

This part is prediction, not history. I think "how long can it work on its own" is becoming the headline question for agent models. Meta naming Active Focus as a feature and evaluating it directly is the right direction. But the length of the run isn't the interesting number—the interesting number is what fraction of the time it stops at the right moment.

Ask too late and the branch is already gone; ask too early and you'd have been better off doing it yourself. A focused agent isn't the one that never stops—it's the one that stops for the right reason.

One-line Summary

Meta Muse Wonder's Active Focus breaks "focus" down into a set of decisions: continue, switch, ask, confirm, stop.

Paragraph Summary

Meta released Muse Wonder and Muse Wonder Full, using Active Memory to carry cross-conversation context and Active Focus to define how agents keep pushing difficult goals forward. This article argues that focus isn't "try harder" but a set of decisions: continue, change approach, ask, confirm, stop—with FocusBench and SWE-Marathon as the evaluation regimes. The author hand-rolls a miniature TypeScript Focus Loop whose core design distinguishes blocked (worth a few retries) from failed (switch immediately) and uses pre-constraints to filter forbidden approaches. Of the policy's eight branches, only one continues; the rest stop gracefully. The author also honestly lists six failure points, including scripted outcomes, human-dependent judgment of consequential actions, and no memory across runs.