Papers
Topics
Authors
Recent
Search
2000 character limit reached

Zero-Mem: Zero-Token Memory Operations for LLM Agents

Published 31 Jul 2026 in cs.CL | (2607.29377v1)

Abstract: LLM agents need memory to act consistently over long interactions, yet many systems use additional LLM calls to operate that memory. Generating intermediate records and mediating their retrieval adds recurring token and time costs, while omitted or merged details can obscure the original evidence. We ask whether structured memory access requires generation at all. Zero-Mem introduces \emph{zero-token memory operations}: no step outside final question answering invokes an LLM or consumes LLM input or output tokens; encoder computation is accounted for separately. Zero-Mem preserves original interaction traces as its source of record. It organizes the traces in two complementary ways. An entity--context graph exposes connections across interactions, while a temporal hierarchy preserves conversational locality and session state. For each query, Zero-Mem weighs the two views, retrieves from both, and follows their structure to recover supporting relations or surrounding context. Deterministic calibration first discards conflicting evidence and then keeps the reader's answer grounded in the retrieved traces. Only the final-QA reader invokes an LLM. Across long-memory and long-context question-answering benchmarks, Zero-Mem achieves competitive performance while eliminating LLM calls and LLM-token consumption from memory operations. With the same final-QA reader and context budget, it reduces memory-operation time cost by 57.6\% relative to the fastest compared baseline. Ablations support the contribution of the two views and their query-dependent coordination. Overall, the results show that structured agent memory need not generate an intermediate representation of the past. After peer review, the code and implementation details will be available at \textcolor{blue}{https://github.com/TheMoon0815/Zero-mem}.

Summary

  • The paper introduces Zero-Mem, a memory system that operates entirely without generative LLM calls by leveraging an entity–context graph and temporal hierarchy for trace preservation.
  • The paper demonstrates deterministic memory organization and retrieval, achieving superior F1 and BLEU-1 scores (+5.4 F1 and +5.45 BLEU-1) on benchmarks like LoCoMo and HotpotQA.
  • The paper evidences a 57.6% reduction in latency and enhanced transparency, cost efficiency, and traceability by isolating memory operations from final inference.

Zero-Mem: Eliminating Generative Memory Operations for LLM Agents

Motivation and Problem Statement

As LLM agents are increasingly deployed for long-term, multi-turn tasks, effective memory systems have become essential for retrieving relevant information from extensive, entity-rich, and temporally structured interaction histories. A prevalent strategy in agentic memory design is to utilize additional LLM calls for summarization, abstraction, organization, and retrieval of historical traces. While this lowers retrieval complexity and can improve downstream answer quality, it introduces substantial token and latency overhead, increases cost, and frequently sacrifices traceability or fidelity due to generative loss or omission in intermediate representations.

Zero-Mem is proposed to address a fundamental question: Can structured, high-fidelity memory for LLM agents operate entirely without generative LLM calls or LLM-token consumption, except for the final answer generation? The objective is to architect a memory pipeline in which all memory organization, indexing, and retrieval operations are non-generative and token-free, thereby isolating memory-operation cost from final inference and improving efficiency, transparency, and provenance preservation.

Methodology

Zero-Mem architectural design is based on retaining fully provenance-bearing raw interaction traces, eschewing generative abstraction at every step. Memory organization and retrieval are conducted through two interdependent but non-generative representations:

  • Entity–Context Graph View: A non-parametric, provenance-preserving bipartite graph is built by applying lightweight NER models. Context nodes represent original trace units, connected to entity nodes (detected without LLMs); additionally, adjacency edges encode sequence continuity. Evidence propagation follows a multi-step, dense-similarity seeded PageRank over this graph, incorporating relational cues and lexical refinement.
  • Temporal Hierarchy View: The interaction log is partitioned into episodes (reflecting session boundaries), windows, turns (utterances), and local spans. These units preserve fine-grained conversational locality and temporal state. Retrieval is performed in a coarse-to-fine manner, guided by answer-type and boundary constraints deterministically inferred from the input query without invoking an LLM. Figure 1

    Figure 1: Overview of Zero-Mem, depicting how original traces are organized into provenance-preserving entity–context graphs and a temporal hierarchy, with all intermediate operations being token-free.

For each query, a deterministic query structure profile determines the balance (routing coefficient ρ\rho) between the relational (graph) and hierarchical (temporal) retrievals; the two evidence sets are fused, then closed by adding bridging structures (from both views) before deterministic calibration removes spurious or out-of-bound content, ranks, and formats the evidence for the final answer generation. Throughout, only statistical, deterministic, or classical NLP components (e.g., NER, BM25, semantic embeddings) are used outside the terminal QA call.

Comparative Evaluation and Results

