MemOrb: Verbal Reinforcement Memory for E-Commerce

• MemOrb is a plug-and-play verbal-reinforcement memory layer for LLM-based e-commerce customer service, designed to mitigate forgetting and repeated operational errors through compact policy reflections.
• It generates and stores concise policy reflections called 'Orbs' from multi-turn dialogues, which are later retrieved to guide tool-using interactions across different customer-service tasks.
• Empirical results show that MemOrb enhances task success rates and consistency, achieving up to a 63-percentage point gain in multi-turn customer service scenarios.

MemOrb is a plug-and-play verbal-reinforcement memory layer for LLM-based customer service agents in e-commerce. It is designed for multi-turn, tool-using dialogues about orders, logistics, returns, and product details, and addresses forgetting across sessions, repeated operational errors, and the absence of continual self-improvement in frozen LLM deployments. Its central mechanism is to distill completed interaction trajectories into compact strategy reflections called “Orbs,” store them in a shared memory bank, and retrieve them to guide later decisions without any fine-tuning (Huang et al., 23 Sep 2025).

1. Problem setting and conceptual basis

MemOrb is situated in a deployment regime where stability and consistency matter as much as raw task accuracy. The motivating claim is that most customer-service agents rely on short context windows or per-user profiles, while in e-commerce fewer than 5% of queries recur and product catalogs change daily; accordingly, per-user memories or raw dialogue caches do not accumulate reusable policy knowledge. In this setting, the main failure mode is not merely forgetting user facts, but repeatedly mishandling tool calls, choosing incorrect parameters, or misapplying policies across different users and tasks (Huang et al., 23 Sep 2025).

The framework emphasizes two indicators. The first is task success rate as the operational measure of effectiveness. The second is consistency, measured with Pass$^k$, which estimates the probability that all $k$ trials in a randomly chosen subset are successful. This shifts evaluation from one-off success to repeated reliable execution, a crucial distinction for customer-service systems that must avoid sporadic correctness and instead sustain stable performance over multiple runs of similar tasks (Huang et al., 23 Sep 2025).

A defining premise is that frozen LLMs can still improve if they accumulate explicit textual strategy knowledge. MemOrb therefore adopts verbal reinforcement rather than gradient updates: after a task finishes, a reflection model analyzes the trajectory and writes a natural-language policy reflection; later, a retrieval stage brings similar reflections back into the prompt so that the actor model can reuse successful strategies or avoid previously documented mistakes (Huang et al., 23 Sep 2025).

2. Architecture and memory representation

MemOrb wraps a frozen actor agent with three additional components: a shared memory bank, a rewrite model, and a self-reflection model. During execution, the actor follows a ReAct-style interaction pattern with users and tools. After the episode ends, the self-reflection model compresses the trajectory into an Orb. On a future task, the rewrite model reformulates the current dialogue context into a retrieval-oriented query, retrieves relevant Orbs, and prepends them to the actor’s prompt (Huang et al., 23 Sep 2025).

An Orb is formally defined as

$$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$

Here, $\text{id}$ is a SHA-256 digest of the other fields; $\text{obs}$ is the concatenated user utterance stream or scenario description; $\text{emotion}$ is a categorical tag such as “frustrated” or “satisfied”; $\text{outcome}$ is the distilled policy reflection produced by the self-reflection model; $\text{context}$ is JSON metadata such as order IDs, SKUs, or budgets; and $\text{timestamp}$ records creation time (Huang et al., 23 Sep 2025).

Field	Role	Content
obs	Scenario capture	Concatenated user utterances or system prompt
emotion	Affect tag	Categorical label from an EmotionTagger
outcome	Policy memory	Distilled reflection with a “New Plan”
context	Structured metadata	JSON such as order IDs, SKUs, budgets

The memory bank has two layers. A metadata store, implemented with SQLite and SQLAlchemy, stores Orb records and supports fetch and upsert. A vector store, implemented with ChromaDB, stores serialized Orb documents embedded by BAAI/bge-m3 into a 768-dimensional vector space. Retrieval uses maximum inner product over these embeddings. This arrangement makes the system lightweight and plug-and-play, in the sense that it can wrap existing LangGraph-based customer-service agents without modifying base-model weights (Huang et al., 23 Sep 2025).

3. Verbal reinforcement loop

MemOrb’s reinforcement mechanism is textual rather than parametric. The episode trajectory is represented as

$\tau = \{(u_t, a_t, r_t)\}_{t=1}^T,$

where $k$0 is the user utterance at step $k$1, $k$2 is the agent action, including tool calls or textual responses, and $k$3 is an evaluation signal such as tool-use correctness or output quality. The policy-reflection distillation procedure concatenates the user utterances into $k$4, tags the final-turn emotion, produces $k$5 by prompting the reflection LLM on the full trajectory, assembles structured metadata into $k$6, assigns a timestamp, and hashes the result into $k$7 (Huang et al., 23 Sep 2025).

