Memory Bank (Memory) User Guide

Make Mobile AI Agent smarter with every use: accumulate experience across tasks, remember preferences across sessions, compress context within tasks — zero network dependency, all data stays in your browser.

Feature Overview
Core Features
Three-Layer Memory Model
How It Works
Typical Use Cases
Case Studies
Competitor Comparison
Data Analysis
FAQ

Feature Overview

The Memory Bank is the "brain" of Mobile AI Agent. When you have the Agent control your phone to complete a task (e.g. "open Douyin and search for products"), it automatically distills reusable experience from the execution process; when performing similar tasks later, the Agent prioritizes retrieving this experience to avoid detours and pitfalls.

Core Value:

Faster with use: Successful paths are remembered, significantly reducing execution rounds for similar tasks
More stable with use: Failure lessons are remembered, preventing the same mistakes from recurring
More personalized with use: Chat preferences are remembered, automatically adapting interaction style over time

Core Features

Feature	Description
Local-First	All data stored in browser IndexedDB (database name `mobile-ai-memory`), zero network dependency, private data never leaves the device
Auto Distillation	Experience automatically distilled after task completion — no manual operation needed; naturally expressed preferences in chat are remembered
Smart Retrieval	BM25 algorithm + field weighting (title×3 / keywords×2 / body×1), millisecond-level matching of relevant experience
Positive & Negative Experience	Successful tasks distill "reusable paths", failed tasks distill "pitfall warnings", injected separately during retrieval
App-Level Knowledge	Experience can be attributed to specific apps (e.g. "WeChat", "Douyin"), same-app tasks prioritized for injection, reducing exploration
Self-Managing Capacity	Semantic memory LRU eviction (limit 500), episodic logs FIFO eviction (limit 200), frequently used experience auto-retained
Graceful Degradation	When IndexedDB is unavailable (e.g. browser private mode), automatically degrades to no-memory mode without affecting the main flow
MCP Open Access	Exposes 3 tools externally (search / save / delete), third-party MCP clients can directly read and write memory

Three-Layer Memory Model

The Memory Bank uses a cognitive-science-inspired three-layer model, simulating the human brain's "long-term memory + short-term memory + working memory":

1. Semantic Memory — Long-Term Experience

Analogy: Knowledge like "WeChat settings page is in the 'Me' tab → Settings" stored in the human brain.

Attribute	Description
Storage	IndexedDB `semantic` store
Capacity	Limit 500 entries
Eviction Strategy	LRU: `score = (lastUsedAt ?? createdAt) + hits × 86_400_000`, lowest score evicted
Sources	Post-task LLM distillation / Chat preference distillation / MCP external writes
Key Fields	`title` (one-line summary), `content` (experience body), `keywords` (retrieval keywords), `polarity` (positive/negative), `app` (attributed app)

Experience Polarity:

positive: Reusable success paths (e.g. "Douyin search entry is the magnifying glass icon in the top-right of the homepage")
negative: Pitfall warnings (e.g. "Tapping the search button directly on the search page has no response — need to tap the input field first to bring up the keyboard")

2. Episodic Memory — Long-Term Event Logs

Analogy: Event memories like "Last time I opened Douyin and searched for a product, it took 5 attempts to succeed".

Attribute	Description
Storage	IndexedDB `episodic` store
Capacity	Limit 200 entries
Eviction Strategy	FIFO: oldest `createdAt` evicted first
Write Timing	Auto-persisted after each Agent task completes (one entry per task, events inline)
Content	Task goal, status, complete event stream (step start/end, tool calls, errors, reflections, replanning), working memory snapshot

3. Working Memory — Short-Term Context

Analogy: "I just did A, now I need to do B, and I already know C" — what you hold in your head while working on a single task.

Attribute	Description
Storage	Pure in-memory (within task lifecycle)
Capacity	Last 3 steps full summary + earlier steps folded into rolling summary + fact list ≤ 20 items
Purpose	Provides compressed context for each Agent decision step, replacing the old "first N steps summary first 80 chars" approach
Lifecycle	Optionally written to episodic memory as `summary` after task completion

How It Works

Data Flow Overview

