---
title: MobiMind-Series Mobile Agent Models
url: https://www.emergentmind.com/topics/mobimind-series-agent-models
type: topic
---

# MobiMind-Series Mobile Agent Models

Searching arXiv for the cited mobile-agent papers and related MobiMind-series work.
MobiMind-Series Agent Models denote the model backbone of MobiAgent: a specialized family of mobile GUI agent models that decomposes automation into distinct roles rather than relying on a single monolithic vision-language policy. In the reported configuration, the series consists of **MobiMind-Planner-4B**, **MobiMind-Decider-7B**, and **MobiMind-Grounder-3B**; these models are integrated within MobiAgent, accelerated by **AgentRR**, and evaluated by **MobiFlow** [2509.00531]. In a broader historical sense, the series belongs to a mobile-agent research trajectory in which instruction understanding, history-aware decision making, visual grounding, memory, reflection, and deployment efficiency are progressively separated into explicit components rather than collapsed into a single next-action predictor.

## 1. Genealogy and problem setting

The immediate antecedent of the MobiMind design is the earlier **MobileAgent** line, which framed mobile control as an LLM-centered pipeline that consumes a prompt built from the **task goal**, **agent role**, **current environment / DOM information**, and **historical operations**, then emits one of several action-oriented instruction types: **Operational Instructions**, **Task Status Instructions**, or **Structured Instructions**. In that formulation, the agent repeatedly reads screen context, generates a command, and acts on the mobile UI until the user’s objective is achieved. The same work also argued that mobile agents should not fully automate everything, because privacy permissions, medical authorization details, clinic selection, and related user-dependent decisions should remain under user control; accordingly, human confirmation was embedded directly into instruction generation through the **Structured Instructions** mechanism rather than isolated in a separate safety module [2401.04124].

Subsequent work expanded the mobile-agent problem from single-pass interaction to hierarchical, experience-accumulating control. **Mobile-Agent-E** introduced a hierarchical multi-agent framework with a **Manager**, **Perceptor**, **Operator**, **Action Reflector**, and **Notetaker**, together with persistent long-term memory in the form of **Tips** and **Shortcuts**. The stated motivation was that practical mobile tasks require “intensive reasoning,” “long-horizon planning,” and “exploration,” and that prior agents “treat every task as if it were their first attempt” [2501.11733]. This establishes a direct conceptual precursor to later MobiMind-style decompositions: strategic planning, low-level execution, error verification, note aggregation, and reusable procedural knowledge are all treated as distinct functions.

Within this lineage, MobiAgent makes the modularization explicit at the model level. The paper presents the **MobiMind-series** as the model backbone of a comprehensive mobile agent system and states that the series is designed to turn mobile GUI automation into a **multi-role, modular system** rather than a single monolithic vision-language agent [2509.00531]. Later work generalized this family logic beyond mobile-only environments. **Mobile-Agent-v3.5** introduced **GUI-Owl-1.5**, described as the “latest native GUI agent model,” with instruct and thinking variants at **2B, 4B, 8B, 32B, and 235B-A22B**, spanning **desktop, mobile, browser, and more**. That development suggests a continuation of the same design direction: role specialization at the system level, together with broader platform unification at the foundation-model level [2602.16855].

## 2. Core model architecture

The defining architectural property of the MobiMind series is role separation. The paper states that MobiAgent adopts a **multi-agent architectural design** with a **Planner (4B)** that produces the task plan at a high level, a **Decider (7B)** that reasons about the next action from screenshot, task, and history, and a **Grounder (3B)** that converts a high-level click target into a concrete bounding box [2509.00531].

| Model | Primary role | Reported behavior |
|---|---|---|
| MobiMind-Planner-4B | High-level task decomposition / planning | Produces the task plan and high-level experiences |
| MobiMind-Decider-7B | Medium-level reasoning and action selection | Takes screenshot, user task, and action history; outputs reasoning, action choice, and JSON parameters |
| MobiMind-Grounder-3B | Low-level GUI grounding | Takes screenshot, user intent / reasoning, and target element description; outputs bounding box in absolute coordinates |

The paper is explicit that this is **not one model with multiple heads**; it is a **specialized set of models** that collaborate. The differences across the series are given in terms of **role, scale, and output abstraction**. The Planner handles the highest-level task decomposition, the Decider performs history-aware action reasoning, and the Grounder maps semantic descriptions into executable coordinates. This suggests a deliberate separation between semantic control and geometric localization, which is particularly consequential in mobile settings where the same intent can require both long-horizon reasoning and precise touch placement.