The key informational content of an Orb is the reflection. These reflections are not raw logs or per-user facts. They are policy-level summaries of what went wrong or right and how similar tasks should be handled in the future. The appendixed prompt structure explicitly asks for failure analysis over tool selection, parameter choice, action ordering, and integration of tool outputs, and requires an explicit “New Plan.” As a result, an Orb stores procedural guidance such as which tool to call first, what conditions to verify, and which policy branch applies under which payment method or evidence type (Huang et al., 23 Sep 2025).

At inference time, retrieval begins by rewriting the current user query $k$8 and dialogue context $k$9 into a retrieval-oriented query

$$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$0

That query is embedded into a 768-dimensional vector and matched against Orb embeddings. If $$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$1 is the query embedding and $$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$2 is the embedding of Orb $$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$3, MemOrb retrieves

$$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$4

The retrieved Orbs are then concatenated into the actor’s system prompt, where they function as verbalized experience and directly shape subsequent decisions (Huang et al., 23 Sep 2025).

This mechanism differs from memory systems that replay raw dialogue or maintain user-specific profiles. MemOrb stores cross-user, schema-free strategy reflections. The stored knowledge is therefore reusable across many customer-service episodes even when the customer identity, product instance, and exact wording differ, provided the underlying operational structure is similar (Huang et al., 23 Sep 2025).

4. Evaluation criteria and benchmark protocol

The principal benchmark is ECom-Bench, comprising 130 multi-turn customer-service tasks: 53 household-appliance tasks from the original benchmark and 77 clothing tasks constructed by the authors with scripts and LLM-based data synthesis. A task is counted as successful if the agent satisfies the customer request within 12 turns, avoids hallucinating product or order information, and uses tools correctly (Huang et al., 23 Sep 2025).

Success rate is defined as

$$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$5

Consistency is measured with Pass$$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$6: $$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$7 where $$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$8 is the number of repeated trials for a task and $$O = \langle \text{id},\ \text{obs},\ \text{emotion},\ \text{outcome},\ \text{context},\ \text{timestamp} \rangle.$$9 is the number of successful trials among them. The protocol differs from the default $\text{id}$0-bench setup because MemOrb reruns tasks even after successful completions, thereby making Pass$\text{id}$1 a stricter measure of stability under repeated execution (Huang et al., 23 Sep 2025).

The benchmarked agent uses the LangGraph template agent from ECom-Bench, and MemOrb is evaluated on top of three frozen LLM backbones: Doubao-Seed-1.6-Thinking, Doubao-Seed-1.5, and DeepSeek-V3. The no-memory baseline uses a 4k-token context window and no external learning mechanism. MemOrb uses SQLite for metadata, ChromaDB for vectors, BAAI/bge-m3 for embeddings, and retrieves $\text{id}$2 Orbs for prompt augmentation. The evaluation runs for ten independent trials; the first trial starts with an empty memory for both baseline and MemOrb, and only MemOrb accumulates new reflections across trials (Huang et al., 23 Sep 2025).

This evaluation design is notable because it isolates training-free continual improvement. There are no gradient updates and no RL fine-tuning. Any improvement across trials arises from the memory layer itself: reflection generation, shared storage, retrieval, and prompt reuse (Huang et al., 23 Sep 2025).

5. Empirical results and behavioral effects

On household-appliance tasks, MemOrb improves both final success rate and the trajectory of improvement across repeated trials. For Doubao-Seed-1.5, the baseline rises from 18.87% at $\text{id}$3 to 67.92% at $\text{id}$4, whereas MemOrb rises from 32.08% at $\text{id}$5 to 94.34% at $\text{id}$6. For DeepSeek-V3, the baseline reaches 66.04% at $\text{id}$7 and MemOrb reaches 75.47%. For Doubao-Seed-1.6-Thinking, the baseline reaches 88.68% and MemOrb reaches 94.34% at $\text{id}$8 (Huang et al., 23 Sep 2025).

On the 77 clothing tasks, absolute success rates are lower, but MemOrb still improves the final results. At $\text{id}$9, Doubao-Seed-1.6-Thinking improves from 37.66% to 38.96%, Doubao-Seed-1.5 from 35.06% to 37.66%, and DeepSeek-V3 from 33.77% to 36.36% (Huang et al., 23 Sep 2025).

The abstract reports that MemOrb achieves up to a 63 percentage-point gain in multi-turn success rate and improves stability across repeated trials. The Pass$\text{obs}$0 curves consistently dominate the no-memory baselines across all three backbone models, indicating that MemOrb does not merely increase average success but also makes repeated successes more likely (Huang et al., 23 Sep 2025).