┌─────────────────────────────────────────────────────────────────────┐
│                     Memory Bank Data Flow                           │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  Task Start                                                         │
│     │                                                               │
│     ▼                                                               │
│  ┌─────────────────────────────────────────┐                        │
│  │ 1. Retrieval & Injection                │                        │
│  │    - App-level UI knowledge (5, priority)│                        │
│  │    - Positive experience (3, reusable)   │                        │
│  │    - Negative experience (2, warnings)   │                        │
│  │    On hit: hits+1, lastUsedAt updated    │                        │
│  └─────────────────────────────────────────┘                        │
│     │                                                               │
│     ▼                                                               │
│  Task Execution                                                     │
│     │                                                               │
│     ├── Each step ──> Working Memory: addStep / addFact              │
│     │          buildContext() outputs compressed context for Resolve │
│     │                                                               │
│     ▼                                                               │
│  Task End                                                           │
│     │                                                               │
│     ├── addEpisode() ──> Episodic log persisted (await)              │
│     │                                                               │
│     └── distillTaskMemories() ──> LLM distillation ──> addSemantic() │
│         (success → positive / failure → negative, detached async)    │
│                                                                     │
│  During Chat                                                        │
│     │                                                               │
│     └── Intent keyword hit ──> distillChatMemories() ──> addSemantic()│
│         (User preference distillation, at most 1 entry)              │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Retrieval Algorithm

The Memory Bank uses BM25 + field weighting + dual boost retrieval:

Tokenization: English/numbers lowercase whole-word ([a-z0-9_]+), Chinese by bigram splitting
Field Weighting: Title ×3 / Keywords ×2 / Body ×1 (keywords indexed as whole words, not split)
BM25 Scoring: k1=1.2, b=0.75, classic information retrieval algorithm
Dual Boost:
- Hit Weighting: Each hit +2%, capped at +40% (frequently used experience weighted higher)
- Recency: Created within 7 days +10% (fresh experience prioritized)

Performance: Index rebuilt from IndexedDB on app startup, millisecond-level for thousands of entries; runtime additions/deletions maintain the index synchronously, no rebuild needed.

Typical Use Cases

Use Case 1: Repetitive Phone Operation Automation

User Goal: Search for a product on Douyin and take a screenshot weekly

Memory Effect:

1st time: Agent explores the Douyin interface, may take multiple attempts to find the search entry
2nd time: Agent retrieves "Douyin search entry is the magnifying glass icon in the top-right of the homepage", navigates directly
Nth time: Agent completes in seconds, skipping all exploration steps

Distilled Experience:

title: "Douyin search entry"
content: "Douyin search entry is the magnifying glass icon in the top-right of the homepage, tapping it enters the search page"
keywords: ["Douyin", "search", "magnifying glass", "homepage"]
app: "Douyin"
polarity: "positive"

Use Case 2: Failure Lesson Avoidance

User Goal: Perform a search operation on a certain app's search page

Memory Effect:

1st time: Agent taps the search button directly, no response (keyboard needs to be brought up first), task fails
2nd time: Agent retrieves "Tapping the search button directly on the search page has no response", taps the input field first to bring up the keyboard, then searches
Subsequently: Agent always brings up the keyboard first on that app's search page

Distilled Experience:

title: "Search requires keyboard to be brought up first"
content: "XX App search page: tapping the search button directly has no response, need to tap the input field first to bring up the keyboard before searching"
keywords: ["search", "keyboard", "input field"]
app: "XX App"
polarity: "negative"

Use Case 3: Long-Term Preference Memory

User Chat: "Always reply to me in Chinese from now on"

Memory Effect:

Agent distills "Language preference: user requests all future replies to be in Chinese"
All subsequent chats default to Chinese, no need to repeat

Distilled Experience:

title: "Language preference"
content: "User requests all future replies to be in Chinese"
keywords: ["Chinese", "reply", "language"]
polarity: "positive"

Use Case 4: Third-Party MCP Client Integration

Scenario: External MCP clients (e.g. Qoder, Claude Desktop) directly read and write memory via WebMCP

Tools:

