Better memory for long-running AI agents—with fast decisions and focused reasoning.

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

Dongming Jiang, Yi Li, and Bingzhe Li · September 2026 · PDF

Jev-Mem separates the frequent decisions of memory management from the deeper reasoning needed to answer a question. A lightweight System-One controller organizes memories and guides retrieval across semantic, temporal, causal, and entity relations. A System-Two language model synthesizes the answer from the evidence it finds.

• 2026-09-27 · Laya integration. Jev-Mem now supports Laya for local System-One decisions. The same memory pipeline works with either Jev or Laya. Get started ↓
• 2026-09-21 · Jev-Mem launch. Our paper is on arXiv, with code on GitHub and a demo on Hugging Face.

On LoCoMo with GPT-4o-mini, the paper reports 11.0% higher overall answer quality, 6.6× faster memory construction, and 36.7% lower query latency than the strongest or fastest baseline for each metric. See results for the comparisons.

Results · How it works · Quick start · Run experiments · Contribute · Citation

Persistent agents need to remember preferences, connect events across sessions, and recover the right evidence as their histories grow. Each new memory and each retrieval step introduces decisions: how information connects, where to search, and when enough evidence has been found. Jev-Mem gives these decisions a dedicated, structured controller.

• Preserve the evidence. Keep original observations, timestamps, and provenance. The default profile retains every valid observation, so a detail can become useful later even if its importance was unclear when it arrived.
• Connect memories in four ways. Shared memory nodes participate in semantic, temporal, causal, and entity graph views, supporting questions about what happened, when, why, and to whom.
• Adapt retrieval to the question. Route queries across relevant graph views, allocate search budgets, score candidates, and reassess whether more evidence is needed after each round.
• Inspect the decisions. Typed outputs, explicit traversal limits, and traces expose routing, budgets, stopping reasons, cache hits, and fallback events.

Results below are reported in Tables 1–2 of the paper, using GPT-4o-mini as the answer model. Answer quality is measured by LLM-as-a-Judge; query latency includes retrieval and answer generation.

• Higher answer quality: 0.777 versus MAGMA's 0.700—a 0.077 absolute gain and 11.0% relative improvement.
• Faster construction: 158 s versus Nemori's 1,044 s—a 6.6× speedup over the fastest competing memory system.
• Lower query latency: 0.93 s versus MAGMA's 1.47 s—a 36.7% reduction versus the fastest memory baseline.

These are the paper's reported measurements. The commands below are starting points for running the implementation; their subsets and scoring settings do not reproduce the full paper evaluation by themselves.

Jev-Mem combines three components:

Write → connect. Each observation retains its text and provenance and receives overlapping episodic, semantic, procedural, and preference scores. Candidate search identifies a bounded set of existing memories; Jev judges inferred relations, while code handles deterministic links such as timestamp ordering.

Retrieve → assess → expand. Vector and keyword search supply initial anchors. The controller selects useful graph views, allocates traversal effort, and scores new candidates. It stops when the evidence is sufficient, further search has little expected value, or a configured limit is reached. Selected evidence then goes to the answer model.

Jev exposes decisions through Noul (binary propositions) and Choice (categorical decisions). Ordinary code validates the outputs and enforces the graph and retrieval limits. Explore the decision questions, write policies, and retrieval controller.

Requires Python 3.11+. From the repository root:

python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
python -m jev_mem.demo

The demo uses no API keys or model downloads. It stores a few synthetic observations, retrieves evidence, and prints the decision trace. It uses deterministic mock decisions and embeddings to demonstrate the pipeline; it does not measure answer quality. After dependencies are installed, it runs offline. On Windows, activate with .venv\Scripts\Activate.ps1.

Create a local .env file in the repository root with your provider keys:

TYPESAFE_API_KEY=your-typesafe-key
OPENAI_API_KEY=your-openai-key

Jev controls memory decisions; the OpenAI-compatible model generates answers and supports evaluation. The CLI loads .env, with existing environment variables taking precedence. The supplied profile uses jev-latest; choose the answer model with --model. The default minilm embedding backend downloads its model on first use.

Build and query the included synthetic observations:

python -m jev_mem --mode build --input examples/observations.json \
  --jev-config config/jev_mem.json --cache-dir ./jev_mem_cache/app

python -m jev_mem --mode query --question "What reminder does Mira prefer?" \
  --jev-config config/jev_mem.json --cache-dir ./jev_mem_cache/app