Zero-Mem is evaluated on the LoCoMo and HotpotQA benchmarks, representing long-term conversational memory and long-context multi-hop QA, respectively. Two model configurations are explored: GPT-4o-mini and Qwen2.5-14B, reflecting both closed-source and open-source settings.

Zero-Mem achieves the strongest average F1 and BLEU-1 scores in LoCoMo across all question types and both LLM readers. With GPT-4o-mini, it improves over the best baseline (GAM) by +5.4 F1 and +5.45 BLEU-1. With Qwen2.5-14B, it leads on every question type and metric.

For HotpotQA, Zero-Mem shows consistent improvements over all baselines across context-lengths up to 448K tokens, with an average improvement of 5.52 F1 over the previous best (GAM) at these extreme settings. Figure 2

Figure 2: Ablation on HotpotQA shows both the graph and hierarchy views are necessary for optimal F1 and BLEU-1; evidence closure and calibration provide further measurable gains.

Figure 3

Figure 3: Retrieval budget ablation on LoCoMo. Performance increases rapidly up to top-5 to top-10 retrieval, saturating thereafter; top-5 is used for baseline comparability.

Also critical are Zero-Mem's efficiency results: memory operations incur zero LLM token or call overhead, and its non-generative design halves memory-operation latency compared to the next most time-efficient baseline (LightMem). Importantly, answer quality improves or matches the best generative-memory competitors, disproving the hypothesis that generative abstraction is a requirement for structuring large-scale agentic memory.

Ablations and Architectural Insights

Ablation studies rigorously confirm:

  • Complementarity of Dual Views: Removing either the graph or hierarchy view imposes severe quality degradation, especially for cross-entity (relational) and session-local (temporal) queries. Combined, their coordination supports both distributed and local evidence needs.
  • Evidence Closure and Calibration: Omitting evidence completion or calibration steps also results in significant drops in F1 and BLEU-1, illustrating the necessity of deterministic post-retrieval processing.

Implications and Future Directions

Zero-Mem demonstrates that provenance-preserving, structured memory for LLM agents can be operationalized entirely outside the scope of generative LLMs, except for the final reader. This delivers large practical and theoretical benefits:

  • Practical: Substantial cost and latency reduction; transparency and debug-ability of evidence chains; improved privacy and compliance owing to strict provenance traceability.
  • Theoretical: Separates the roles of memory structuring and generation in agent architectures; supports explicit evaluation of non-generative memory pipelines in compositional and multi-hop-agentic settings.
  • Contradicts the often unstated assumption that only LLM-driven summarization, abstraction, and reflection can enable scalable and accurate memory for large-horizon agents. Figure 4

    Figure 4: Contrasts Zero-Mem's operating regime against prior generative-memory and raw retrieval architectures.

Potential future research includes extending this dual-view, zero-token methodology to richer multi-modal traces, dynamic entity tracking, and time-evolving agent behaviors; further, joint optimization of retrieval and answer modules could refine overall effectiveness now that memory cost is amortized.

Conclusion

Zero-Mem establishes that LLM agents can achieve state-of-the-art long-term memory performance with no intermediate generative memory operations. Memory organization, indexing, retrieval, and calibration are entirely token-free; only the terminal QA reader depends on the LLM. Empirical results demonstrate superior answer quality and 57.6% lower latency relative to the most efficient prior art. This work compels the community to reconsider generative dependence in agent memory pipelines, motivating a new class of transparent, efficient, and provenance-maintaining agentic architectures (2607.29377).

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

Explain it Like I'm 14

A simple guide to “Zero-Mem: Zero-Token Memory Operations for LLM Agents”

What is this paper about?

The paper introduces Zero-Mem, a way for AI chat assistants (LLM agents) to remember past conversations without constantly asking another AI to summarize or manage that memory. Zero-Mem keeps the original messages, organizes them smartly, and only uses the AI once—at the very end—to answer the user’s question.

“Zero-token memory operations” means: during memory work (storing, finding, and checking evidence), the system doesn’t make the AI generate any extra words at all. The AI is only called for the final answer.


What questions does the paper try to answer?

  • Can an AI agent remember long, messy histories without repeatedly using an LLM to summarize, rewrite, or “reflect” on the past?
  • Can we keep memory reliable and easy to trace back to the original messages?
  • Can we do all that faster and cheaper, while keeping or improving answer quality?

How does Zero-Mem work? (In everyday language)

Think of the AI’s memory like a big diary of everything that’s happened in chats and tasks. Zero-Mem keeps the exact diary pages (the original messages) and builds two simple, helpful views on top—without rewriting anything.

  • View 1: A relationship map (like a social map)
    • Who and what are mentioned together? For example, “Alex” and “trip to Paris” appear in the same message.
    • The system uses a basic name-finder (to spot people, places, organizations) and links messages that mention the same things.
  • View 2: A timeline with chapters
    • Messages are grouped by time and session into turns, short windows, and bigger episodes (like pages, paragraphs, and chapters).
    • This preserves “what happened right before/after” and keeps context local, like a mini storyline.