search_memory: { query: "Douyin search", type: "semantic", limit: 5 } → returns relevant experience
save_memory: { title: "Custom experience", content: "...", keywords: [...] } → writes to memory
delete_memory: { id: "xxx" } → deletes specified memory

Purpose: External systems can inject their own accumulated knowledge into the Agent's memory, enabling cross-system experience sharing.

Case Studies

Case A: Douyin Product Search from Zero to One

Task Goal: "Open Douyin, search for 'Bluetooth earphones', screenshot the top 10 products"

1st Execution (No Memory)

Plan Phase:
  Step 1: Open Douyin
  Step 2: Enter search page
  Step 3: Type keyword
  Step 4: Screenshot product list

Resolve Phase:
  Step 1: launchApp("com.ss.android.ugc.aweme") ✓
  Step 2: Exploring UI... Tapped bottom "Home" tab ✗ (wrong)
          Exploring UI... Tapped top "magnifying glass" icon ✓ (success)
  Step 3: Tap search input field → bring up keyboard → inputText("Bluetooth earphones") ✓
  Step 4: screenshot() ✓

Task duration: 4 steps, 2 exploration failures

Distilled Experience:

"Douyin search entry is the magnifying glass icon in the top-right of the homepage" (positive)
"Douyin search requires tapping the input field first to bring up the keyboard" (positive)

2nd Execution (With Memory)

Plan Phase:
  Retrieval Injection:
    - App-level knowledge: Douyin search entry is the magnifying glass icon in the top-right of the homepage
    - Positive experience: Douyin search requires tapping the input field first to bring up the keyboard
  
  Step 1: Open Douyin
  Step 2: Tap the magnifying glass icon in the top-right of the homepage to enter search page
  Step 3: Tap the search input field to bring up the keyboard, type "Bluetooth earphones"
  Step 4: Screenshot product list

Resolve Phase:
  Step 1: launchApp("com.ss.android.ugc.aweme") ✓
  Step 2: tap(magnifying glass coordinates) ✓ (experience matched, direct navigation)
  Step 3: tap(input field) → inputText("Bluetooth earphones") ✓ (experience matched)
  Step 4: screenshot() ✓

Task duration: 4 steps, 0 exploration failures

Effect Comparison:

Metric	1st Time	2nd Time	Improvement
Exploration failures	2	0	-100%
Execution rounds	6	4	-33%
Token consumption	~8000	~5000	-37%

Case B: Failure Lesson Avoidance

Task Goal: "Search for 'phone case' on a certain e-commerce app and add to cart"

1st Execution (Failed)

Step 3: Tap the "Search" button directly on the search page
  → Button has no response (keyboard needs to be brought up first)
  → Agent retries 3 times, task fails

Distilled experience:
  title: "Search requires keyboard to be brought up first"
  content: "XX App search page: tapping the search button directly has no response, need to tap the input field first to bring up the keyboard before searching"
  polarity: "negative"

2nd Execution (With Memory)

Plan Phase:
  Retrieval Injection:
    - Negative experience: XX App search page: tapping the search button directly has no response, need to tap the input field first to bring up the keyboard

Resolve Phase:
  Step 3: tap(input field) → keyboard pops up → inputText("phone case") → tap(search button) ✓

Task succeeded, avoided the previous pitfall

Case C: Chat Preference Memory

Conversation:

User: "Always reply to me in Chinese from now on"
Agent: (distills "language preference" memory)
      "Sure, I will reply to you in Chinese from now on."

All subsequent conversations:
Agent defaults to Chinese, no need to repeat

Competitor Comparison