For your own data, supply a JSON list of strings or objects with content, an optional ISO 8601 timestamp, and optional metadata.

Live runs send text to the configured providers and may incur charges. Keep keys, conversations, and generated caches local; see SECURITY.md for handling private data.

One memory system, two decision backends. Keep Jev as the default, or run Laya locally for memory construction and retrieval. The graph, retrieval policies, and System-Two answer model are shared.

After creating the Python environment above, try Laya on the included synthetic data:

python -m pip install '.[laya]'
USE_TF=0 python -m jev_mem.benchmarks.locomo \
  --dataset examples/locomo_synthetic.json \
  --jev-config config/laya_mem.json \
  --sample 0 --max-questions 2 --best-of-n 1 --no-parallel

Laya decisions need no TypeSafe API key. Answer generation and evaluation still use your configured OpenAI-compatible provider. Weights download on first use; Apple Silicon users can select the MLX install and profile from the table. The results reported above use Jev; Laya has not been benchmarked for this paper. See the Laya guide for setup, cache reuse, and model limits.

Download datasets from their original distributors using the data setup guide. The repository includes synthetic examples for exploring the input formats.

Place the dataset at data/locomo10.json, then try ten questions from sample 0:

python -m jev_mem.benchmarks.locomo \
  --dataset data/locomo10.json \
  --jev-config config/jev_mem.json \
  --sample 0 --model gpt-4o-mini \
  --max-questions 10 --category-to-test 1,2,3,4 --best-of-n 1

Samples are zero-based. --max-questions caps evaluated questions per sample after category filtering; all conversation history is still ingested. Pass multiple samples with, for example, --sample 2 3 4 5.

Use --best-of-n 1 for single-answer evaluation: the inherited default of 3 uses reference-aware selection that can bias accuracy. This example excludes adversarial category 5, which requires separate analysis and is included in the paper's results table. --jev-mock replaces only Jev; benchmark answer generation and judging still use live models.

The repository also includes a LongMemEval runner. The current paper reports LoCoMo results; no LongMemEval result is claimed here.

python -m jev_mem.benchmarks.longmemeval \
  --dataset data/longmemeval_s_cleaned.json \
  --jev-config config/jev_mem.json \
  --model gpt-4o-mini --max-questions 5

Each question has its own conversation history. Jev-Mem ingests every nonempty user/assistant message with its role and session date, then answers from retrieved graph evidence. The runner uses an existing lenient scorer, not the official LongMemEval metric. Run with --help for category filters; their IDs differ from LoCoMo's.

Matching benchmark runs automatically reuse cached graphs. For a single LoCoMo sample, --reuse-memory PATH_TO_EXISTING_SAMPLE_CACHE reuses an exact graph while tuning retrieval; construction settings must match, and it cannot be combined with --rebuild.

Results record construction, save/load, and query timing separately. Jev-Mem also records retrieval traces and decisions. The runner's construction timer excludes model initialization, disk saving, and question answering. Record the commit, configuration, dataset subset, model, scoring protocol, and cache state when comparing experiments.

Start with config/jev_mem.json. All validated fields and defaults are defined in JevMemConfig.

Tune settings on development data and evaluate on held-out samples. Latency limits are checked between operations, so they are not a strict wall-clock deadline.

For Python integration, import JevMemSystem and JevMemConfig from jev_mem. Use JevMemSystem, MemoryBuilder, and QueryEngine with jev_config=.... See the naming and migration guide when updating older integrations.

See the developer guide for module responsibilities and documentation index for evaluation and release workflows. The original root commands remain available as compatibility entry points. Install with python -m pip install -e . to use the jev-mem console commands.

Reproducible benchmark runs, new memory tasks, controller ablations, and documentation improvements are welcome. Start with CONTRIBUTING.md for the development workflow and contribution guidelines.

python -m pip install -r requirements-dev.txt
python -m pytest -q

Explore memory/ for the implementation, tests/ for offline regression tests, and examples/ for synthetic inputs. Share bugs and experiment ideas through GitHub issues.

@misc{jiang2026jevmemsystemonecontrolledagenticmemory,
      title={Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents}, 
      author={Dongming Jiang and Yi Li and Bingzhe Li},
      year={2026},
      eprint={2609.23986},
      archivePrefix={arXiv},
      primaryClass={cs.AI},
      url={https://arxiv.org/abs/2609.23986}, 
}

Jev-Mem is distributed under the MIT license.