When a new question comes in, Zero-Mem follows these steps:

  1. Understand the question shape
    • Is it asking about a person or a relationship (better for the relationship map)?
    • Is it asking about “what happened when” or needs nearby context (better for the timeline)?
  2. Search using both views
    • It searches the relationship map to connect related bits spread across the diary.
    • It searches the timeline to keep the story straight (what happened first, what’s nearby).
    • It also uses simple search signals: exact word matches (names, dates, numbers) and meaning-based matches (when wording differs but the idea is similar).
  3. Close the gaps
    • If the answer needs a nearby sentence for clarity, Zero-Mem grabs that too.
    • If there’s a useful bridge (like another message that links two people or events), it pulls that in.
  4. Check for conflicts and format
    • It throws out evidence that breaks rules (wrong time period, wrong person).
    • It checks the final answer’s type and format (for example, a date should look like a date) and makes small, exact fixes if needed—only when the evidence clearly supports it.
  5. Ask the LLM only once
    • After all that, the system gives the best evidence to the LLM to produce the final answer.

Key idea: Zero-Mem never replaces the original messages with AI-made summaries. This avoids the “telephone game” problem where details get lost or mixed up.


What did the researchers find, and why is it important?

They tested Zero-Mem on tough benchmarks that require long-term memory and multi-step reasoning:

  • On LoCoMo (very long multi-session chats):
    • Zero-Mem got the best average scores across question types with two different LLMs.
    • It was especially strong on questions needing time-aware or open-ended memory.
  • On HotpotQA (multi-hop questions over long documents):
    • Zero-Mem scored highest across all context lengths, even when there were lots of distracting passages.
  • Speed and cost:
    • Zero-Mem used zero LLM tokens for all memory operations (only the final answer used the LLM).
    • It cut memory-operation time by 57.6% compared to the fastest strong baseline, while also improving answer quality.
  • Why both views matter:
    • Removing either the relationship map or the timeline view made results worse.
    • This shows the two views complement each other: the map connects scattered facts; the timeline keeps the story straight.

This is important because it proves you don’t need to keep generating summaries or notes with an LLM to get strong memory performance. Keeping the original messages and organizing them well can be faster, cheaper, and more reliable.


What could this change in the real world?

  • More trustworthy AI assistants
    • Answers can be traced back to the exact messages that support them, reducing mistakes and “hallucinations.”
  • Lower cost and faster responses
    • No extra LLM calls for memory means fewer tokens and less waiting.
  • Works with different AIs
    • Zero-Mem improved results with both a closed-source model (GPT-4o-mini) and an open-source one (Qwen2.5-14B).
  • Useful for many apps
    • Personal assistants that remember long histories
    • Customer support agents that keep track of past issues
    • Research tools that connect facts across many documents

The takeaway

