Jev Mem: System One Controlled Agentic Memory for Efficient AI Agents
Jev-Mem is a new agentic memory architecture from UT Dallas that splits memory control into a fast System-One plane and a slower System-Two reasoning plane — cutting query latency by thirty-seven percent and memory construction time by six-point-six times. Vince sees a genuine efficiency unlock for production agent systems; Ava is cautiously impressed but wants to see how it holds up beyond LoCoMo.
Transcript
Vince Okay so the thing that got me is that most agent memory systems are using a full LLM to decide things like — should I store this? How do I score this candidate? When do I stop searching? Every one of those decisions is running through autoregressive generation.
Ava Right, and that's the actual problem. It's not that the LLM is bad at those decisions — it's that you're paying full generation cost for what is basically a structured classification call. Memory typing, relation judgment, stopping criteria — those are high-frequency, low-complexity operations that don't need a slow reasoning pass every time.
Vince Which is exactly where Jev-Mem comes in. UT Dallas team, three authors — they call it System-One-controlled agentic memory. The framing is borrowed from dual-process cognition: fast automatic System One for the structured decisions, slow deliberative System Two only when you actually need to reason.
Ava Yeah, the Kahneman framing. I'll say — it's a reasonable analogy rather than a deep claim about cognition. The actual mechanism is more interesting than the branding. They built a dedicated control plane that handles memory typing, redundancy filtering, relation construction — semantic, temporal, causal, entity — query routing, retrieval budget allocation, graph traversal, candidate scoring, and adaptive stopping. All without firing the generative model.
Vince That list is doing a lot of work.
Ava It is, but the key is that these are all structured decisions. The controller they're using — Jev TypeSafe AI — produces typed probabilistic outputs. Not generated text. So you get a decision without a forward pass through the whole model. System Two only activates for evidence synthesis and final answer generation.
Vince So the expensive part fires way less often. And the numbers bear that out — construction time drops to one hundred fifty-eight seconds, which is six-point-six times faster than the fastest competing system in their eval. Query latency hits zero-point-nine-three seconds, down thirty-six-point-seven percent.
Ava Those are real numbers. On LoCoMo — that's the benchmark, Long Conversational Memory — they score zero-point-seven-seven-seven on LLM-as-a-Judge, eleven percent relative improvement over the strongest baseline. Both axes moving in the right direction at once is actually unusual. You normally trade one for the other.
Vince Right, right.
Ava But I want to flag something on the benchmark situation, because it's a little messy. Mem0 is reporting ninety-two-point-five percent on LoCoMo in their August twenty twenty-six writeup. Jev-Mem is at zero-point-seven-seven-seven. Those are different scoring scales — one's percentage accuracy, one's a judge score — so you can't directly compare them. But it does mean you need to read the fine print before declaring a winner.
Vince And there's the Letta filesystem thing — seventy-four percent on LoCoMo just by storing conversation histories in a flat file. Which is a little humbling for the field.
Ava Oh, that one stings a little.
Vince It really does. It's the 'boring but works' problem again. Sometimes the unglamorous baseline just… holds up.
Ava It does. Though I think Jev-Mem's real argument isn't 'we beat the filesystem' — it's 'we beat the structured systems that are actually trying.' And within that comparison, the efficiency story is genuinely compelling. The construction time speedup especially. If you're running a long-horizon coding agent that's hammering memory across a whole session, six-point-six times faster construction is not a marginal win.
Vince That's exactly the use case they name — coding assistants, personal agents, research agents. And the code is actually out there. GitHub repo, libingzheren slash Jev-Mem, Python three-point-eleven or newer. So this isn't a research artifact that sits on arXiv and never ships.
Ava Yeah, that matters. My honest read on the architecture — the multi-relational memory plane is the part I'd want to stress test. They're building four graph views simultaneously: semantic, temporal, causal, entity. That's a richer structure than flat RAG, which is good for retrieval quality, but the upfront construction cost is real even at one fifty-eight seconds. The question is how that scales as memory grows over a genuinely long session.
Vince Mm-hm.
Ava And the adaptive stopping piece — System One decides when to stop traversing the graph — that's doing a lot of load-bearing work for retrieval quality. If it stops too early on a complex query, you've degraded exactly the case where you most needed System Two. I'd want to see ablations on that specifically.
Vince This is also round N of the context-window-versus-durable-memory fight, right? We've been watching this one since… honestly, I've lost count. The paper's explicit that bigger context windows don't actually solve the problem — models don't reliably use all positions in a long input, and long-term sessions add indexing and retrieval complexity that context size alone can't fix.
Ava Yeah, and I think that's the honest framing. This isn't a context-sufficiency-camp paper. It's firmly in the durable-state camp — memory as infrastructure, not working space. The difference here is they're also making a systems argument, not just a quality argument. It's not 'our memory is richer,' it's 'our memory is richer AND cheaper to operate.'
Vince Which is a harder case to dismiss. Ava, do you think this is actually shippable in a production agent today, or is it still 'cool paper, needs six more months'?
Ava Honestly? I think it's closer to shippable than most. The repo is real, the benchmark numbers are specific, and the efficiency story is not cherry-picked — they're winning on both metrics. My hesitation is LoCoMo as the sole benchmark. It's a conversational memory task. I'd want to see this on something like LongMemEval or BEAM before I called it production-ready for, say, a coding agent with tool calls and branching state.
Vince Fair. I'd actually put decent odds — maybe sixty-five percent — that someone integrates this into a real agent framework within the next couple months. The repo's clean, the dependency story is simple, and the efficiency win is concrete enough that a team running at scale has a real reason to try it.
Ava I'll take that. I'd shade lower — fifty-five, maybe — just because 'someone forks it' and 'someone ships it in production' are very different things. But I'm not saying no.
Vince The GitHub is libingzheren slash Jev-Mem if you want to poke at it — it's in the show notes.
Ava And genuinely, if you're building agents that run long sessions and you're feeling the memory latency — this is worth an afternoon. The architecture is legible, the idea is clean, and 'use a lighter controller for the boring decisions' is the kind of thing that should have been obvious and somehow wasn't.
Vince That's the whole routing thing in a different coat, honestly. The load-bearing move is almost never the loud part.
Ava Every time, Vince. Every time.
Vince Alright — go clone the repo, run it on something that actually hurts, and let us know if the adaptive stopping bites you. We'll be here being wrong about things in public.