The **MobiMind-Decider** is **post-trained on Qwen2.5-VL-7B**. It takes as input the current screenshot (`<image>`), the user task, and the action history, and outputs reasoning, an action choice, and parameters in JSON. Its action space includes `click(target_element)`, `swipe(direction)`, `input(text)`, `wait`, and `done`. The paper emphasizes that the Decider outputs a **high-level description of the target UI element rather than coordinates**. That description is then passed to the Grounder [2509.00531].

The **MobiMind-Grounder** is **post-trained on Qwen2.5-VL-3B**. It takes the screenshot, user intent / reasoning, and target element description, and returns the target bounding box as JSON of the form `{"bbox":[x1,y1,x2,y2]}`. In effect, the Grounder provides the screen-space realization of the Decider’s semantic action proposal. Because MobiAgent is designed to integrate with **GUI-based** and **XML-based** backends, this grounding layer also serves as the interface between abstract action selection and backend-specific execution [2509.00531].

## 3. Data pipeline, supervision, and post-training

The MobiMind-series training pipeline is built on a custom real-world trajectory dataset rather than on synthetic supervision alone. The paper describes a lightweight smartphone action recording tool that logs **every user action**, **screen bboxes from XML hierarchy**, and the **corresponding device state**. The collected action space consists of `Click(bbox)`, `Input(text)`, `Swipe(direction)`, `Done()`, and, for special cases, `Wait(sec)`. When XML is incomplete, the system uses **OmniParser** to regenerate missing bounding boxes [2509.00531].

The collection pipeline also includes explicit AI assistance. For simpler tasks, a strong VLM such as **Gemini-2.5** is prompted to execute tasks and record trajectories. More importantly, the paper reconstructs reasoning traces from trajectories by prompting **Gemini-2.5** to simulate a **ReAct-style agent** and produce both step-wise reasoning and abstract action primitives such as “click search button.” This means the training supervision includes not only actions and boxes, but also reconstructed reasoning and high-level operational descriptions [2509.00531].

Several refinement procedures are then applied to improve coverage and training stability. These include **task concatenation** to join temporally dependent trajectories into more complex tasks, **data redistribution** to balance prefix/suffix sharing, **history augmentation** to include partial-history examples, **prompt generalization** to assign multiple semantically equivalent task descriptions to a trajectory, and **corner-case enhancement** for special single-step cases such as closing pop-ups, waiting, backing out, or terminating tasks. The resulting supervision signals comprise ground-truth action labels, ground-truth bounding boxes, reconstructed reasoning traces, high-level action primitives, exact-match action rewards, and grounding rewards based on overlap and center-point correctness [2509.00531].

Post-training is organized as a **two-phase pipeline**: **Warm-up SFT** followed by **two-stage curriculum GRPO**. Warm-up SFT teaches output format and basic GUI-agent behavior so that GRPO does not begin from sparse rewards alone. The GRPO stage first trains grounding directly, then reuses the Grounder as a reward model for the Decider. For the Grounder, the reward is composed of an IoU term and a center-point term: if the predicted box has sufficient overlap with the ground truth, it receives reward \(\alpha\); if the predicted box center lies inside the ground-truth box, it receives reward \(1-\alpha\); and the final reward is the sum of the two. For the Decider’s non-click actions, the reward is exact-match binary reward. For click actions, the Decider outputs a target-element description, the Grounder maps that description to a box, and the reward is then computed using the Grounder’s evaluation, specifically \(R_{\mathrm{center}}\). This makes the Grounder a practical supervisory signal for high-level click reasoning rather than merely a downstream executor [2509.00531].

## 4. Planning, memory, and control abstractions

A recurring methodological theme across the MobiMind lineage is that mobile control is treated as structured sequential reasoning rather than flat action prediction. In **MobileAgent**, the most distinctive contribution was the integration of **SOP (Standard Operating Procedure)** information into in-context learning. The paper contrasts this with output-side plan prompting: a “plan” asks the model to generate subtasks during inference, whereas “SOP” moves that structure to the input side so that the model is guided by a standardized operational pipeline before producing the next action. The formal statement is
\[
H(Y \mid X, Z) \leq H(Y \mid X),
\]
where \(X\) is the input prompt, \(Y\) is the instruction/action output, and \(Z\) is the SOP representation. The intended interpretation is that conditioning on SOP reduces uncertainty about the correct action [2401.04124].