Zero-Mem shows that AI agents can remember and use long histories well without constantly generating new “memory summaries.” By keeping the original messages and organizing them with a map (relationships) and a timeline (local context), the system answers better, faster, and more cheaply—using the LLM only once, at the end.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The following concrete gaps and open questions remain unresolved and suggest directions for future research:

  • Entity extraction and disambiguation
    • How robust is the NER-driven entity–context graph under aliasing, coreference, pronouns, misspellings, and homonyms, especially across sessions and users?
    • No canonical entity linking is used; how to prevent cross-session entity collisions (same name, different person) or fragmentation (same person, different surface forms)?
    • How does the approach perform with few/zero named entities (e.g., generic or procedural queries), or in highly technical/low-resource domains where NER accuracy drops?
  • Temporal modeling and conflict handling
    • The paper states it “discards conflicting evidence” but does not specify the rules for temporal updates, precedence, or tie-breaking (latest mention vs. majority vs. bounded scope).
    • Event-time normalization is not detailed (e.g., resolving “last week,” time zones, or document vs. event time); how reliably can temporal validity be enforced?
    • How are overlapping or nested episodes/windows detected and updated online without drift or fragmentation?
  • Hierarchical segmentation details
    • The method claims episode/window formation via “semantic continuity,” but the non-generative procedure, thresholds, and update policy are unspecified; what algorithm and parameters are used and how sensitive are results to them?
    • How are session boundaries inferred when metadata are missing or noisy?
  • Graph construction and propagation
    • Edges encode only co-occurrence and adjacency with frequency-based weights; can richer, typed relations (e.g., “works_at,” “met_with,” “bought”) be induced non-generatively without sacrificing zero-token guarantees?
    • Personalized PageRank over large graphs may be costly; what are the asymptotic and practical limits (nodes/edges) before latency and memory use degrade?
  • Routing and weighting
    • Routing uses a fixed global coefficient ρ=0.6; how sensitive is performance to ρ and γ across datasets and question types? Can routing be learned or adaptively estimated without violating zero-token constraints?
    • What is the fallback behavior and quality when routing selects the “wrong” primary view?
  • Evidence closure and calibration
    • Deterministic calibration rules are not fully specified (e.g., numeric normalization, unit conversion, deduplication heuristics, list pruning criteria); how comprehensive and domain-agnostic are these rules?
    • What are failure modes where calibration over-prunes correct but non-exactly-matched answers, or preserves fluent but unsupported LLM outputs?
    • Beyond extractive fixes, how can the system handle aggregation questions (counting, arithmetic), comparisons, or schema alignment deterministically?
  • Retrieval budget and context management
    • Results are reported mainly at Top-5; larger budgets stabilize performance but can exceed reader context limits. How to optimally allocate evidence under strict context windows and varying query complexity?
    • How does evidence ordering within the final reader context impact answer quality, and can ordering be optimized deterministically?
  • Scalability and systems concerns
    • End-to-end build/update costs for the graph and hierarchy (indexing, PageRank precomputation, incremental updates) under streaming, multi-user workloads are not characterized.
    • Storage growth from retaining all raw traces is unbounded; what are policies for eviction, compaction, or privacy-preserving redaction that maintain provenance yet control footprint?
    • How does performance change with millions of turns, heavy concurrency, or distributed/sharded indexes?
  • Robustness and domain generalization
    • No evaluation on noisy inputs (ASR transcripts), code-switching, multilingual text, or specialized domains (medical, legal) where NER and embedding quality can drop.
    • The approach depends on a specific embedding model (BGE-M3) and spaCy NER; how portable are results across languages, domains, and alternative encoders/NERs?
  • Multimodality and tool traces
    • Although traces may include tool outputs and images, the paper does not describe indexing/grounding non-text modalities; how would the dual-view framework extend to vision, audio, or structured tool outputs without LLM mediation?
  • Faithfulness and evidence attribution
    • The method emphasizes provenance but provides no quantitative evaluation of evidence precision/recall or alignment with gold supporting facts (e.g., HotpotQA supporting sentences).
    • How often does the final answer cite or rely on evidence outside the retrieved set, and can explicit evidence-attribution checks be added without LLM calls?
  • Comparative fairness and tuning
    • Baselines with generative consolidation may be disadvantaged by a uniform Top-5 cap and shared reader; how do results change when each baseline uses its recommended evidence budget and reader configuration?
    • Were embeddings, indexes, and hyperparameters equivalently tuned across methods? A sensitivity study is missing.
  • Task coverage
    • Evaluation focuses on QA; how does Zero-Mem perform on agent tasks requiring planning, long-horizon tool use, preference tracking, or policy consistency across sessions?
    • No human evaluation of dialog consistency, helpfulness, or perceived faithfulness is provided.
  • Security, privacy, and governance
    • Retaining full, provenance-rich raw traces raises PII and compliance issues (e.g., GDPR/CCPA); how to support selective deletion, anonymization, and audit trails without breaking provenance?
    • What safeguards prevent sensitive but irrelevant memories from surfacing via relational closure or dense similarity?
  • “Zero-token” definition and cost accounting
    • The zero-token claim excludes encoder inference and indexing; standardized cost accounting (latency, energy, compute $/query) across memory pipelines is not established.
    • If embeddings are obtained via hosted APIs, token-based or character-based pricing may still apply; how should such costs be integrated into the zero-token framework?
  • Error analysis and diagnostics
    • The paper lacks qualitative error analyses (especially on multi-hop where Zero-Mem underperforms some baselines); what specific failure patterns dominate (missed bridge entities, wrong temporal scope, over-aggregation)?
    • Can deterministic diagnostics be surfaced to guide index maintenance (e.g., adding alias dictionaries, time normalization rules) without resorting to LLMs?
  • Incremental and lifelong updates
    • How are graph/hierarchy updated online with bounded latency as new turns arrive, including re-segmentation of episodes, reweighting edges, and cache invalidation for PageRank?
    • Does incremental updating introduce drift or degrade earlier segmentations, and how can this be detected and corrected deterministically?
  • Hybrid and learned components
    • Are there zero-token-compatible learned components (e.g., small discriminative rerankers, learned routing) that could further improve retrieval without LLM calls?
    • What is the trade-off frontier between small learned models and fully deterministic heuristics in this setting?
  • Reproducibility and release
    • Core implementation details remain unspecified or deferred (segmentation algorithm, calibration rules, indexing parameters); complete release of code, configs, and scripts is necessary to validate zero-token claims and replicate results.

