---
title: 'SPlanner: Modular Planner-Centric Framework'
url: https://www.emergentmind.com/topics/splanner
type: topic
---

# SPlanner: Modular Planner-Centric Framework

Searching arXiv for recent 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-language model executor [2505.14141]. 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 [2605.02168]. 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 [2606.06014]. 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"** [2505.14141]. 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 [2505.14141].

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 [2605.02168]. 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 [2606.06014]. 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 [2505.14141]. 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 [2505.14141].

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 [2505.14141]. 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 [2505.14141].

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 [2505.14141]. 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 [2505.14141]. 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 [2505.14141]. 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:
$$
LLM(I) \to \Big( (\varepsilon_1, \varepsilon_2, \cdots, \varepsilon_j),\ (A^T_1, A^T_2, \cdots, A^T_j) \Big).
$$
For a single app, the target functions are written as
$$
A^T = (a_1, a_2, \cdots, a_k) \subseteq A^j.
$$
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 [2505.14141].

The per-app path is a transition sequence
$$
p = (t_1, t_2, \cdots, t_m),
$$
with
$$
t_i = (s_{i-1}, e_i, a_i, g_i(V), u_i(V), s_i) \in T^j.
$$
The full multi-app plan is
$$
P = (p_1, p_2, \cdots, p_j).
$$
The paper emphasizes that BFS returns the shortest path in number of transitions, which tends to minimize unnecessary navigation [2505.14141]. If no feasible path exists, SPlanner returns a fallback textual error such as “No feasible execution path exists.” [2505.14141]

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 [2505.14141]. The paper describes this as:
$$
O_i = VLM(I, S_i, Plan, H_i),
$$
where \(I\) is the original instruction, \(S_i\) the current screenshot, \(Plan\) the SPlanner-generated textual plan, and \(H_i\) the history [2505.14141].

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 [2505.14141].

## 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 [2605.02168]. The decomposition consists of three modules: planner, actor, and memory manager. At each step, the memory manager retrieves or updates memory,
$$
\mathcal{M}_t = \text{MemoryManager}(\mathcal{Q}, \mathcal{O}_{t-k:t}, \mathcal{A}_{t-k:t}),
$$
the planner produces a plan and subgoal,
$$
\mathcal{P}_t = \text{Planner}(\mathcal{Q}, \mathcal{O}_t, \mathcal{M}_t),
$$
and the actor emits the concrete action,
$$
\mathcal{A}_t = \text{Actor}(\mathcal{Q}, \mathcal{P}_t, \mathcal{O}_t, \mathcal{A}).
$$
Memory is optionally updated by
$$
\mathcal{M}_{t+1} = (1 - \delta_t)\mathcal{M}_t + \delta_t \mathcal{M}_t'.
$$
This loop continues until a Stop action is issued or a step limit is reached [2605.02168].

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
$$
\mathcal{P}_t \sim \pi_{\theta}^{\text{plan}}(\mathcal{P}_t \mid \mathcal{Q}, \mathcal{O}_t, \mathcal{M}_t).
$$
In practice, \(\mathcal{P}_t\) is structured text containing an updated global plan and a single explicit subgoal for the actor [2605.02168].

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%** [2605.02168]. 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%** [2605.02168].

The compute-allocation analysis fits the scaling law
$$
y = \alpha \log(x) + \beta,
$$
where \(x\) is parameters in billions and \(y\) is task success rate. The reported slopes are **Planner: \(\alpha = 16.0\)**, **All modules jointly: \(\alpha = 15.6\)**, **Actor: \(\alpha = 12.0\)**, and **Memory manager: \(\alpha = 5.6\)** [2605.02168]. 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 [2605.02168].

