Jev-Mem moves memory control off the LLM, +11% on LoCoMo at 6.6× faster build

Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents

Dongming Jiang, Yi Li, Bingzhe Li

cs.AI, cs.LG

2026-09-21

Jev-Mem runs memory writes and retrieval with a non-autoregressive System-One controller. LoCoMo score 0.777 (+11% vs MAGMA), 158 s build, 0.93 s queries.

What problem this solves

Long-horizon agents accumulate preferences, task history, and environment facts faster than a context window can hold. Memory then stops being a log and starts making decisions: whether to add an edge, which graph a query should walk, whether the evidence is enough to stop. Current systems sit at two awkward poles. Heuristics are cheap and rigid. Handing every judgment to an autoregressive LLM puts generation on the memory critical path; building the store can take more than three thousand seconds.

Jiang, Li, and Li at UT Dallas recast the problem as a System-One / System-Two split. Memory control is high-frequency and has a tiny output space, so it fits a lightweight System-One. Answer writing and deep reasoning stay with a System-Two LLM. The controller they plug in is Jev from TypeSafe AI, which emits typed probabilities without token-by-token generation.

Method

Jev-Mem has three layers. A shared data plane stores each observation as a canonical node, then overlays four relation graphs (semantic, temporal, causal, entity) plus vector and lexical indexes. A System-One control plane owns both writes and reads. System-Two synthesizes the final answer and is invoked for an optional merge or summary only when the controller escalates.

The write path does not make an irreversible store-or-drop call. Observations are kept, so a fact that looks unimportant now is still there when a later query needs it. The controller scores four overlapping types: episodic, semantic, procedural, preference. Pairwise comparison against the whole store would grow with memory size, so vector similarity, lexical overlap, shared entities, and temporal proximity first retrieve at most Kw candidates; relation judgment runs only on that set. Timestamps create temporal edges directly; matching identifiers create entity edges directly. Inferred edges are written only above a threshold θrel.

Retrieval is a closed loop, not a single top-k. The controller predicts how useful each graph is for the query, whether multi-hop is needed, and how much recency should count, then splits an expansion budget B across the active graphs. Anchors are fused from vector and keyword ranks by reciprocal rank fusion with κ=60. Each round scores four quantities: evidence sufficiency, expected utility of more search, missing required evidence, and unresolved contradiction. Search stops when evidence is enough, or when further expansion is predicted not to help. New candidates are scored on query relevance, relation usefulness, novelty, and support for current evidence, mixed with embedding similarity and stored edge weight, then the beam continues. Control cost is capped: one batched typing call and one relation call on a write; one routing call plus, per round, at most one evidence check and one batched candidate-scoring call on a read.

Results

Evaluation is on LoCoMo ultra-long multi-session dialogues. The answer backbone is gpt-4o-mini throughout, scored by LLM-as-a-Judge. Baselines are full context, A-MEM, MemoryOS, Nemori, and MAGMA, an earlier multi-relational graph from the same group.

MethodMulti-hopTemporalOpen-domainSingle-hopAdversarialOverall
Full Context0.4680.5620.4860.6300.2050.481
MAGMA0.5280.6500.5170.7760.7420.700
Jev-Mem0.6230.6370.6180.8020.9620.777

Overall 0.777, an 11.0% relative gain on MAGMA's 0.700. Best in five of six categories. Temporal is 0.637, a shade under MAGMA's 0.650. The largest gaps are adversarial (0.962 vs 0.742) and open-domain (0.618 vs 0.517).

MethodBuild (s)Query (s)
A-MEM36362.26
MemoryOS327632.68
Nemori10442.59
MAGMA14041.47
Jev-Mem1580.93

Build time is 158 s, 6.6× faster than the quickest competing memory system, Nemori at 1044 s. Query latency is 0.93 s, 36.7% below MAGMA's 1.47 s and below the 1.74 s of stuffing the full context. MemoryOS takes 32.68 s per query.

The introduction promises two widely used benchmarks. The body reports only LoCoMo.

Why it matters

Agent memory has grown denser graphs over the past year, and control cost has grown with them. Jev-Mem pulls "how should memory be managed" out of the generation loop and turns it into batched probabilistic decisions. Cascades and speculative decoding already route whole requests across model sizes. This work cuts the grain down to each typing, routing, and stopping decision inside the memory lifecycle.

The usable setting is specific. You already run a multi-relational memory, and you will accept a non-autoregressive typed controller. Quality and latency moving together on LoCoMo is evidence that the split is not empty talk. It is an architectural change, not a new memory representation. MAGMA already laid down the four graphs; this paper changes who makes the decisions.

Limitations

There is no Limitations section. The most direct hole is the evaluation surface: two benchmarks in the prose, only LoCoMo in the tables; no ablation that swaps System-One for heuristics or for an LLM controller, so the 11% and the 6.6× cannot be split between the controller and the retrieval loop. MAGMA is both prior work from the same authors and the strongest baseline, and it still wins on temporal questions, so the comparison is not neutral.

Jev is an external TypeSafe AI component. Model size, training data, and failure modes are barely discussed. Both answering and judging go through gpt-4o-mini LLM-as-a-Judge, with no human check. The prose disagrees with the table by a few points on multi-hop, open-domain, and single-hop; the table is the source of record.

There are no tool-use, repository, or web-browsing long-horizon tasks. Adaptive stopping that works on LoCoMo has no evidence yet in environments where actions leave side effects.

Terms

Source

Related papers

All paper explainers