MobiMem: Memory-Centric LLM Agent System

• MobiMem is a memory-centric LLM agent system that leverages Profile, Experience, and Action memories to enable self-evolution without retraining.
• Its architecture integrates specialized memory primitives with OS-inspired scheduling and record-and-replay services to enhance personalization, task success, and efficiency.
• Empirical evaluations show up to 50% improvement in task success and up to 9x latency reduction on mobile devices compared to traditional model-centric approaches.

Searching arXiv for papers on “MOBIMEM” and closely related terms to ground the article in the current literature. First, I’ll look for the exact term “MOBIMEM” / “MobiMem”. Then I’ll check related possible confusions in older mobile-systems literature, including “MBMP” and “mobility management framework”. MOBIMEM, spelled “MobiMem” in the paper, is a memory-centric agent system for mobile and desktop automation that is designed to let LLM-based agents self-evolve after deployment without retraining or fine-tuning the underlying model. Its central thesis is that personalization, capability expansion, and efficiency gains can be shifted from model weights into external memory and runtime orchestration. The system combines three specialized memory primitives—Profile Memory, Experience Memory, and Action Memory—with OS-inspired services including a scheduler, an agent record-and-replay mechanism, and context-aware exception handling. In the reported evaluation on AndroidWorld and top-50 apps, it achieves 83.1% profile alignment with 23.83 ms retrieval time, improves task success rates by up to 50.3%, and reduces end-to-end latency by up to 9x on mobile devices (Liu et al., 15 Dec 2025).

1. Terminological scope and research setting

In current arXiv usage, MOBIMEM refers to the memory-centric agent system introduced in “Beyond Training: Enabling Self-Evolution of Agents with MOBIMEM” (Liu et al., 15 Dec 2025). The name should be distinguished from two nearby but different strands of earlier mobile-systems literature. “Multi-Hop Bandwidth Management Protocol” defines MBMP, an admission-control protocol for single-channel, multi-hop mobile ad hoc networks; the protocol name is MBMP rather than MOBIMEM (Pattanayak et al., 2010). “Mobility Management Framework” is a technology-neutral analytical framework for signaling, processing, and air-interface cost trade-offs in heterogeneous mobility management, again conceptually adjacent but terminologically distinct (0810.0394).

The MobiMem paper is situated in the literature on LLM GUI agents for phones and PCs. Its problem statement is that prevailing model-centric agent architectures make post-deployment evolution depend on retraining, RL, or continual fine-tuning. The paper characterizes this dependency as computationally heavy, especially at per-user scale and on mobile devices, and as entangled with an inherent accuracy-latency trade-off: larger multimodal models improve reasoning but are slower, whereas smaller models are faster but brittle in complex GUI flows (Liu et al., 15 Dec 2025).

A common misconception is that MobiMem is merely a retrieval layer attached to an existing GUI agent. The paper instead presents it as a broader execution substrate: memory is specialized by function, and runtime services are explicitly responsible for scheduling, safe replay, and recovery from interruptions. This suggests that the system’s novelty lies not in retrieval alone but in the coupling of memory design with execution control.

2. Three-layer architecture and execution model

MobiMem uses a three-layer architecture. The top layer is a Multi-Agent Layer with four specialized agents: Profile Updater, Experience Generator, Task Rewriter, and Operator. The middle layer is an Agent Memory Layer comprising Profile Memory, Experience Memory, and Action Memory. The bottom layer is an OS Integration Layer with Agent Scheduler, AgentRR, Agent Exception Handler, and OS-level perception and execution APIs such as screenshots, UI hierarchy, and input events (Liu et al., 15 Dec 2025).

The execution flow is organized as a memory-driven control loop. A user issues a natural language command. The scheduler retrieves user profile context from Profile Memory and experience templates from Experience Memory in parallel. Task Rewriter combines the template, profile, and query into a concrete plan. Operator executes the plan, reusing actions from Action Memory through AgentRR where possible and invoking the LLM when reuse is not possible. After execution, Experience Generator updates templates, Action Memory updates ActTree or ActChain, and Profile Updater updates DisGraph based on behavior (Liu et al., 15 Dec 2025).

The paper gives a formalization flavor rather than a single unified model. Profile retrieval is described as embedding-based seed selection followed by BFS over a graph under a token budget: $$\text{start\_nodes} = \operatorname{TopK}_{v \in V} \bigl(\cos(\mathbf{e}(q), \mathbf{e}(v))\bigr).$$ Template retrieval is likewise formulated as nearest-neighbor search over textual keys: $$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$ These serving-time operations are intended to be quick and LLM-free. This suggests that MobiMem’s systems contribution depends on moving high-frequency online decisions away from heavyweight generation and toward structured memory access.

3. Specialized memory primitives

Profile Memory stores structured long-term user information, including facts, preferences, and behavior patterns. Its underlying data structure is DisGraph, a distance-graph with concept nodes $C$, entity nodes $E$, and edges restricted to concept-concept and concept-entity relations: $$G = (V, E), \quad V = C \cup E, \quad E \subseteq (C \times C) \cup (C \times E).$$ The graph uses “semantic-free” edges, with semantics located in nodes rather than edges; relevance is mediated by hop distance,