This distinction is tightly connected to the empirical observation that mobile action data are exploratory, redundant, and highly variable. On AitW, the same instruction was reported to correspond on average to **29 different operation pipelines**, which made direct plan prediction unstable. The SOP formulation therefore abstracts common task structure into input-side subtasks and their finished/unfinished states rather than forcing the model to emit a long plan sequence during inference. The same work also defined a richer action-output space than simple click prediction: action generation may decide that the task is complete, impossible, or requires a structured confirmation message for the user [2401.04124].

**Mobile-Agent-E** extends this control abstraction with persistent memory and explicit reflection. Its long-term memory contains **Tips**, defined as general guidance and lessons learned from previous trial-and-error experiences, and **Shortcuts**, defined as reusable, executable sequences of atomic operations tailored for recurring subroutines. The Manager reasons at a coarse strategic level and is intentionally not conditioned on the Perceptor’s fine-grained outputs; the Operator chooses the next action from query, screenshot, perception result, plan, notes, recent action/error history, and long-term memory; the Action Reflector classifies outcomes as successful or partially successful, wrong-page failures, or no-change failures; and the Notetaker aggregates task-relevant facts such as prices, phone numbers, reviews, or item details [2501.11733].

At the system level, these designs converge on a common view of mobile control: planning, action selection, verification, and memory update are distinct computational functions. This suggests that “mobile intelligence” in the MobiMind sense is better characterized as a closed control loop with explicit intermediate state than as a single multimodal forward pass. A related misconception is that more explicit planning or more verbose reasoning is always beneficial. The MobileAgent results contradict that simplification: a naïve plan can hurt performance when the same instruction admits many valid pipelines, whereas input-side SOP guidance improves stability [2401.04124].

## 5. Acceleration, edge-cloud collaboration, and deployment regimes

The MobiMind-series is not only a model family but also the core of a broader systems stack. In MobiAgent, **AgentRR** accelerates execution by reusing past execution prefixes when a new task resembles a previously seen one. It introduces an **ActTree** and a latent memory model trained from traces generated by the agent itself. The series’ outputs are reused hierarchically: the Planner contributes high-level experiences, the Decider provides action primitives, and the Grounder contributes concrete coordinates. This makes MobiMind compatible with record-replay acceleration rather than requiring every step to be recomputed from scratch [2509.00531].

A parallel line of work addresses the same practical objective through edge-cloud partitioning. **EcoAgent** uses a cloud-based **Planning Agent** with edge-based **Execution Agent** and **Observation Agent** in a closed-loop collaboration. Its **Pre-Understanding Module** converts raw screens into concise textual descriptions before cloud transmission. The reported compression is from **over 1400 tokens per image** to **about 50–150 tokens**, with memory storing the resulting textual screen history for later reflection and replanning [2505.05440]. This is conceptually close to the MobiMind emphasis on separating high-level reasoning from low-level interaction, but it places the boundary across cloud and device rather than across three co-resident models.

**LightAgent** formalizes a different edge-cloud strategy around a compact on-device MLLM plus escalation to a stronger cloud model only when runtime monitoring indicates difficulty. The base model is **Qwen2.5-VL-3B**, improved by **SFT followed by GRPO**, and its long-reasoning mechanism compresses each historical step into a compact textual state assessment rather than retaining screenshots indefinitely. The state is updated as \(h_{t+1}=h_t\circ a_t\), enabling horizons of roughly **10–20 steps** under tight resource limits. The required output format contains the three blocks `<REASONING>`, `<STATE_ASSESSMENT>`, and `<CALLED_FUNCTION>` [2510.22009]. A plausible implication is that MobiMind-style modularization and LightAgent-style history compression address the same bottleneck from two different angles: the former structurally separates functions, while the latter compresses the sequential state passed through those functions.

At the high-integration end of the design space, **AppCopilot** presents a **multimodal, multi-agent, general-purpose on-device assistant** with a model layer, a reasoning/control layer, and an execution layer. It combines bilingual multimodal foundation modeling, **hierarchical task planning** via DAG decomposition, multi-agent decision fusion, personalization memory, experience replay, function calling, and profiling-driven optimization, with an **8B backbone model** chosen as a deployment “sweet spot” [2509.02444]. **X-OmniClaw** pushes the same systems logic toward an edge-native personal assistant architecture with **Omni Perception**, **Omni Memory**, and **Omni Action**, plus **Behavior Cloning and Trajectory Replay** for reusable skills [2605.05765]. These systems are not identical to the MobiMind series, but they illustrate the broader architectural environment in which the series operates.

## 6. Evaluation, empirical profile, and unresolved issues