Dimension	Mobile AI Use Memory	ChatGPT Memory	Claude Projects	AutoGPT Memory
Storage Location	Local IndexedDB	Cloud (OpenAI servers)	Cloud (Anthropic servers)	Local / Vector database
Privacy	✅ Data never leaves device	❌ Uploaded to cloud	❌ Uploaded to cloud	✅ Local storage
Network Dependency	✅ Zero dependency	❌ Requires internet	❌ Requires internet	⚠️ Vector DB requires internet
Memory Types	Three-layer (Semantic / Episodic / Working)	Single-layer (User preferences)	Single-layer (Project knowledge)	Two-layer (Short-term / Long-term)
Auto Distillation	✅ Auto after task completion	✅ Auto during conversation	❌ Manual upload	✅ Automatic
Retrieval Algorithm	BM25 + Weighted + Boost	Undisclosed	Undisclosed	Vector similarity
Experience Polarity	✅ Positive / Negative separated	❌ No distinction	❌ No distinction	❌ No distinction
App-Level Knowledge	✅ Attributed to specific apps	❌ None	❌ None	❌ None
Capacity Management	✅ LRU / FIFO auto-eviction	Undisclosed	Undisclosed	⚠️ Requires manual cleanup
MCP Open Access	✅ 3 tools exposed	❌ Closed	❌ Closed	⚠️ Partially open
Degradation Strategy	✅ No-op when IndexedDB unavailable	❌ No degradation	❌ No degradation	❌ No degradation

Core Advantages:

Privacy-First: All data stays in the browser, never uploaded to the cloud
Three-Layer Model: More granular memory layering than competitors, simulating human cognition
Positive & Negative Experience: Remembers not only success paths but also pitfall lessons
App-Level Knowledge: Designed for mobile scenarios — experience can be attributed to specific apps
Open Integration: MCP tools exposed externally, third-party clients can directly read and write

Data Analysis

Capacity & Performance

Metric	Value	Description
Semantic memory limit	500 entries	LRU eviction, frequently used experience auto-retained
Episodic log limit	200 entries	FIFO eviction, oldest records removed first
Working memory capacity	Last 3 steps full + rolling summary + 20 facts	Rule-based compression, zero LLM cost
Index rebuild time	Millisecond-level (thousands of entries)	Full rebuild on app startup
Retrieval response time	< 10ms	Pure in-memory inverted index + BM25
Single entry size	~200 bytes	title + content + keywords
Total storage footprint	< 1 MB	500 semantic + 200 episodic

Retrieval Weight Analysis

Field	Weight	Description
title	×3	Highest weight — one-line experience summary
keywords	×2	Whole-word indexed, high retrieval hit rate
content	×1	Lowest weight, but most information-rich

Boost Mechanism:

Boost	Calculation	Effect
Hit weighting	`1 + min(hits, 20) × 0.02`	Each hit +2%, capped at +40%
Recency	Created within 7 days ×1.1	Fresh experience prioritized

Distillation Efficiency

Scenario	Distilled Count	Description
Successful task	0–3 positive experiences	Reusable navigation paths, page structure
Failed task	0–2 negative experiences	Pitfall warnings; pure environment errors skipped
Chat preference	0–1 entries	Long-term preferences / instructions

Distillation failure rate: 0% (failures silently return empty array, no impact on main flow)

Task Execution Effect Estimation

Based on the Memory Bank's capabilities, for similar tasks on the Nth execution vs. the 1st:

Metric	Estimated Improvement	Description
Exploration failures	-50% ~ -100%	Direct navigation after experience match
Execution rounds	-20% ~ -40%	Skip exploration steps
Token consumption	-20% ~ -40%	Context compression + experience injection
Task success rate	+10% ~ +30%	Avoid known pitfalls

Note: The above are estimates based on typical mobile tasks. Actual results depend on task complexity and memory hit rate.

FAQ

Q1: Is Memory Bank data synced to the cloud?

No. All data is stored in the browser's local IndexedDB (database name mobile-ai-memory), with zero network dependency. Data persists even after closing the browser (unless browser data is cleared).

Q2: Does Memory Bank work in browser private/incognito mode?

No. IndexedDB is unavailable in private mode. The Memory Bank automatically degrades to no-op mode — all read/write APIs return empty or null, without affecting the Agent's main flow. The console outputs a one-time console.warn notice.

Q3: Does Memory Bank auto-clean?

Yes. When semantic memory exceeds 500 entries, LRU eviction applies (score = lastUsedAt + hits × 86_400_000, lowest score evicted); when episodic logs exceed 200 entries, FIFO eviction removes the oldest records. Frequently used experience is automatically retained.

Q4: How can I view and manage my memories?