Practical Applications

Below is an overview of practical, real-world applications suggested by the paper’s findings and methods. Applications are grouped by deployability horizon and include sector mapping, potential tools/products/workflows, and feasibility notes.

Immediate Applications

These can be deployed now using the paper’s zero-token memory pipeline (dual-view relational + temporal retrieval, deterministic calibration) with off-the-shelf components (e.g., spaCy NER, BM25, BGE-M3 embeddings, PageRank).

  • Customer support and contact centers (software; services)
    • Use case: Tokenless long-term memory for multi-session customer chats that preserves provenance and reduces inference spend and latency.
    • Tools/products/workflows: Plug-in “Tokenless Memory Layer” for Zendesk/Genesys/Five9; backend built on Elasticsearch/OpenSearch + Weaviate/Milvus + spaCy NER; orchestration with LangChain/LlamaIndex; PPR over an entity–context graph.
    • Assumptions/dependencies: Access to historical chat logs and session boundaries; PII governance; multi-lingual NER quality if needed; final QA LLM cost remains.
  • CRM and sales assistants (software; finance)
    • Use case: Account/matter timelines across emails, calls, and meetings with zero LLM calls for memory; fast, provenance-grounded recall before meetings.
    • Tools/products/workflows: Salesforce plugin that indexes interaction traces into a dual-view memory substrate; “Next-Meeting Brief” generator with deterministic calibration of facts and dates.
    • Assumptions/dependencies: Email/calendar/CRM API access; strict access controls per account; accurate entity resolution for names/companies.
  • Enterprise meeting assistants (software; productivity)
    • Use case: Cross-session recall of decisions, owners, and deadlines from meeting transcripts with trace-level provenance and low latency.
    • Tools/products/workflows: “Decision & Action Item Tracker” that anchors answers to exact transcript spans; BM25+embedding hybrid search; PPR over participant–topic graph.
    • Assumptions/dependencies: Good diarization and timestamps; storage of raw transcripts; deterministic calibration mainly helps factoid/list answers.
  • Software engineering copilots (software)
    • Use case: Retrieval over multi-repo code, issues, PRs, and RFCs using a provenance-preserving graph; temporal hierarchy preserves version/state.
    • Tools/products/workflows: GitHub/GitLab/Jira plugin “Zero-Mem Dev Memory” for PR review, root-cause analysis, “when/why” change queries.
    • Assumptions/dependencies: Repo/issue indexers; code-aware NER or entity heuristics (files, functions, services); scale to >1M nodes requires tuned indexing.
  • Legal operations and e-discovery (legaltech)
    • Use case: Matter-centric recall across filings, emails, depositions with strict source traceability; deterministic constraints for dates/citations.
    • Tools/products/workflows: “Provenance Recall Console” that shows graph paths between entities and the original passages; exportable audit trails.
    • Assumptions/dependencies: Secure ingestion; document-level and paragraph-level provenance; jurisdictional privacy and retention policies.
  • Healthcare admin and patient support (healthcare)
    • Use case: Intake/benefits/appointment chat with multi-visit memory and provenance; token-efficient longitudinal recall without summarization drift.
    • Tools/products/workflows: EHR-integrated “Patient Timeline Retriever” for care navigators; deterministic checks for IDs/dates/med lists when exact matches exist.
    • Assumptions/dependencies: HIPAA/GDPR compliance; limit to administrative guidance (not medical diagnosis); clinical NER adaptation may be required.
  • Financial advisory assistants and KYC (finance)
    • Use case: Client-preference and risk-profile recall across sessions with auditable sources; supports compliance Q&A with deterministic formatting checks.
    • Tools/products/workflows: “Client Profile Memory” in advisor desktop; evidence-anchored rationales for suitability and KYC refresh prompts.
    • Assumptions/dependencies: Access rights per client; sensitive data minimization; calibrated routing for date-effective facts (temporal cues).
  • IT service desks and incident response (software; security)
    • Use case: Fast recall of similar incidents, owners, and mitigations with zero-token memory updates; temporal view to reflect post-mortem changes.
    • Tools/products/workflows: “Incident Graph Explorer” linking tickets, alerts, services; deterministic shortlists of prior fixes.
    • Assumptions/dependencies: Integrations with ServiceNow/Jira; clear service/entity nomenclature improves NER and graph utility.
  • Education and tutoring (education)
    • Use case: Student progress memory across sessions with source-grounded feedback and assignment references; low-cost deployment at scale.
    • Tools/products/workflows: “Lesson Continuity Module” for LMS (Canvas/Moodle); retrieval from problem attempts and teacher notes.
    • Assumptions/dependencies: FERPA-like privacy; deterministic calibration helps fact/list responses more than free-form pedagogy.
  • Knowledge management and internal search (software; enterprise)
    • Use case: Cross-wiki and ticket retrieval that maintains both relational links and local context windows; avoids lossy summaries.
    • Tools/products/workflows: “Provenance KM Search” that fuses graph and hierarchy rankings with evidence closure to include neighboring context.
    • Assumptions/dependencies: Content freshness management; deduplication strategies; multilingual embeddings if needed.
  • Government digital services help desks (public sector; policy)
    • Use case: Citizen support agents with long-term memory and transparent provenance to reduce cloud spend and increase trust.
    • Tools/products/workflows: “Tokenless Memory Gateway” deployed in gov clouds; deterministic answer-type checks for forms/IDs/dates.
    • Assumptions/dependencies: Accessibility requirements; archival rules and deletion policies for raw traces.
  • Personal productivity assistants (daily life; software)
    • Use case: On-device or hybrid assistants that recall tasks, preferences, and events without LLM-in-the-loop memory, improving privacy and cost.
    • Tools/products/workflows: Mobile “Zero-Mem Personal Timeline” with local BM25 + small embedding model; optional cloud final-QA call only.
    • Assumptions/dependencies: Device storage and on-device encoders; opt-in data collection; smaller multilingual NER models.