The MobiMind-series is evaluated inside **MobiFlow**, which uses **DAG-based task definitions**, **milestone events**, **multi-level validation**, and **online and offline traces**. The paper reports that the combination of **MobiMind-Decider-7B** and **MobiMind-Grounder-3B** achieves the **best performance on MobiFlow** among the compared systems, including **GPT-5**, **Gemini-2.5 Pro**, and **UI-TARS-1.5-7B**. The reported qualitative advantages are stronger performance on complex tasks such as shopping and food delivery, better task understanding, decomposition, instruction following, exception handling, and task termination. On termination specifically, the paper states that **GPT failed to terminate properly in 11 app categories**, **Gemini failed in 3**, and **MobiAgent terminated correctly across all evaluated scenarios**. At the system level, AgentRR reports an **action replay rate of 30%–60% under uniform task distribution**, **60%–85% under power-law distribution**, **replay correctness exceeding 99%**, and **2–3× latency improvement in complex scenarios** [2509.00531].

The precursor **MobileAgent** established a strong benchmark reference point on **AitW**, described as a dataset with **715,000 episodes** and **30,000 unique instructions**. The SOP-based model reported **66.92% overall performance**, with the same inference time as the base Llama 2 system at **0.071 s/n**, while **Llama 2 + plan + state** reported **0.123 s/n**. The paper further states that **Llama 2 + SOP** improves over the prior best-performing model in the comparison set by **1.49%**, whereas naïve plan prompting degrades performance relative to the base model [2401.04124]. This directly supports the claim that input-side operational structure can improve mobile control without increasing inference-time output length.

For long-horizon mobile intelligence, **Mobile-Agent-E** introduced **Mobile-Eval-E**, a benchmark with **25 tasks**, **19 multi-app tasks**, **15 apps**, and an average of **14.56 expected operations per task**. Using **GPT-4o** as the backbone, the system reported **75.1 Satisfaction Score**, compared with **53.0** for **Mobile-Agent-v2**; **Action Accuracy** improved from **73.2** to **85.9**, **Reflection Accuracy** from **96.7** to **97.4**, and **Termination Error** decreased from **52.0** to **32.0**. With self-evolution enabled, **Mobile-Agent-E + Evo** reached **86.9 SS**, **90.4 AA**, **97.8 RA**, and **12.0 TE** [2501.11733]. These numbers show that persistent memory and reusable procedures can materially alter both quality and efficiency in long-horizon settings.

Edge-cloud systems expose a different empirical tradeoff. On **AndroidWorld**, **EcoAgent (OS-Atlas)** reported **27.57% Success Rate**, compared with **28.44%** for **M3A**, but with only **1.53 Average LLM Calls** and **3,240 Average LLM Tokens**, versus **13.39** calls and **87,469** tokens for M3A [2505.05440]. On **AndroidLab**, full **LightAgent** with **Gemini-2.5-Pro** reached **47.1% success rate**, close to the cloud model alone at **56.5%**, while the on-device model alone reached **15.2%**; the framework reduced cloud calls by **roughly 10%**, although the cloud side still performed **about 65% of total steps** [2510.22009]. These results support a second correction to a common misconception: small on-device models are not yet sufficient for complex mobile tasks on their own, and current practical systems still rely on selective cloud assistance.

The broader GUI-agent expansion represented by **GUI-Owl-1.5** further clarifies the scaling horizon of this family. The reported results include **56.5 on OSWorld**, **71.6 on AndroidWorld**, **48.4 on WebArena**, **80.3 on ScreenSpotPro**, **47.6 on OSWorld-MCP**, **46.8 on MobileWorld**, and **75.5 on GUI-Knowledge Bench** [2602.16855]. This suggests that the MobiMind-series should be understood not as an isolated model trio, but as one instantiation of a more general research program: decomposed mobile control, explicit reasoning and memory, and increasingly unified deployment across mobile, desktop, browser, tool use, and cloud-edge collaboration.

Several limitations remain consistent across the series and its relatives. Benchmark scores are environment-dependent; offline replay can cause false negatives when a successful new trajectory diverges from a recorded one; UI parsing and grounding remain imperfect under missing XML, dynamic UIs, or UI drift; and Planner training is less fully specified than Decider and Grounder training in the available MobiAgent description [2509.00531]. Across adjacent systems, another recurring limit is that heuristic switching or risk-sensitive orchestration has not yet been replaced by a fully learned end-to-end policy [2510.22009]. The resulting picture is not of a solved problem, but of a maturing architecture class in which modularity, structured supervision, memory, and deployment-aware orchestration have become the central technical levers.

Source: https://www.emergentmind.com/topics/mobimind-series-agent-models