Open the "Memory Management" drawer in the top-right toolbar of the chat panel, where you can:

View all semantic memories and episodic logs
Search by keyword
Delete individual memories
Clear a specific category of memories

Q5: Can external MCP clients read and write memories?

Yes. The Memory Bank exposes 3 WebMCP tools:

search_memory: Search memories
save_memory: Write memories
delete_memory: Delete memories

Third-party MCP clients (e.g. Qoder, Claude Desktop) can directly read and write memories through these tools, enabling cross-system experience sharing.

Q6: Does memory distillation consume tokens?

Yes. After each task completion, one LLM call distills semantic memories (0–3 entries for successful tasks, 0–2 for failed tasks). Distillation failures are silently skipped, not affecting the main flow. Chat preference distillation is only triggered when intent keywords are matched (e.g. "from now on", "prefer", "like"), controlling LLM costs.

Q7: What's the difference between positive and negative experience?

Positive experience: Reusable success paths, e.g. "Douyin search entry is the magnifying glass icon in the top-right of the homepage"
Negative experience: Failure pitfall warnings, e.g. "Tapping the search button directly on the search page has no response — need to tap the input field first to bring up the keyboard"

During retrieval, positive and negative experiences are injected separately, explicitly telling the model "this was a pitfall last time" to avoid repeating mistakes.

Q8: What is App-level knowledge?

Experience can be attributed to specific apps (e.g. "WeChat", "Douyin"), used for App-level UI knowledge priority injection. For example:

"WeChat settings page is in the 'Me' tab → Settings" (app: "WeChat")
"Douyin search entry is the magnifying glass icon in the top-right of the homepage" (app: "Douyin")

When a task goal contains an app name, that app's knowledge is prioritized for injection, reducing exploration rounds.

Q9: What's the difference between working memory and semantic memory?

Dimension	Working Memory	Semantic Memory
Lifecycle	Single task execution	Long-term (cross-task/session)
Storage	Pure in-memory	IndexedDB
Capacity	Last 3 steps + rolling summary + 20 facts	Limit 500 entries
Purpose	Provide compressed context for current task	Provide experience reference for future tasks
Write Method	Automatic via code	LLM distillation / Chat preference / MCP

Q10: Does Memory Bank support export/import?

Not yet supported. The current version stores memory data only in local IndexedDB and cannot be migrated across devices. For backup, you can export IndexedDB data through browser developer tools. Future versions may support JSON export/import.

Iron Rules:

Read failures return empty, write failures silently discarded, distillation failures skipped
Memory is a supplementary capability — no anomaly may ever affect the Agent / chat main flow

Memory Bank (Memory) User Guide

Memory Bank (Memory) User Guide

Table of Contents

Feature Overview

Core Features

Three-Layer Memory Model

1. Semantic Memory — Long-Term Experience

2. Episodic Memory — Long-Term Event Logs

3. Working Memory — Short-Term Context

How It Works

Data Flow Overview

Retrieval Algorithm

Typical Use Cases

Use Case 1: Repetitive Phone Operation Automation

Use Case 2: Failure Lesson Avoidance

Use Case 3: Long-Term Preference Memory

Use Case 4: Third-Party MCP Client Integration

Case Studies

Case A: Douyin Product Search from Zero to One

1st Execution (No Memory)

2nd Execution (With Memory)

Case B: Failure Lesson Avoidance

1st Execution (Failed)

2nd Execution (With Memory)

Case C: Chat Preference Memory

Competitor Comparison

Data Analysis

Capacity & Performance

Retrieval Weight Analysis

Distillation Efficiency

Task Execution Effect Estimation

FAQ

Q1: Is Memory Bank data synced to the cloud?

Q2: Does Memory Bank work in browser private/incognito mode?

Q3: Does Memory Bank auto-clean?

Q4: How can I view and manage my memories?

Q5: Can external MCP clients read and write memories?

Q6: Does memory distillation consume tokens?

Q7: What's the difference between positive and negative experience?

Q8: What is App-level knowledge?

Q9: What's the difference between working memory and semantic memory?

Q10: Does Memory Bank support export/import?

目录