$$d(u, v) = \text{length of shortest path from } u \text{ to } v.$$

When new observations arrive, the system retrieves relevant nodes by embeddings, sends those nodes plus local neighbors and raw observations to Profile Updater in a single LLM call, receives structured edits, and applies them atomically. Retrieval for a new task is LLM-free: embedding search selects top-$k$ seeds, BFS expands each seed up to depth $D$, and a round-robin procedure fills a token budget $B$ with entity descriptions. If a concept accumulates too many entities, and $|E_c| > \tau$, the system splits it into sub-concepts such as Business Travel and Leisure Travel to improve retrieval precision (Liu et al., 15 Dec 2025).

Experience Memory stores reusable execution logic as multi-level templates indexed in a vector database. High-level templates represent abstract workflows across apps or major steps; low-level templates represent detailed step sequences tied to specific UIs. A template is represented conceptually as

$$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$0

where each step is either invariant or parameterized. Templates may be synthesized automatically from completed traces by Experience Generator or authored manually by developers. Retrieval uses the textual key $$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$1, and Task Rewriter fills the parameter slots for a new task. For cross-app tasks, Experience Memory models a workflow as a DAG,

$$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$2

whose nodes are subtasks and whose edges encode data dependencies (Liu et al., 15 Dec 2025).

Action Memory stores fine-grained interaction sequences between agent and GUI, including screenshots, UI trees, actions, and short local context. It has two forms. ActTree is a per-app prefix structure in which nodes are UI states and edges are actions; reuse is based on matching the current UI state $$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$3 to a stored node $$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$4 with a depth-dependent threshold,

$$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$5

ActChain is tied to an experience template and distinguishes invariant from variant steps. For a step $$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$6, reuse is defined as

$$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$7

Before replay, the system checks the UI hierarchy using resource ID, class name, text, and fuzzy matching. If replay is stale, the system falls back to the LLM and records the new trace to refresh Action Memory (Liu et al., 15 Dec 2025).

A useful interpretation is that the three memories target distinct failure modes of model-centric agents. Profile Memory addresses underspecified intent and personalization; Experience Memory addresses task-level generalization; Action Memory addresses repeated low-level interaction cost.

4. OS-inspired runtime services

Agent Scheduler orchestrates both planning and execution. In the planning phase it retrieves profile context and templates in parallel. In the execution phase it exploits parallelism over a DAG of subtasks. A subtask $$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$8 is ready precisely when all predecessors have finished: $$T^\ast = \arg\max_{T_i} \cos(\mathbf{e}(q), \mathbf{e}(k_i)).$$9 The paper distinguishes coarse-grained parallelism, where independent subtasks run concurrently, from fine-grained parallelism, where steps of a downstream app that do not depend on upstream outputs are overlapped with upstream work. In the example of querying prices in two shopping apps and then sending a summary in a social app, serial execution takes 48.27 s, coarse-grained scheduling reduces this to 37.65 s, and fine-grained scheduling reduces it further to 29.84 s (Liu et al., 15 Dec 2025).

AgentRR is an agent-level record-and-replay mechanism that underpins ActTree and ActChain. During recording, it intercepts agent-device interactions and stores screenshot, UI hierarchy, action type, action parameters, and links to the current task, experience template, and step index. For ActTree it creates or merges UI-state nodes and action-labeled edges into a shared prefix tree. For ActChain it aligns recorded step sequences with template steps, marks steps as invariant or variant, and stores mappings from $C$0 to action sequences. Replay is conditioned on semantic validity rather than bit-exact reproduction: $C$1 This makes replay best-effort with safety checks rather than blind reuse (Liu et al., 15 Dec 2025).

The Agent Exception Handler treats user interruptions and runtime exceptions as first-class events. It monitors for explicit commands such as “stop” or “pause” and for conflicting user UI actions. On detection, the scheduler suspends the agent thread and saves the current UI state, partial plan, execution state, and action history. After the user manually corrects or reissues instructions, the planner resumes from the updated state. Experience Generator then analyzes the divergence between the original plan and the corrected trajectory, distilling new or updated templates and possibly new profile entries (Liu et al., 15 Dec 2025).

These services make the system more than a static memory architecture. A plausible implication is that MobiMem treats agent adaptation as an operating-systems problem of coordination, replay, and recovery, rather than only a problem of model inference.

5. Empirical profile: personalization, capability, and efficiency

For personalization, the paper evaluates synthetic user profiles with 20 users, 500 historical tasks per user, and 30 ambiguous test tasks per user. Profile alignment is defined as

$C$2

On this benchmark, Vanilla RAG yields 66.4% alignment with 19.58 ms retrieval, GraphRAG yields 81.1% alignment with 6,676 ms retrieval, and MobiMem DisGraph yields 83.1% alignment with 23.83 ms retrieval. The paper reports this as 280× faster than GraphRAG, while retaining GraphRAG-level, and slightly better, alignment (Liu et al., 15 Dec 2025).

