Microsoft puts clicks and commands inside one Mage agent Microsoft puts clicks and commands inside one Mage agent

A different place to choose the tool

Microsoft describes a 4B model trained in five stages, moving from visual grounding through separate GUI and coding instruction into hybrid training and reinforcement learning. Its reported OSWorld-Verified score rises from 55.84% after hybrid supervised training to 66.04% after reinforcement learning. That final measurement covers two runs, 361 tasks excluding Google Drive, and 50 steps. The reference uses a custom SGLang runtime. The progression matters because it separates acquiring both skills from learning when to use them.

Microsoft’s May 21 MagenticLite release took a different route. MagenticBrain plans, codes and delegates browser tasks to Fara1.5, then resumes after the specialist returns. The harness manages context and pauses critical browser or code actions for human approval. It runs through Quicksand, a QEMU-based sandbox. Splitting the roles creates a visible handoff where an operator can inspect the delegated task and returned result. A unified policy removes that particular boundary; its action trace becomes the place to understand the choice.

Training evidence and deployment evidence

OpenCUA offers an independent comparison through its October 4, 2025 paper revision. Its training pipeline turns recorded human computer use into state-action examples, augmented with reflective reasoning. The authors collected demonstrations across Windows, macOS and Ubuntu. They also report that small environmental differences can produce different outcomes even with deterministic decoding. This makes the training route relevant to evaluation: a model can learn plausible actions without behaving identically across every installation of the same application.

OpenCUA’s error analysis identifies missed saves, unnecessary clicks and different routes to the same goal. Network delays and unexpected dialogs can also change an interaction sequence. Its authors found that extending the action budget often gave diminishing returns: extra steps could be spent repeating mistakes or failing to recognize completion. This evidence puts a useful limit on the idea that more opportunities to act necessarily improve an agent. A successful path needs both a way forward and a recognizable stopping condition. In a hypothetical document workflow, a correct saved file can still conflict with an unsaved application buffer; checking either state alone leaves part of the task unexamined.

The permission boundary survives the architecture change

The comparison also separates a model’s action choice from the operator’s authorization. Fara’s published design includes asking for permission at critical points. That is a useful product behavior, while an execution policy answers a separate question: what happens if a request reaches the tool without that pause. A browser specialist and a unified desktop policy both need an answer. Model packaging does not determine whether an account can send a message, replace a file or access a private service.

MagenticLite makes context management another explicit harness responsibility. Microsoft describes condensed histories and selective context for its specialists. Fara1.5 also has actions for retaining information and requesting user preferences or permission during long tasks. The broader system exposes the agent’s actions and lets users take control. These choices concern what survives between decisions and where a person can interrupt, not just which model handles a screenshot. They help explain why comparing isolated model sizes misses part of the system: delegation, memory and intervention all sit around the prediction itself.

For developers, the architectural trade-off is now concrete. Delegation exposes a task boundary, while a unified policy puts channel choice inside each turn. Neither arrangement specifies what an account is authorized to do. The evidence here supports comparing those divisions of responsibility, rather than treating their benchmark scores as interchangeable. A controlled desktop task offers a clear place to test the difference because its inputs, permitted changes and final state can all be defined in advance.