Long-Term Applications

These require further research, scaling, domain adaptation, or policy/regulatory work before production.

  • Clinical decision support with provenance-bound recall (healthcare)
    • Use case: Evidence-grounded, longitudinal clinical recall to assist clinicians (e.g., medication changes, labs, imaging) with robust temporal validity.
    • Tools/products/workflows: “ClinMem” module integrated with EHR timeline and clinical ontologies (SNOMED/LOINC/RxNorm).
    • Assumptions/dependencies: Domain-specific NER/normalization; rigorous validation; regulatory clearance (e.g., FDA/CE); privacy-preserving storage.
  • Federated and privacy-preserving multi-tenant memory (software; policy)
    • Use case: Cross-division or cross-organization memory with secure graph partitioning, differential privacy, and auditable provenance.
    • Tools/products/workflows: “Federated Zero-Mem” with access-controlled subgraphs, query-time filter/rank by tenant scope.
    • Assumptions/dependencies: Fine-grained authorization; privacy accounting; policy-compliant retention and deletion.
  • Multimodal zero-token memory for robotics and IoT (robotics; energy; manufacturing)
    • Use case: Combine logs, images, sensor traces into a provenance-preserving memory for task recall and diagnostics, still avoiding generative memory steps.
    • Tools/products/workflows: Visual/temporal nodes in the graph; on-device encoders; edge PageRank accelerators for real-time retrieval.
    • Assumptions/dependencies: Robust multimodal alignment; hardware acceleration; bandwidth constraints at the edge.
  • Autonomous research agents with structured, tokenless memory management (academia; software)
    • Use case: Literature review and multi-hop evidence synthesis with zero-token memory ops and explicit provenance chains for citations.
    • Tools/products/workflows: “Evidence Chain Builder” that logs graph paths across papers; deterministic extraction for citations.
    • Assumptions/dependencies: High-quality PDF parsing; domain NER (authors, venues, methods); scalable graph over millions of documents.
  • Standards for provenance-preserving agent memory (policy; industry consortia)
    • Use case: Interoperable schemas/APIs for entity–context graphs and temporal hierarchies, audit logs for memory operations, and explainability artifacts.
    • Tools/products/workflows: Open specification (e.g., W3C-style) for “Provenance Memory Objects” with verifiable pointers to traces.
    • Assumptions/dependencies: Multi-vendor collaboration; legal agreements on auditability and retention.
  • Tokenless memory SDKs for vector/graph databases (software infrastructure)
    • Use case: Turn-key libraries that implement dual-view retrieval, closure, and deterministic calibration over popular DBs.
    • Tools/products/workflows: SDKs for Elasticsearch/OpenSearch, Neo4j/TigerGraph, Weaviate/Milvus/FAISS; serverless deploy recipes.
    • Assumptions/dependencies: Optimized cross-index joins; memory budgets; observability tooling.
  • Learned yet token-free routing and calibration (ML methods)
    • Use case: Replace heuristic routing/calibration with lightweight, non-generative classifiers or distillations while preserving zero-token property for memory ops.
    • Tools/products/workflows: Tiny on-device classifiers for query profiling and evidence scoring; self-supervised training on interaction logs.
    • Assumptions/dependencies: Labeled or weakly labeled data; careful bias/robustness evaluation.
  • Compliance-first audit and trace replay (finance; public sector; legal)
    • Use case: Full replayable chains from answer back to exact source units with timestamped policies; supports e-discovery and regulatory audits.
    • Tools/products/workflows: “Answer-to-Trace Graph Proof” artifacts shipped with every response; immutable logs via ledger/append-only stores.
    • Assumptions/dependencies: Storage overhead; standardized redaction annotations; cryptographic attestations.
  • Large-scale, cross-lingual memory for global orgs (software; education; government)
    • Use case: Robust zero-token memory across languages and scripts with consistent entity linking and temporal reasoning.
    • Tools/products/workflows: Cross-lingual embeddings, multilingual NER/linkers; language-aware PageRank resets.
    • Assumptions/dependencies: Training/evaluation data; entity resolution across locales; varied date/time formats.
  • Hardware-accelerated PageRank and hierarchical retrieval (infrastructure)
    • Use case: Sub-200ms memory ops on very large graphs through GPU/FPGA acceleration and compressed indexes.
    • Tools/products/workflows: CUDA kernels for PPR; succinct data structures for temporal hierarchies; cache-aware memory layouts.
    • Assumptions/dependencies: Engineering effort; cost–benefit trade-offs; integration with managed cloud services.