Ablations clarify which ingredients matter. Replacing Orbs with a more complex structured reflection memory increases token overhead and context bloat without producing comparable gains. Restricting retrieval to nearly identical tasks, via $\text{obs}$1, weakens cross-user transfer and harms performance especially for Doubao-Seed-1.5 and DeepSeek-V3. This supports a central claim of the framework: cross-user reflection sharing is important because customer-service strategy knowledge generalizes across users more effectively than user-specific episodic caches (Huang et al., 23 Sep 2025).

Qualitative case studies show the same pattern at the level of tool workflow. In one failure episode, the reflection encodes a revised cancellation-and-cashback strategy, including direct order cancellation, screenshot verification, and conditional use of the refund tool depending on payment method. In a later similar task, the actor follows that “New Plan” and successfully handles installation guidance, logistics, cancellation, and cashback registration in a single interaction sequence. The case illustrates that MemOrb stores operational policy corrections rather than conversational trivia (Huang et al., 23 Sep 2025).

6. Position within the agent-memory literature

MemOrb occupies a specific niche within long-term memory research for LLM agents. Relative to user-centric memory systems such as Mem0 and LangMem, it does not center memory around persistent user profiles; instead, it stores schema-free policy reflections shared across users. Relative to episodic RAG systems such as MemoryBank and ReadAgent, it does not replay raw dialogue chunks, thereby avoiding context bloat. Relative to programmatic memory layers such as MemGPT and A-Mem, it remains lightweight, relying on SQLite, ChromaDB, and prompt-based reflection rather than a heavily structured memory substrate. Relative to skill-code repositories such as Voyager and Optimus-1, it is specialized for dialogue-oriented strategy in customer service rather than executable long-horizon planning (Huang et al., 23 Sep 2025).

This positioning becomes clearer when contrasted with adjacent 2026 memory work. Memori is an LLM-agnostic persistent memory layer that treats memory as a data-structuring problem and converts dialogue into semantic triples plus conversation summaries, achieving 81.95% accuracy on LoCoMo with 1,294 tokens per query, or about 5% of full context (Borro et al., 20 Mar 2026). All-Mem instead organizes memory as a topology-structured graph with visible-surface retrieval, offline Split/Merge/Update consolidation, and non-destructive versioning, improving retrieval and QA on LoCoMo and LongMemEval under fixed budgets (Lv et al., 20 Mar 2026). MemMA approaches the problem as a coordinated memory cycle, adding a Meta-Thinker, Memory Manager, Query Reasoner, and in-situ self-evolving memory construction to improve long-horizon conversational QA on LoCoMo (Lin et al., 19 Mar 2026). Memora, by contrast, proposes a harmonic memory representation built from primary abstractions, concrete values, and cue anchors, and reports state-of-the-art results on LoCoMo and LongMemEval (Xia et al., 3 Feb 2026).

The contrast is substantive. MemOrb’s core abstraction is not a graph node, semantic triple, or cue-anchored abstraction, but a policy reflection distilled from a completed customer-service trajectory. Its memory is therefore closer to verbalized experience replay than to factual storage or topological consolidation. A plausible implication is that MemOrb is best understood as a specialized continual-improvement layer for operational policy transfer, rather than as a universal long-term memory architecture.

7. Limitations and prospective extensions

MemOrb’s main limitations are explicitly acknowledged. Reflection quality is bounded by the base LLM because the self-reflection and rewrite modules use the same frozen model family as the actor; a weak reflector can therefore generate suboptimal Orbs. The memory stack is a single-node SQLite plus ChromaDB deployment, so scaling to very large concurrent workloads would require sharding or more robust vector infrastructure. The memories are text-only, without multimodal evidence such as screenshots, receipts, or PDFs. Finally, evaluation is limited to ECom-Bench, so cross-domain generalization to healthcare, finance, or other regulated service settings remains untested (Huang et al., 23 Sep 2025).

Several failure modes follow from these design choices. A bad reflection can encode an incorrect “New Plan,” thereby propagating misleading procedural guidance. If policies, tools, or business rules change, older Orbs can become stale and may overfit the actor to outdated workflows. And if too many reflections are retrieved or reflections become verbose, prompt crowding can offset the intended efficiency of compact strategy memory (Huang et al., 23 Sep 2025).

The paper identifies four main directions for future work: multimodal Orbs that incorporate screenshots or voice; privacy-aware memory and possibly federated or on-device storage; cross-domain evaluation beyond e-commerce; and more advanced memory management, including pruning outdated reflections or organizing them hierarchically (Huang et al., 23 Sep 2025). These extensions would move MemOrb closer to broader lifelong-memory systems, but the current formulation is already technically distinctive: it shows that frozen LLM agents can achieve training-free continual self-improvement by storing and reusing compact verbal reflections of operational strategy.