For capability, Experience Memory is evaluated on AndroidWorld, which the paper describes as 20 apps and 116 tasks, and on real-world ID/OOD tasks. Templates improve task success by +50.3% relative for UI-TARS-1.5-7B, +10.5% for GUI-Owl-7B, and about +21–22% for Gemini-2.5-Flash and Qwen3-VL-30B. On real-world tasks with UI-TARS-1.5-7B, the gain is 44.1% on OOD tasks and 22.0% on ID tasks. Storage overhead is reported as 116 templates and about 900 KB total, or 7.8 KB per template. In a cost comparison, fine-tuning uses about 100 examples, 4 person-hours, 0.25 GPU-hours, and reaches 58.5% accuracy; manual templates use about 5 examples, 0.2 person-hours, 0 GPU-hours, and reach 63.5% accuracy; synthesized templates use about 5 examples, 0 person-hours, 0.0027 GPU-hours, and reach 60.1% accuracy (Liu et al., 15 Dec 2025).

For efficiency, the paper evaluates 454 realistic tasks spanning email, tickets, food delivery, hotels, shopping, browser, media, and maps. ActTree achieves 37.5% average action reuse, ActChain plus LLM templates reaches 59.7%, and ActChain plus human templates reaches 77.3%. End-to-end latency improves from 14.1 s to 8.6 s for MobiMind-4B, from 14.7 s to 8.8 s for UI-TARS-1.5-7B, and from 38.0 s to 16.2 s for GUI-Owl-7B. On Snapdragon 8 Elite CPU-only hardware, latency without Action Memory is 153.2 s on average, and Action Memory yields 1.6×–9× speedup, bringing most tasks into the 10–50 s range. The memory overhead is reported as about 1.54 MB for about 6,000 cached actions (Liu et al., 15 Dec 2025).

For multi-app scheduling, fine-grained parallelism yields up to 1.98× speedup over serial execution across six multi-app categories, and coarse-grained scheduling yields up to 1.41×. These results support the paper’s broader claim that the memory stack and scheduler jointly improve not only model invocation cost but also overall workflow structure (Liu et al., 15 Dec 2025).

6. Relation to adjacent approaches, limitations, and distinctions

MobiMem is explicitly contrasted with model-centric approaches such as fine-tuning and RL, which the paper characterizes as difficult to apply per user or per long-tail task. It is also contrasted with generic RAG and GraphRAG systems. Classic RAG is described as fast but semantically noisy because it uses a flat vector store without structured relations. GraphRAG, Mem0, and A-MEM are described as more accurate but slower because update and retrieval require LLM calls. MobiMem’s DisGraph moves semantics to nodes and keeps edges as distance or membership relations, requiring one LLM call per update and zero LLM calls for retrieval (Liu et al., 15 Dec 2025).

The system is also positioned against multi-agent or memory-augmented frameworks such as LangChain, AutoGen, MetaGPT, MemGPT, Mem0, and A-MEM. The paper’s stated distinction is that those systems do not combine accurate and fast preference retrieval, reusable execution templates, state-indexed GUI action reuse, and OS-like scheduling and exception handling in a single agent architecture (Liu et al., 15 Dec 2025).

Several limitations are identified. DisGraph traversal remains cheap in practice, around 0.15–0.35 ms even at 100k nodes, but vector database search grows linearly and reaches 1.29 s from 100 to 100k nodes. Automatically synthesized templates are noisier than human-crafted ones, which is reflected in lower reuse rates. The paper does not specify sophisticated eviction, compaction, or summarization policies for growing memories. Safety checks are based on UI matching and fuzzy matching, but the discussion notes that stronger value-difference checks and secure sandboxing may be needed for risky actions such as payments or data deletion. Although the architecture is conceptually portable to desktop, web, and CLI environments via OS accessibility APIs, the implementation reported in the paper is Android-centric. Finally, base-model quality still constrains template generation and action correctness even if reliance on model size is reduced (Liu et al., 15 Dec 2025).

The principal terminological distinction is therefore straightforward. MBMP is a bandwidth-aware admission-control protocol for multi-hop MANETs (Pattanayak et al., 2010), and the “Mobility Management Framework” is a cost-based framework for mobility strategies and vertical handover in heterogeneous networks (0810.0394). MOBIMEM, in contrast, denotes a memory-centric LLM agent system for mobile and desktop automation (Liu et al., 15 Dec 2025). The shared lexical field of “mobile” and “management” can obscure this difference, but the problem domains are separate: wireless resource control, network mobility management, and post-deployment agent self-evolution.

A plausible broader implication is that MobiMem reframes agent improvement as external-state optimization. In that formulation, memory structures and runtime services absorb a substantial part of what model scaling and continual retraining previously carried, especially in GUI automation where interaction traces, user preferences, and recurrent workflows are persistent and structurally reusable.