Notes on Global Assumptions and Dependencies

  • Zero-token applies to memory operations only; final question answering still invokes an LLM (and thus cost/latency/security models for that stage remain).
  • Feasibility hinges on high-quality NER, embeddings (e.g., BGE-M3), and lexical indexing (BM25); domain adaptation may be required for healthcare, legal, or code entities.
  • Storing raw traces improves provenance but increases privacy/compliance responsibilities (GDPR/HIPAA/CCPA), retention limits, and right-to-erasure workflows.
  • Deterministic calibration provides the most benefit for factoid, list, and formatted outputs; free-form generation quality still depends on the final LLM.
  • Performance on very large corpora may require sharding, caching, and graph/index optimization; routing weights and reset vectors can be tuned per domain.
  • Multilingual deployments require multilingual encoders and NER; mixed-script entity normalization is non-trivial.

Glossary

  • Ablation study: A controlled analysis that removes or alters components to assess their individual contributions. "Ablation study on HotpotQA with 56K-token contexts and GPT-4o-mini."
  • Adjacency edges: Graph links that connect neighboring context units to preserve local continuity. "EddE_{dd} contains adjacency edges between neighboring context units."
  • Answer calibration: A post-reading procedure that checks and, when possible, deterministically corrects an answer against retrieved evidence. "afterward, deterministic answer calibration applies evidence-support, type, and format checks without invoking another model."
  • BGE-M3: A family of dense text embedding models used for semantic retrieval signals. "Zero-Mem additionally indexes trace units with lexical statistics (BM25) and dense embeddings (BGE-M3)."
  • BLEU-1: A unigram precision-based metric for evaluating text generation quality. "Results are reported across four question types under two evaluation metrics, F1 and BLEU-1, using GPT-4o-mini and Qwen2.5-14B as base LLMs."
  • BM25: A classic lexical retrieval scoring function for ranking documents by term overlap. "Zero-Mem additionally indexes trace units with lexical statistics (BM25) and dense embeddings (BGE-M3)."
  • Coarse-to-fine search: A retrieval strategy that narrows candidates by moving from broader to more granular units. "The hierarchical view retrieves evidence through coarse-to-fine search."
  • Context budget: The maximum context size allocated to the reader or retrieval pipeline. "With an identical final-QA reader and equivalent context budget, Zero-Mem achieves a 57.6\% reduction in memory-operation latency compared to the most time-efficient baseline,"
  • Damping factor: The probability of continuing a random walk in PageRank, balancing exploration and resets. "where γ(0,1)\gamma\in(0,1) is the damping factor."
  • Dense embeddings: Vector representations capturing semantic similarity for retrieval and scoring. "Zero-Mem additionally indexes trace units with lexical statistics (BM25) and dense embeddings (BGE-M3)."
  • Dense similarity: Similarity computed between dense embeddings of texts. "where sim(q,z)\operatorname{sim}(q,z) denotes the dense similarity between query qq and sentence zz."
  • Deterministic calibration: Non-generative filtering and adjustment procedures that enforce constraints without LLM calls. "Zero-Mem applies deterministic calibration at both the evidence and answer levels."
  • Directed labeled graph: A graph with directed edges and labels capturing typed relations between entities. "Mem0g models entity relations with a directed labeled graph."
  • Dual-time model: A representation that tracks two distinct time dimensions (e.g., event time and ingestion time). "and a dual-time model tracking event and ingestion times."
  • Dual-view routing coefficient: A weighting parameter that balances the contributions of graph and hierarchical retrieval views. "Damping factor γ\gamma and dual-view routing coefficient ρ\rho are both set to 0.6."
  • Encoder computation: The non-generative embedding or feature extraction cost, accounted for separately from LLM token usage. "encoder computation is accounted for separately."
  • Entity--context graph: A bipartite graph linking entities to the context units in which they appear, plus adjacency between contexts. "An entity--context graph exposes connections across interactions,"
  • Evidence closure: A completion step that augments top candidates with supporting relational links and local context. "Removing evidence closure results in 67.90 F1 and 65.43 BLEU-1,"
  • Final-QA reader: The only LLM-invoking component that generates the final answer from the curated evidence set. "Only the final-QA reader invokes an LLM."
  • Hierarchical view: The retrieval perspective that preserves temporal order and local conversational context across granularities. "The graph view is primary for relational queries, whereas the hierarchical view is primary for local queries."
  • HotpotQA: A Wikipedia-based benchmark for multi-hop question answering and explainability. "HotpotQA~\cite{HotpotQA} is a Wikipedia-based benchmark for multi-hop question answering."
  • Just-in-time memory paradigm: A strategy that assembles task-specific context on demand at query time. "GAM~\cite{GAM} combines lightweight offline memory with online deep research under a just-in-time memory paradigm,"
  • Lexical statistics: Term-frequency-based features used for exact-phrase and token-level retrieval signals. "Zero-Mem additionally indexes trace units with lexical statistics (BM25) and dense embeddings (BGE-M3)."
  • LoCoMo: A benchmark evaluating very long-term conversational memory in LLM agents. "LoCoMo~\cite{locomo} is a widely adopted benchmark for assessing long-term memory in conversational agents over extended, multi-session interactions."
  • Multi-hop: Reasoning or retrieval that requires connecting evidence across multiple documents or turns. "we evaluate its single-hop, multi-hop, temporal-reasoning, and open-domain tasks."
  • Named Entity Recognition (NER): Automatic identification of entities (persons, organizations, etc.) in text. "Zero-Mem applies the non-generative Named Entity Recognition (NER) model (e.g., spaCy) to each context unit"
  • Open-domain: Tasks or questions not constrained to a specific, closed knowledge base or context. "we evaluate its single-hop, multi-hop, temporal-reasoning, and open-domain tasks."
  • Personalized PageRank: A variation of PageRank that biases random walks toward a query-specific reset distribution. "Personalized PageRank then distributes this evidence over the relational graph:"
  • Provenance: The retained origin and metadata of evidence that allows tracing back to source interactions. "a provenance-preserving entity--context graph and temporal hierarchy without generative abstraction."
  • Query-conditioned routing: A mechanism that assigns relative weights to retrieval views based on the structure of the query. "Query-conditioned routing weights the two views, whose retrieved evidence is fused and completed with relational bridges and local neighbors."
  • Reset vector: The query-dependent distribution that seeds or reinitializes random walks in Personalized PageRank. "The propagated entity activations and dense context priors are combined into a query-specific reset vector rq\mathbf{r}_q."
  • Retrieval-augmented generation (RAG): A method that first retrieves relevant text and then conditions generation on it. "RAG divides the history into 2,048-token chunks and retrieves the top five chunks by semantic similarity as supporting context for answer generation."
  • Sliding window: A chunking approach that processes overlapping text blocks sequentially over long histories. "LONG-LLM partitions the interaction history into multiple text blocks using a sliding window, processes each block independently, and returns the candidate answer with the highest confidence."
  • Stationary node-score vector: The converged node-importance distribution in PageRank for a given query. "where πq\boldsymbol{\pi}_q is the query-conditioned stationary node-score vector,"
  • Temporal hierarchy: A structured organization that preserves conversational order, locality, and session state over time. "a temporal hierarchy preserves conversational locality and session state."
  • Top-K: The retrieval budget specifying how many primary candidates are kept before augmentation. "Increasing TopKTop-K from 1 to 5 substantially improves the average F1 and BLEU-1 scores from 52.59 and 46.79 to 59.15 and 52.96, respectively."
  • Transition matrix: The normalized matrix of edge probabilities used to define random-walk transitions in a graph. "PP is the row-normalized graph transition matrix,"
  • Zero-Mem: The proposed framework that eliminates LLM calls from memory operations via structured, provenance-preserving retrieval. "We propose Zero-Mem, which reformulates memory operation as structured evidence selection over provenance-bearing interaction traces."
  • Zero-token memory operations: An operating regime where memory construction, organization, and retrieval use no LLM calls or LLM tokens. "Zero-Mem introduces zero-token memory operations: no step outside final question answering invokes an LLM or consumes LLM input or output tokens; encoder computation is accounted for separately."
  • Zettelkasten: A note-taking method that structures knowledge into linked atomic notes to aid retrieval and synthesis. "A-Mem~\cite{A-Mem} follows the Zettelkasten note-taking method, constructing structured memory notes with keywords, tags, and contextual descriptions while dynamically linking related memories."

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 8 tweets with 7 likes about this paper.

HackerNews