SPlanner: Modular Planner-Centric Framework

• SPlanner is a planner-centered system that explicitly isolates high-level planning from perception and execution using EFSMs and LLM-based solvers.
• It employs graph search and planner-only reinforcement learning to optimize sequential decision-making in both mobile GUI and multi-agent frameworks.
• The framework enhances stability and interpretability across applications such as mobile automation, long-horizon planning, and autonomous driving.

Searching arXiv for papers on “SPlanner” and closely related usages to ground the encyclopedia entry. SPlanner is a term used in multiple research contexts to denote planner-centered systems that impose explicit structure on sequential decision making. In the mobile GUI literature, SPlanner specifically refers to a plug-and-play planning module that models mobile applications with Extended Finite State Machines (EFSMs) and converts user instructions into concise execution plans for a vision-LLM executor (Mo et al., 20 May 2025). In broader agentic automation research, an SPlanner-style system denotes a planner-centric multi-agent architecture in which planning is treated as the dominant bottleneck in long-horizon tasks, with acting and memory delegated to smaller modules (Wu et al., 4 May 2026). In autonomous driving, the related PLAN-S framework serves as a planner-facing bridge from latent world models to a style-conditioned semantic cost map, and is explicitly discussed as a component that a world-model-based “SPlanner” could adopt (Qiu et al., 4 Jun 2026). Across these usages, the unifying theme is the elevation of planning into a distinct computational object rather than leaving it entangled with perception or low-level execution.

1. Terminological scope and research contexts

The name SPlanner is used most concretely in the paper "Building a Stable Planner: An Extended Finite State Machine Based Planning Module for Mobile GUI Agent" (Mo et al., 20 May 2025). There it denotes a planning module for mobile GUI agents that sits between the user instruction and the VLM executor, producing a natural-language plan from symbolic app models. The stated purpose is to address task planning instability in mobile device control, especially the tendency of VLMs to become “lost” during long-horizon interaction (Mo et al., 20 May 2025).

A second usage is architectural rather than nominative. "Planner Matters! An Efficient and Unbalanced Multi-agent Collaboration Framework for Long-horizon Planning" argues for an SPlanner-style system built around the idea that, in long-horizon tasks, high-level planning is the main bottleneck. It decomposes automation into planner, actor, and memory manager, but concentrates model capacity and reinforcement learning almost entirely on the planner (Wu et al., 4 May 2026). In that work, “SPlanner-style” refers to a planner-first systems design rather than a single named product.

A third nearby usage appears in autonomous driving. "PLAN-S: Bridging Planning with Latent Style Dynamics for Autonomous Driving World Models" is not named SPlanner, but its discussion explicitly states that, assuming SPlanner denotes a style-aware planning architecture over world models, PLAN-S provides a concrete blueprint (Qiu et al., 4 Jun 2026). Here the planner interface is a four-channel semantic cost map that exposes risk, drivability, and style-conditioned spatial preferences to downstream planners.

This suggests that SPlanner has become a family resemblance term rather than a single canonical architecture. A plausible implication is that the literature uses it for systems in which planning is surfaced as an explicit, inspectable, and separately optimizable layer.

2. EFSM-based SPlanner for mobile GUI agents

In the mobile GUI setting, SPlanner is defined as a plug-and-play planning module for agents that interact with smartphones or emulators using screenshots and low-level actions such as tap, swipe, and type (Mo et al., 20 May 2025). The core claim is that pure VLM step-by-step planning is unstable because the model lacks deep app-usage knowledge, over-focuses on GUI elements with literal keyword matches, and can enter repeated loops or oscillate between screens (Mo et al., 20 May 2025).

The formal substrate is an Extended Finite State Machine for each application,

$\varepsilon = (S, E, A, V, T, s_0),$

where $S$ is a set of states corresponding to screens or pages, $E$ is a set of events described as natural-language GUI operation sequences, $A$ is a set of primary functions, $V$ is a set of internal variables, $T$ is a set of transitions, and $s_0$ is the initial state (Mo et al., 20 May 2025). Each transition is a 6-tuple

