This paper reads two others, published four days apart in September 2026: Jev-Mem by Dongming Jiang, Yi Li and Bingzhe Li, and Memory as Middleware for Self-Improving AI Agents by K. R. Jayaram, Vatche Isahagian, Vinod Muthusamy, Gegi Thomas, Punleuk Oum, Gaodan Fang and Ashwath Vaithinathan Aravindan. Both are their authors' work and every figure below is theirs. What is ours is the reading: that two groups approaching from opposite ends of the stack arrived at the same structural answer, and what that answer costs.
On 21 September 2026 a group published a memory system whose central argument is that a language model should not be deciding what an agent remembers.
On 25 September, four days later and apparently independently, another group published a position paper arguing that memory should not live inside an agent at all.
One is an efficiency argument with numbers. The other is a systems argument about ownership. They are the same conclusion: memory is infrastructure, and treating it as part of the model is the mistake.
1. The expensive thing nobody prices
Most agentic memory systems today work roughly like this. The agent needs something. A language model decides what to look for, writes a query, reads what came back, decides whether it is enough, and decides what to store afterwards.
Every one of those decisions is a generation call. Jev-Mem's authors name the cost precisely:
many existing systems rely on autoregressive LLMs to control how memories are organized, retrieved, and used, placing expensive generation on the critical path of memory operations
On the critical path is the phrase to keep. Memory operations are not occasional. A long-horizon agent reads and writes constantly, so a generation call per operation is a generation call per step of everything the agent does. The cost does not appear as a slow model, it appears as a slow system, which is much harder to attribute.
This is the same error we described in TypeSafe's System One: code orchestrates, and in a chain of events beats one big model: putting a model in a position where ordinary control flow would do. The difference is that this time somebody measured it.
2. What it costs, and what it buys back
Jev-Mem replaces the model on that path with a cheap controller, named for Kahneman's fast system. The authors describe the split as System One doing "fast, lightweight decision-making, whereas System Two performs slower, deliberative reasoning".
The controller handles memory typing and relational organisation when memories are written, and at read time it does the routing, the retrieval-budget allocation, the graph traversal, the candidate scoring and the decision about when to stop. The expensive model is called for reasoning, once the material has been assembled.
On LoCoMo, the long-term conversational memory benchmark from Maharana et al.:
| Jev-Mem | Best baseline | |
|---|---|---|
| LLM-as-a-Judge score | 0.777 | +11.0% relative gain |
| Memory construction | 158 s | 6.6x faster |
| Average query latency | 0.93 s | 36.7% lower |
Read the second row first. A 6.6 times speedup on construction is not a tuning result, it is what happens when you stop paying for generation in a loop. And the accuracy went up by 11 per cent relative, not down.
That last part is the one worth sitting with, because the intuitive trade is the opposite. You would expect a cheaper controller to be a worse controller, buying speed with quality. It was better. A plausible reading, and ours rather than theirs: the model was never adding judgement to graph traversal and budget allocation. Those are mechanical decisions. Putting a reasoner on them added latency and variance and no information.
This is exactly the claim we have been making about where intelligence belongs, and we have not previously been able to point at a measurement. Now we can.
3. The other paper, from the other end
The middleware paper does not measure anything. It is an architecture position, and its observation is about ownership rather than speed:
AI agents are stateless across sessions by default and therefore operationally amnesic
Agents cannot carry prior failures, repairs, preferences or successful strategies across sessions, so they repeat mistakes. The usual fix is bespoke memory, custom logic welded into each agent, and the authors' point is what that forecloses: memory that lives inside an agent cannot be independently managed, shared, audited or replaced.
Their proposal is to treat memory the way distributed systems came to treat data access and messaging: as a middleware layer with its own concerns. They name six, and the list reads like something written by people who have operated systems rather than demonstrated them: two-sided pluggability, host-native interposition, multi-tenant isolation, write-path consistency, federated sharing with provenance, and lifecycle governance.
The reference implementation is called ALTK-Evolve. The paper is conditionally accepted to Middleware 2026 and carries no benchmark numbers, which is appropriate for what it is and worth stating plainly rather than glossing.
Three of those six are governance concerns, not performance ones. Isolation, provenance and lifecycle are exactly the questions we set out in governed autonomy, arriving here from a different direction: you cannot audit a memory you cannot address, and you cannot address one that only exists inside an agent's own code.
4. Why two papers four days apart matter more than either
Independent convergence is weak evidence on its own. Two groups can be wrong together, and often are.
What makes this pair worth reading together is that they are not solving the same problem. One is optimising latency and cost. The other is asking who owns a piece of state. They have no reason to reach the same structural answer, and they do: take memory out of the model's control loop and make it a component in its own right.
When an efficiency argument and a governance argument independently recommend the same boundary, that boundary is usually real. It is the same signal we read in NVIDIA putting agent policy enforcement outside the agent process in OpenShell: the reason to move something out of the model is rarely one reason.
And both continue a direction we have been tracking rather than starting one. We read Jev as a model in CLM-8B, Jev, and language model shape; this is the same lineage applied to memory. The two-store argument underneath all of it is in read and write memory and why the brain keeps two memory systems.
5. What is not settled
One benchmark. Jev-Mem's numbers are LoCoMo. It is a reasonable benchmark for long-term conversational memory and it is one benchmark, measuring one shape of task. A 6.6 times construction speedup on conversational histories says little about memory over a codebase, a ledger or a stream of sensor events.
The controller is not free. A System One controller is a component with its own failure modes, and the papers do not dwell on what happens when the routing is wrong. A model deciding what to fetch at least reasons about it. A cheap controller that routes badly fails quietly and cheaply, which is not obviously better.
Middleware has no numbers. The position is well argued and it is a position. The six challenges are a research agenda, which the authors say outright.
Nobody has said what to forget. Both papers are about storing, organising and retrieving. Neither addresses deletion or decay as a first-class concern, and in a system that accumulates state across sessions indefinitely that becomes the problem, in cost terms and under data protection law. We raised this in read and write memory and it remains open.
6. What to do with this
If you are building agents, three things follow and none require either system.
Find out what is on your critical path. For each memory operation, ask whether a generation call is involved and what judgement it is contributing. If the answer is routing, ranking or deciding when to stop, that is mechanical and a model is the wrong tool. This is a profiling exercise, not an architecture rewrite.
Put memory behind an interface, now. Even if the implementation is a table and a vector store. Memory welded into agent code cannot be shared, swapped, audited or deleted from, and the cost of extracting it grows with every agent you add.
Decide who may read what, before you have more than one agent. Multi-tenant isolation and provenance are easy to design in and very hard to retrofit, which is the whole reason the middleware paper lists them.
7. Sources
- Dongming Jiang, Yi Li, Bingzhe Li, Jev-Mem: System-One-Controlled Agentic Memory for Efficient AI Agents, 21 September 2026. Every Jev-Mem figure and quotation above is from this paper.
- K. R. Jayaram, Vatche Isahagian, Vinod Muthusamy, Gegi Thomas, Punleuk Oum, Gaodan Fang, Ashwath Vaithinathan Aravindan, Memory as Middleware for Self-Improving AI Agents, 25 September 2026, conditionally accepted to Middleware 2026.
- Maharana et al., Evaluating Very Long-Term Conversational Memory of LLM Agents, the LoCoMo benchmark Jev-Mem reports against.
- Related recent work we read but did not draw on here: Are We Ready For An Agent-Native Memory System? and Memory in the Loop.
We have not run either system. Everything above is a reading of published work, and the figures are the authors'. The argument in section 4 about independent convergence, the reading in section 2 about why accuracy rose, and the open questions in section 5 are ours and should be argued with.
This note sits in our Research track, alongside the agentic, retrieval and system design threads. The full library is at Research.