## 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 [2505.14141]. 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
$$
\tau = (\mathcal{Q}, \mathcal{O}_1, \mathcal{P}_1, \mathcal{A}_1, \mathcal{O}_2, \dots, \mathcal{O}_{T}, \mathcal{P}_T, \mathcal{A}_T),
$$
and the objective is
$$
\max_{\theta} \mathbb{E}_{\tau \sim \pi_\theta^{\text{plan}, \phi, \psi}}[R(\tau)].
$$
The actor and memory manager remain fixed while only the planner policy is updated [2605.02168].

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
$$
r_i \in \{1, 3, 5\},
$$
with \(1=\) failure, \(3=\) partial, and \(5=\) success. To stabilize noise, the evaluation is repeated \(K\) times and the final reward is the mode:
$$
r = \text{mode}(\{r_i\}_{i=1}^K).
$$
This reward is broadcast to all planning steps [2605.02168].

The optimization algorithm is **Group Relative Policy Optimization (GRPO)**. For experience tuple
$$
\mathbf{e}_i = (\mathcal{Q}, \mathcal{O}_i, \mathcal{M}_i, \mathcal{P}_i),
$$
the objective is
$$
J(\theta) = \mathbb{E}_{\mathbf{e}_i \sim \mathcal{E}}\left[ \rho_i A_i - \beta D_{\text{KL}}[\pi_\theta \;\|\; \pi_{\text{ref}}] \right],
$$
with group-normalized advantage
$$
A_i = \frac{r(\mathbf{e}_i) - \mathrm{mean}(\{r(\mathbf{e}_k)\}_{k=1}^G)}{\mathrm{std}(\{r(\mathbf{e}_k)\}_{k=1}^G)}.
$$
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 [2605.02168].

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 [2606.06014]. In that framework, a latent world model produces a BEV latent \(F\), which is transformed by a bridge module into a style-conditioned semantic cost map
$$
M = \mathcal{C}(F, s, e) \in \mathbb{R}^{K \times H \times W}, \quad K=4.
$$
The planner then operates on both the latent and the cost map:
$$
\tau = \tilde{\pi}_\theta(F, M, e, \mathrm{cmd}).
$$
The four channels are **Dynamic obstacles**, **Off-road**, **Static obstacles**, and **Drivability** [2606.06014].

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 \(\hat{M}\), transformed into
$$
M = \sigma(\hat{M}) \in [0,1]^{4\times H \times W}.
$$
The key point is that risk and preference become explicit planner-facing quantities rather than remaining entangled inside opaque latent features [2606.06014].

The host planner can consume this map in two ways. For **regression planners**, PLAN-S uses attention-level fusion,
$$
Q' = Q + \mathrm{CrossAttn}\bigl( Q,\, \phi_M(\mathrm{flatten}(M)) + \mathrm{PE} \bigr),
$$
followed by cost-gated deformable attention [2606.06014]. For **anchor-score planners**, it samples logit costs along candidate anchors,
$$
c^{(a)} = \frac{1}{T} \sum_{t=1}^{T} \sum_{k=1}^{K} w_k\,\hat{M}_k(\tau^{(a)}_t),
$$
and fuses them into the reward:
$$
r_{\mathrm{fused}}^{(a)} = r^{(a)} + \lambda_{\mathrm{cost}}\cdot \log\bigl(1 - \sigma(c^{(a)})\bigr).
$$
This modifies trajectory selection before hard commitment [2606.06014].

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** [2606.06014]. On NAVSIM, the **rule-cost** variant reaches **89.4 PDMS**, while the **learned-cost** variant gives complementary gains on hard scenes [2606.06014].

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 [2505.14141]. 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 [2505.14141].

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 [2505.14141]. It also identifies manual EFSM construction, modeling coverage, natural-language matching, absence of online replanning, and dynamic or personalized UIs as important constraints [2505.14141].

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%** [2605.02168]. 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** [2605.02168]. On MMInA, multi-agent RL with **Qwen3-VL-8B** achieves approximately **51%** success [2605.02168]. 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 [2505.14141]. 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” [2605.02168]. 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 [2606.06014].

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 [2505.14141][2605.02168][2606.06014].

Source: https://www.emergentmind.com/topics/splanner