$(s, e, a, g(V), u(V), s') \in T,$

with source state, event, primary function, guard condition, update function, and target state (Mo et al., 20 May 2025).

This formulation encodes app control logic explicitly. States are screens such as a camera home page or settings page; events are natural-language operation descriptions; primary functions represent high-level app capabilities; and guards plus variable updates capture configuration-sensitive behavior such as whether video mode is enabled (Mo et al., 20 May 2025). Because events are already written in natural language, the symbolic path produced by the planner can later be polished into an executable textual plan.

All modeled applications form a set of EFSMs,

$$\mathcal{F} = \{ \varepsilon_1, \varepsilon_2, \cdots, \varepsilon_n \},$$

which acts as a structured knowledge base of app usage and control logic (Mo et al., 20 May 2025). The paper states that EFSMs are manually constructed prior to deployment, with a modeling cost of 1–2 hours per app and more for complex applications (Mo et al., 20 May 2025). This manual construction is both a strength and a limitation: it makes the planner stable and interpretable, but constrains coverage to modeled functionalities.

3. Planning pipeline and execution loop

The SPlanner workflow begins with instruction parsing. Given a user instruction $I$, an LLM maps it to the relevant app EFSMs and their target primary function sequences:

$S$0

For a single app, the target functions are written as

$S$1

SPlanner then runs a BFS-based solver over the EFSM to find a path that starts from the initial state, executes all target primary functions in order, and respects guards and updates (Mo et al., 20 May 2025).

The per-app path is a transition sequence

$S$2

with

$S$3

The full multi-app plan is

$S$4

The paper emphasizes that BFS returns the shortest path in number of transitions, which tends to minimize unnecessary navigation (Mo et al., 20 May 2025). If no feasible path exists, SPlanner returns a fallback textual error such as “No feasible execution path exists.” (Mo et al., 20 May 2025)

Once the symbolic path is found, a second LLM converts it into a concise, step-wise natural-language plan aligned with the original instruction. The executor VLM never sees the EFSM directly; instead, it receives the instruction, the polished plan, the current screenshot, and the action history, and produces the next GUI action in an iterative loop (Mo et al., 20 May 2025). The paper describes this as:

$S$5

where $S$6 is the original instruction, $S$7 the current screenshot, $S$8 the SPlanner-generated textual plan, and $S$9 the history (Mo et al., 20 May 2025).

The planner therefore handles symbolic logic and navigation, while the VLM handles perception and low-level action instantiation. This separation of concerns is central to the method’s stability. The system does not perform online replanning in the described version, and the authors identify incomplete executor adherence to the plan as a residual failure mode (Mo et al., 20 May 2025).

4. Planner-centric multi-agent SPlanner-style systems

A different but related line of work generalizes SPlanner into a planner-centric multi-agent design for long-horizon automation across web navigation, OS control, and tool use (Wu et al., 4 May 2026). The decomposition consists of three modules: planner, actor, and memory manager. At each step, the memory manager retrieves or updates memory,

$E$0

the planner produces a plan and subgoal,

$E$1

and the actor emits the concrete action,

$E$2

Memory is optionally updated by

$E$3

This loop continues until a Stop action is issued or a step limit is reached (Wu et al., 4 May 2026).

The planner is treated as the SPlanner core. Its responsibilities include interpreting the task, generating an initial plan, updating that plan as the environment changes, selecting tools or UI affordances, and making termination decisions. Its policy is written as

$E$4

In practice, $E$5 is structured text containing an updated global plan and a single explicit subgoal for the actor (Wu et al., 4 May 2026).

The key empirical claim is that scaling the planner contributes most of the system’s performance lift. On WebVoyager with Qwen2.5-VL-7B, a single-model agent attains 12.3% overall success, +Planner+Actor reaches 40.6%, and +Planner+Actor+Memory reaches 44.7% (Wu et al., 4 May 2026). When broader benchmarks are aggregated, the baseline single model reaches 12.5%, the multi-agent system without RL reaches 27.4%, and multi-agent + planner RL reaches 35.1% (Wu et al., 4 May 2026).

The compute-allocation analysis fits the scaling law

$E$6

where $E$7 is parameters in billions and $E$8 is task success rate. The reported slopes are Planner: $E$9, All modules jointly: $A$0, Actor: $A$1, and Memory manager: $A$2 (Wu et al., 4 May 2026). The interpretation given is that scaling the planner almost matches the gains of scaling the entire system, whereas execution and memory saturate much earlier.

This work therefore treats SPlanner not as a fixed symbolic planner, but as a system design principle: make the planner the central, large, and trainable component; keep actor and memory smaller and possibly frozen; and focus reinforcement learning on the planner alone (Wu et al., 4 May 2026).

5. Training regimes and planner optimization

The mobile GUI SPlanner paper is largely symbolic and prompt-based: EFSMs are manually modeled, instruction parsing and path polishing are LLM-mediated, and the executor VLM is off-the-shelf with no fine-tuning requirement (Mo et al., 20 May 2025). Its training emphasis lies more in structured knowledge engineering than in end-to-end optimization.

By contrast, the planner-centric long-horizon framework introduces explicit planner-only reinforcement learning. A rollout is defined as

$A$3

and the objective is

$A$4

The actor and memory manager remain fixed while only the planner policy is updated (Wu et al., 4 May 2026).

Reward is provided by a VLM-as-judge at the trajectory level. After execution, the evaluator receives the task, screenshots over time, plans, and final answer, and assigns a scalar reward

$A$5

with $A$6 failure, $A$7 partial, and $A$8 success. To stabilize noise, the evaluation is repeated $A$9 times and the final reward is the mode:

$V$0

This reward is broadcast to all planning steps (Wu et al., 4 May 2026).

The optimization algorithm is Group Relative Policy Optimization (GRPO). For experience tuple

$V$1

the objective is

$V$2

with group-normalized advantage

$V$3

The authors report that planner-only RL gives the best results and most stable reward learning, while actor-only RL has limited impact and joint planner+actor RL is less stable and underperforms planner-only training (Wu et al., 4 May 2026).

This suggests a sharp divergence between two SPlanner traditions. One uses manually curated symbolic app models and graph search to stabilize execution. The other uses modular decomposition plus planner-only RL to stabilize long-horizon agent reasoning. The shared principle is that planning should be isolated and improved directly, rather than treated as an incidental side effect of a monolithic policy.

6. Style-aware and planner-facing world-model interfaces

The autonomous driving paper PLAN-S is relevant because it frames a planner-facing interface that the authors explicitly connect to an “SPlanner” system (Qiu et al., 4 Jun 2026). In that framework, a latent world model produces a BEV latent $V$4, which is transformed by a bridge module into a style-conditioned semantic cost map

$V$5

The planner then operates on both the latent and the cost map:

$V$6

The four channels are Dynamic obstacles, Off-road, Static obstacles, and Drivability (Qiu et al., 4 Jun 2026).

Style conditioning is implemented with dual AdaFiLM, which modulates disjoint channel groups of the BEV latent using ego state and driving style code. The decoder outputs cost-map logits $V$7, transformed into

$V$8

The key point is that risk and preference become explicit planner-facing quantities rather than remaining entangled inside opaque latent features (Qiu et al., 4 Jun 2026).

The host planner can consume this map in two ways. For regression planners, PLAN-S uses attention-level fusion,

$V$9

followed by cost-gated deformable attention (Qiu et al., 4 Jun 2026). For anchor-score planners, it samples logit costs along candidate anchors,

$T$0

and fuses them into the reward:

$T$1

This modifies trajectory selection before hard commitment (Qiu et al., 4 Jun 2026).

Quantitatively, on nuScenes, PLAN-S reduces average L2 to 0.55 m and reduces 3 s collision rate from 0.43% to 0.25%, which the paper describes as approximately a 42% relative reduction (Qiu et al., 4 Jun 2026). On NAVSIM, the rule-cost variant reaches 89.4 PDMS, while the learned-cost variant gives complementary gains on hard scenes (Qiu et al., 4 Jun 2026).

For SPlanner as a general concept, this paper is important because it defines a semantic contract between world model and planner. Instead of letting the planner read only entangled latent features, the system exposes an interpretable spatial structure that encodes safety and style. A plausible implication is that future SPlanner systems in embodied domains may standardize on planner-facing abstractions of this kind.

7. Empirical performance, limitations, and broader significance

The most direct benchmark evidence for named SPlanner comes from mobile GUI agents. On AndroidWorld, the paper evaluates 116 tasks across 20 real-world apps and reports that Qwen2.5-VL-72B without planning achieves 35.0% task success, whereas SPlanner + Qwen2.5-VL-72B achieves 63.8%, a 28.8 percentage point improvement (Mo et al., 20 May 2025). It also reports competitiveness with specialized baselines: AgentS2 at 54.3%, V-Droid at 59.5%, and UI-TARS1.5 at 64.2%, with SPlanner slightly lower than UI-TARS1.5 by 0.4 points but operating as a plug-and-play module without fine-tuning (Mo et al., 20 May 2025).

The paper attributes residual failures to three sources: the VLM not fully following the plan, visual understanding limitations, and plan granularity limitations for context-dependent tasks (Mo et al., 20 May 2025). It also identifies manual EFSM construction, modeling coverage, natural-language matching, absence of online replanning, and dynamic or personalized UIs as important constraints (Mo et al., 20 May 2025).

The planner-centric long-horizon framework shows that SPlanner-style decomposition generalizes beyond mobile devices. On OSWorld, Qwen3-VL-8B baseline reaches 18.1% overall and +Multi-agent reaches 22.1% (Wu et al., 4 May 2026). On MCPBench, Qwen2.5-VL-7B baseline completion is 4.72, while the Planner+Actor+Memory variant reaches approximately 6.8–6.9, with execution fidelity rising from approximately 0.5–0.6 to approximately 0.7–0.9 (Wu et al., 4 May 2026). On MMInA, multi-agent RL with Qwen3-VL-8B achieves approximately 51% success (Wu et al., 4 May 2026). These findings support the broader claim that explicit planning modules are beneficial across digital environments.

Across the surveyed literature, several limitations recur. Symbolic SPlanner depends on manual knowledge engineering and lacks online replanning (Mo et al., 20 May 2025). Planner-centric RL depends on the quality of the VLM-as-judge, uses coarse trajectory-level credit assignment, and assumes actor and memory are already “good enough” (Wu et al., 4 May 2026). PLAN-S depends on host-specific interfaces and auxiliary supervision, and its style effects are evaluated partly qualitatively because standard benchmarks lack explicit style labels (Qiu et al., 4 Jun 2026).

Taken together, the literature presents SPlanner as a research program centered on explicit planning representations, modular planner–executor separation, and planner-facing interfaces. In one branch this takes the form of EFSM-guided mobile automation; in another it becomes planner-centric multi-agent RL for long-horizon digital tasks; in a third it appears as style-conditioned semantic cost maps for driving world models. The common conclusion is that planning performance improves when high-level structure is modeled directly, inspected explicitly, and optimized separately from low-level control (Mo et al., 20 May 2025, Wu et al., 4 May 2026, Qiu et al., 4 Jun 2026).