Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents
Dongming Jiang, Yi Li, Bingzhe Li
cs.AI · cs.LG
Quick verdict
Claims System-One control lifts LoCoMo to 0.777 (+11% rel.) with 6.6x faster builds; promising efficiency design, but single benchmark and no ablations.
Summary
The paper argues that agentic memory systems waste autoregressive LLM generation on frequent, bounded control decisions such as typing, linking, routing, scoring, and stopping. Jev-Mem proposes a three-plane architecture: a System-One control plane built on typed probabilistic 'Jev' queries, a multi-relational memory plane (semantic, temporal, causal, and entity views sharing canonical observation nodes, inherited from the authors' earlier MAGMA), and a System-Two LLM reserved for answer synthesis. During construction the controller types observations and selectively adds relations over at most ten candidates; during retrieval it routes queries across relational views, allocates an expansion budget (B=80), performs RRF-anchored graph traversal, scores candidates, and stops adaptively based on evidence sufficiency. On LoCoMo, with gpt-4o-mini as both backbone and judge, Jev-Mem reports an overall LLM-as-a-Judge score of 0.777 versus 0.700 for MAGMA (a claimed 11.0% relative gain), best in five of six table columns including Adversarial at 0.962 versus 0.742; memory construction takes 158 s (6.6x faster than Nemori's 1044 s) and average query latency is 0.93 s (36.7% below MAGMA's 1.47 s). Main limitations: despite announcing two benchmarks, only LoCoMo is reported; no ablations isolate the controller's mechanisms; no variance or significance testing; prose figures (0.625, 0.797, a claimed 0.650 match) contradict Table 1 (0.623, 0.802, 0.637); efficiency-focused baselines (LightMem, SimpleMem, Zero-Mem) are cited but not compared; and the controller's underlying model is unspecified.
Review complete
Assessment at a glance
6
risk flags identified
● high 1
● medium 4
● low 1
5 strengths · 5 weaknesses · 5 author questions
Levels reflect verification complexity — not a quality score. Evolve never rates your paper.
Key claims under review
- High-frequency, bounded memory-control decisions (typing, relation inference, routing, budgeting, scoring, stopping) can be executed by a lightweight typed probabilistic controller instead of autoregressive LLM calls without hurting downstream accuracy.
- On LoCoMo, Jev-Mem achieves an overall LLM-as-a-Judge score of 0.777 versus 0.700 for the strongest baseline MAGMA, an 11.0% relative improvement, leading in five of six table columns.
- Jev-Mem constructs memory in 158 s (6.6x faster than the fastest tested competitor, Nemori at 1044 s) and answers queries in 0.93 s on average (36.7% below MAGMA's 1.47 s and below Full Context's 1.74 s).
- A single typed decision interface can govern both memory construction and retrieval, replacing collections of heuristics and repeated LLM calls with one control plane.
Strengths
Sharp problem identification with precise positioning
Section 2.2 cleanly separates bounded-output memory decisions (labels, probabilities, scores) from open-ended generation, and positions the fix against adaptive-RAG (IRCoT, FLARE, Self-RAG) and model-routing (FrugalGPT, RouteLLM) work rather than claiming their novelty.
Unified control abstraction across the full memory lifecycle
Section 3.1 uses one typed interface J(S,Q) for both write-path typing/relations and read-path routing/scoring/stopping — architecturally cleaner than the per-heuristic designs it criticizes, and the paper argues this explicitly rather than leaving it implicit.
Unusually transparent implementation detail
Joint accuracy-efficiency result, if it holds
Documented honesty choices
Weaknesses
Single benchmark despite promising two
No ablations of the claimed mechanisms
Prose contradicts Table 1 in three places
Efficiency baselines incomplete
The controller is an unexplained black box
Full Review Report
$1.99 · one-timeUnlock the complete preliminary analysis Evolve produced for this paper.
Report preview
Jev-Mem — Structured Preliminary Review
The remaining sections cover Methodology Assessment, Statistical Evidence, Results & Reproducibility, Limitations & Risks, and Verdict & Recommendations.
- All 5 strengths & 5 weaknesses, analyzed in detail
- 6 risk flags with severity, section & reviewer questions
- Methods & statistical evidence assessment
- 5 questions a peer reviewer would ask
- Full six-dimension evaluation report & recommendations
One-time purchase · this paper only
One-time purchase, this paper only. AI-generated preliminary analysis — not peer review.
Frequently asked questions
What is Jev-Mem?
Jev-Mem is an agentic memory architecture for LLM agents that splits work by speed: a lightweight 'System-One' controller makes fast, structured memory decisions (typing memories, linking them, routing queries, scoring candidates, deciding when to stop searching) using typed probabilistic queries instead of LLM text generation, while a 'System-Two' LLM is reserved only for final answer synthesis. The memory itself is a multi-relational store with semantic, temporal, causal, and entity views.
What results does Jev-Mem report on LoCoMo?
The paper reports an overall LLM-as-a-Judge score of 0.777 versus 0.700 for the strongest baseline (MAGMA), a claimed 11.0% relative improvement; memory construction in 158 seconds, 6.6x faster than the fastest tested competitor (Nemori, 1044 s); and average query latency of 0.93 seconds, 36.7% below MAGMA's 1.47 s. All numbers use gpt-4o-mini as both answer model and judge.
Is Jev-Mem code available?
The authors state the code is publicly available at github.com/libingzheren/Jev-Mem. However, the System-One controller depends on an external tool called Jev (typesafe.ai), and the paper never specifies what model powers it, which complicates independent reproduction and cost estimation.
How does Jev-Mem differ from MAGMA?
MAGMA is the same research group's earlier system providing the multi-relational memory store (semantic, temporal, causal, entity graphs). Jev-Mem keeps that memory plane but replaces LLM-based memory control with the lightweight typed controller: on LoCoMo this changes overall score from 0.700 to 0.777 and build time from 1404 s to 158 s, making MAGMA the closest thing to an ablation in the paper — though other implementation differences are not controlled for.
About this review
This is an AI-generated preliminary review by Evolve.Pub, produced from the openly available text of the paper. It is not peer review and does not represent the authors' views. The canonical record of the paper is at the publisher link above.
- Figures 1-2 are referenced but only their embedded text labels were extractable; visual architecture and any plotted details could not be verified.
- The experiments section may be incomplete in extraction: 4.1 announces two benchmarks but only LoCoMo appears; a second-dataset subsection may exist beyond the provided text.
- The three prose-table mismatches (0.625/0.623, 0.797/0.802, 0.650/0.637) could partly stem from extraction, though both versions appear coherently in the same text, so they are treated as genuine inconsistencies.
- Default values for symbols like theta_act, Dmax, and Kw are not in the extracted text (only Appendix B's operating values), so some hyperparameters could not be audited.
Go deeper on this paper
Wrote a paper? Stress-test it before reviewers do.
Upload your manuscript for the same structured scrutiny — reasoning, statistics, evidence, figures, and reproducibility.
