The critical-path tax
Jev-Mem opens by naming a tax this series has been circling from the start. The problem statement, verbatim: “Agentic memory is becoming essential for long-horizon AI agents, yet 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.” The paper is arXiv:2609.23986, Dongming Jiang, Yi Li, and Bingzhe Li (corresponding), UT Dallas affiliation, v1 September 21 2026, preprint — one September 2026 preprint, per authors, and not yet peer-reviewed, the hedge this series wears on every number.
The previous post moved the fix to the write path and left one question standing: who executes the decisions. Three September preprints relocate structure to ingest — semantic views, collision arbitration, reconsolidation loops — and each relocation implies work that somebody has to perform: type this memory, drop this duplicate, build these relations, route the query, allocate the budget, score the candidate, decide to stop. Moving the work does not name the worker. When the worker is a frontier LLM, every one of those decisions is sampled autoregressively — at ingest on every write and at answer time on every retrieval — so the tax lands on both paths, every turn, for as long as the agent runs. The sequel beat to that argument is simple: organization was half the story, and the executor is the other half.
What follows prices the split before it sells it. Section by section: what the model is actually asked to do on the control path; the three-plane architecture the preprint proposes, quoted whole; what the controller does not know, in the authors' own disclosures; the construction bill first — this series states bills before wins — then the read path's latency and stopping budget; then a synthesis, a decision table, and a watch list for a field learning to separate bookkeeping from thought. Every external claim carries per authors, every score is scoped to the one benchmark the tables report, and no figure appears here that the preprint does not print.
What the model is really being asked to do
The full lifecycle, as the authors describe it, is a list of decisions rather than a passage of prose: “This separation redesigns the full memory lifecycle: on the write path, System One performs memory typing, redundancy filtering, and semantic, temporal, causal, and entity relation construction; on the read path, it performs query routing, retrieval-budget allocation, graph traversal, candidate scoring, evidence assessment, and adaptive stopping.” Read it as a job description and the shape is unmistakable: three write-side jobs that classify and connect records, six read-side jobs that steer and terminate a search — filing, not reasoning.
Spelled out, every item on that list ends in a label, a link, a number, or a stop signal. Typing decides which bucket a memory belongs to. Redundancy filtering decides whether an existing record already says it. Relation construction stamps semantic, temporal, causal, and entity ties between records. On the read side, routing picks the entry point, budget allocation decides how much expansion is affordable, graph traversal walks candidates out, scoring ranks them, evidence assessment decides whether the set is sufficient, and adaptive stopping decides when to walk no further. Quality still matters, and pretending otherwise would be the wrong lesson: a mistyped memory and a wrongly dropped duplicate both propagate into every answer built on them, and shallow relations make traversal wander edges that were never recorded. But quality in this sense is coverage and calibration — did the type scheme match the record, does the duplicate check catch a paraphrase, are the temporal edges right — which is a different kind of excellence from fluent generation, and none of it needs a fresh paragraph of reasoning each turn.
Paying frontier-model sampling for outputs that are labels and numbers is the mismatch this paper puts on its cover. Autoregressive generation earns its price when the next token genuinely depends on all the tokens before it — synthesis, argument, code, an answer assembled from conflicting evidence. It is most expensive exactly where it is least needed: a binary redundancy call does not improve because it was rendered in elegant prose, and a retrieval budget does not become better calibrated for having been generated at temperature. On a long-horizon agent the asymmetry compounds, because ingest runs continuously while retrieval runs every turn — the same control decisions re-sampled thousands of times to produce the same classes of output. The sections that follow price what moves when the control path stops being a generation workload.
Three planes, one job each
The architecture, quoted whole: “Jev-Mem brings this division of labor to agentic memory through a dedicated System-One control plane, a structured multi-relational memory plane, and a System-Two reasoning plane.” Three planes, one job each: the control plane makes the bookkeeping decisions on both paths, the memory plane holds the multi-relational graph those decisions build and query, and the reasoning plane answers. What keeps the split honest is the invocation rule, also verbatim: “System Two is invoked only for complex reasoning and answer synthesis.” Everything else — typing, filtering, linking, routing, budgeting, scoring, stopping — stays on the cheap side of the boundary.
Where the novelty is claimed matters, and the authors say it plainly: “Jev provides one concrete realization of the System-One controller through typed probabilistic decisions, but the key novelty of Jev-Mem is the architectural separation of lightweight memory control from deliberative reasoning across both memory construction and retrieval.” Jev is the instance; the separation is the contribution. The typed decisions lean on a cited enabler: “Jev TypeSafe AI (2026) makes such a separation practical by producing typed probabilistic decisions without autoregressive generation.” Secondary status, as this series labels such references: the citation points at typesafe.ai, a website note rather than a paper, so the mechanism's support rests on what the Jev-Mem tables show rather than on the cited page.
Mechanically, the controller is narrow, public about its plumbing, and explicit about what it never asks of the reasoning plane. Control calls run through TypeSafeClient.system_one, where Jev answers typed binary questions — the paper's “Noul” form — each carrying a value in [0,1]; the controller's size and architecture are undisclosed in the paper, and nothing is invented here to fill that gap. The code is public at github.com/libingzheren/Jev-Mem. On the retrieval side the boundary holds under load: per the paper's own description, System Two “is not involved in normal graph routing, candidate expansion, or stopping decisions.” The expensive plane fires for synthesis; the ordinary turns of a long-horizon conversation never reach it.
Scores, per authors, on the benchmark the tables report. LoCoMo overall: Jev-Mem 0.777 against the strongest baseline — MAGMA at 0.700 per the paper's Table 1 — stated by the authors as “an 11.0% relative improvement over the strongest baseline.” The evaluation backbone is gpt-4o-mini, per authors. For scale against context-oriented systems in the same table: Full Context 0.481, A-MEM 0.580, MemoryOS 0.553, Nemori 0.590. Overall row only, benchmark scope attached, hedge intact — the construction and latency tables get priced in their own sections rather than bundled into this one.
What the controller doesn't know
The authors open their own limits discussion with a question they do not claim to have closed: “How can a weaker reasoner control memory without hurting downstream accuracy?” It is the right question for any control-plane design, because the entire saving depends on substituting a cheaper reasoner for a frontier one on the bookkeeping path — and the risk is that the cheaper one mis-files evidence the final answer quietly leans on. Per authors, asked in their own paper, unanswered by their own tables.
Scope first, because scope decides what every number above is worth. Reported results cover LoCoMo only, per authors — every table quoted in this post is a LoCoMo table, and the paper's Conclusion is affirmative-only: there is no dedicated Limitations section, so the disclosures collected here are the authors' own, taken as stated. Calibration is the second disclosure: model-reported values “are not assumed to be calibrated probabilities.” The scores that steer budgets and stopping decisions are treated as signals rather than guarantees, which matters more here than in a system where the model only writes prose — in this design the uncalibrated numbers are the ones opening and closing the search.
The retrieval time budget is a soft limit, and the authors say so in as many words. The budget “is not a strict preemption guarantee for local computation,” and an active limit can terminate retrieval “even if evidence is incomplete.” Combined with adaptive stopping, that means an answer can be cut from a search the controller judged unfinished — a tradeoff the authors also state in full, quoted where the read path's budget is priced in §6, because it is a cost lever as much as a caveat.
Two design disclosures keep the claims inside their fence. Ingestion preserves observations: there is no irreversible learned store-or-discard decision at ingestion time, so a record the controller once judged low-value can still be revisited instead of lost at the door — the conservative choice for a system whose controller is explicitly the weaker reasoner. And the System One and System Two names are, per authors, an analogy for how computation is allocated — not a claim that the underlying mechanisms correspond, which is the kind of sentence more papers should print before their diagrams get over-read.
Finally, the accounting in this paper is latency, not cost. Per authors, what gets reported is construction and retrieval in wall-clock seconds; the paper prints no token or dollar accounting, and none is invented here to round the picture out. Seconds are the honest currency for a post like this — anyone re-running the system with their own model pays seconds first — but the invoice a frontier control path would charge is denominated elsewhere, and the gap between the two currencies is left open on purpose.
The construction bill
Construction time is the first invoice, and this series reads invoices before awards. Per authors, building the store against LoCoMo takes Jev-Mem 158 seconds where the fastest competing system — Nemori at 1,044 seconds per the paper's Table 2 — takes four figures: an 84.9% reduction, a 6.6× speedup, measured the same way for every system in the column. The comparison that matters operationally is against the nearest neighbor in that column rather than the slowest: the gap to the fastest baseline is already the whole story of what moving bookkeeping off generation buys.
The rest of the column spreads wider still. A-MEM 3,636 seconds, MemoryOS 3,276 seconds — both past the three-thousand-second mark — and MAGMA 1,404 seconds, per authors, same table. Four baselines, one pattern: systems that lean on generation while ingest runs pay for it in wall-clock before a single question has been asked, and because an agent's store is written turn after turn rather than once, those ingest calls compound — day one pays them, and day ninety pays them again on top of everything accumulated so far. The construction column is the least glamorous number in any memory paper and the one that decides whether a design survives contact with a churning store.
Whether the bill matters depends on which constraint binds, and both constraints point the same way here. For an agent whose store churns continuously — traces appended every session, consolidations running in the background — a frontier model on the ingest path is a recurring charge against the least glamorous part of the budget, while a store written once and read ten thousand times amortizes construction almost to nothing. The accuracy column and the construction column pull together rather than trade off: 0.777 overall and 158 seconds both fall out of the same design, per authors, so a team evaluating any control plane should ask not whether fast construction is good — it is — but whether its own workload reads more than it writes, and what generation on the write path would cost in tokens where this paper only ever reports seconds. The seconds column is legible to any team with a stopwatch and a load test; converting it into a monthly bill would take the token side of the ledger, and printing that side here would be invention rather than reporting.
The read path learns to stop
Retrieval latency, per authors, cell by cell. Jev-Mem answers in 0.93 seconds — 36.7% lower than the fastest memory baseline, MAGMA at 1.47 seconds, and 46.6% lower than the full-context comparison at 1.74 seconds. MemoryOS sits at 32.68 seconds on the same measure, with A-MEM 2.26 seconds and Nemori 2.59 seconds in between the two ends. Every figure comes from a LoCoMo table on a preprint that is not yet peer-reviewed — repeated with its hedge because latency is the number a control plane gets sold on, and because the spread between 0.93 and 32.68 is wide enough that the architecture, not the hardware, has to be doing the work.
Inside the controller, the levers are explicit numbers, printed per authors. In the active profile: graph-expansion budget 80; evidence_sufficient ≥0.95; missing_evidence/contradiction below 0.15; continue_useful below 0.15; depth 8; visited nodes 60; examined edges 2400; Jev attempts 16; retrieval time budget 15 seconds. Each one is a knob on how far traversal may run before the controller must justify another hop: a fixed expansion budget and a depth cap bound the search before any synthesis is attempted, the visited-node and examined-edge ceilings bound the graph walk itself, the Jev attempt cap bounds how many controller calls a single retrieval may spend, and the time budget bounds the wall clock — soft, per §4, and terminating “even if evidence is incomplete” when it fires. Thresholds are what make early stopping definable, which is the whole trick: an adaptive stop without a threshold is just a model guessing when it is done.
The tradeoff is the authors' own, quoted whole: “Stopping too early risks missing necessary evidence, whereas uncontrolled expansion introduces irrelevant memories that can distract downstream reasoning.” That sentence is why the profile is thresholds rather than open-ended expansion — a controller that can stop early needs a definition of early, and evidence_sufficient ≥0.95 against continue_useful below 0.15 is that definition written as configuration. The tie-back to the previous post is the same one this series keeps making: a controller can only route queries and score candidates against relations someone built, so all of these levers act on structure that typing, redundancy filtering, and the four relation types put in the graph at write time. On a store written without structure there is nothing coherent to stop against, and no threshold in the world repairs it — the cheap read control is cheap because the write path already did the organizing.
The synthesis
Split the difference the way the paper draws it: control is bookkeeping, reasoning is answering. The control plane types, filters, links, routes, budgets, scores, and stops; the reasoning plane is invoked only when the answer needs thought rather than assembly. Per authors, the System One and System Two names are an analogy for how computation is allocated — not a claim that the underlying mechanisms correspond. Read that way, the architecture is less a cognitive theory than a deployment decision that every agent-memory team faces anyway: which calls deserve a frontier model, which deserve a cheap typed decision, and who pays for the boundary between them when the conversation runs long.
At measurement level, the same split is what a temporal knowledge graph for agent memory is built to hold. In OpenZync, typed ingest and deterministic graph relations are resolved at write time, and expensive model spend is reserved for the reasoning path that actually needs it — bookkeeping stays deterministic where determinism is enough, and the frontier model is paid only for synthesis that cannot be typed into a relation. The paper's tables put a number on the direction: 158 seconds of construction and 0.93 seconds of retrieval come from keeping generation off the control path, per authors, on one benchmark, not yet peer-reviewed — the number is the illustration, the boundary is the idea worth carrying.
Where each approach earns its keep
The honest guide to the division of labor, read as jobs rather than products — and read with every claim's per authors, not yet peer-reviewed hedge intact:
| Approach | Best at | Fails at | Build when |
|---|---|---|---|
| Full-LLM memory loop | Flexible control — any distinction a prompt can state gets applied, no schema required | Frontier-model generation on every typing, routing, and stopping decision; cost compounds with turns, per the framing this paper argues against | Prototyping, where schema churn outruns any fixed rule set |
| Jev-Mem control plane | System-One bookkeeping over a multi-relational graph — 0.777 LoCoMo overall and 158 seconds construction per authors | LoCoMo-only reported tables per authors; uncalibrated scores; controller size and architecture undisclosed | Long-horizon agents whose bookkeeping volume dwarfs their synthesis volume |
| Heuristic router (no LLM) | Predictable latency and zero generation cost on the control path | Misses semantic relations — quality collapses to whatever the rules anticipated | Fixed schemas where rules already cover the distinctions that matter |
| Write-time organization | Structure fixed once at ingest — views, roles, or graph edges, so reads inherit instead of repair | Still needs an executor: rules or a model run the decisions, and the generation bill returns if a frontier model does them | Stores whose failure is missing structure rather than expensive control |
| OpenZync | Temporal knowledge graph — typed ingest and relations resolved at write time, expensive model only in the reasoning path | Routing and retention policy still operated by the team — no benchmark scores claimed | Provenance and audit matter — facts must know what they replaced and when they held |
Read the rows against the critical path, not the feature list. The first row is the design the paper's opening sentence names: maximum flexibility, and generation on the critical path of every memory operation, forever. The second row is the same flexibility pulled onto a typed control plane, and it comes with the narrowest evidence base in the table — one benchmark's tables, scores the authors themselves do not claim are calibrated, and a controller whose size nobody outside the repo can check. The third row buys its predictable latency by never asking anything semantic, which is why it wins until the schema meets a distinction nobody wrote a rule for. The fourth row is what the previous post argued for on its own, and it deliberately does not settle who executes the decisions — the row above it is one answer, a rule set is another, and the first row is the expensive default. The last row is a persistence shape where the write-side decisions are typed and deterministic and the model spend waits in the reasoning path, offered without a score these papers did not give it. Work down the table from the column that hurts: generation cost on every turn, row two; rules too brittle for paraphrase, row one or two; structure never recorded at ingest, row four; a schema so stable rules suffice, row three.
What to watch
Five signals will mark where this lands — none of them a product announcement, all of them evidence, each stated with the hedge its source requires.
Controller quality becomes a benchmarked dimension. Watch for leaderboards that score the control decisions themselves — typing accuracy, relation precision, stopping correctness, budget adherence — rather than only end-answer scores, because if the control plane is the contribution, evaluations eventually measure it directly. Per authors, this paper reports end-to-end LoCoMo outcomes, not a controller scorecard; whether independent evaluations add the scorecard is the open question, and the answer would show up as new columns rather than new claims in abstracts.
Typed controllers spread past the paper that borrowed them. Typed binary decisions with bounded outputs are portable — a system that never cites Jev-Mem can adopt a TypeSafe-style controller for routing or deduplication and describe it in plain terms like rule-scored control or bounded-decision ingest. Watch for that vocabulary appearing in changelogs, and watch for the secondary-status caveat to matter: the cited enabler is a website note, so any spread will need its own evidence rather than inherited credibility. Whether the spread happens is not a certainty — most teams will keep generation on the path because it is the default — but the direction worth monitoring is control decisions showing up as configuration instead of prompts.
Construction time becomes a reported metric instead of an afterthought. The 158-versus-1,044-second column is the shape of accounting this field could standardize on: seconds to build, seconds to answer, and — where anyone measures it — how often the expensive plane fired. Watch for construction figures moving from appendix tables into abstracts, and for reviewers asking the same question of every memory system: what does the store cost to build before it answers anything. Per authors, this paper reports seconds and stops there; the teams already paying ingest bills in tokens will care first, because for them construction time is not a diagram — it is an invoice.
System-Two invocation rate turns into a cost key performance indicator. The design's savings live entirely in how rarely the reasoning plane fires, which makes invocations per conversation the number that decides whether the separation pays for itself in production. Watch for that rate appearing next to latency in dashboards — high rates mean the cheap controller is offloading nothing, low rates mean the boundary is holding — and watch for it to be reported per task type, because synthesis-heavy workloads will pull it up regardless of controller quality. The paper does not publish this rate, per authors; its absence is exactly why it is worth watching for.
LoCoMo-only results either hold or narrow. Every score in this post hangs on one benchmark, disclosed as such by the authors, on a preprint that is not yet peer-reviewed. Watch for replications on other long-horizon evaluations, and watch just as carefully for the opposite outcome — control-plane gains that shrink when the conversation structure, relation density, or query mix changes. Neither outcome is foretold; what is worth monitoring is whether the 11.0% relative improvement over the strongest baseline survives contact with benchmarks its tables never covered. Until that answer arrives, every figure in this post keeps the two hedges it arrived with: one benchmark's tables, one preprint that is not yet peer-reviewed.
Memory that doesn't need a genius to file it
The lesson this series keeps re-learning now has a price attached to the executor. Filing was never the genius part of memory: typing a record, dropping a duplicate, drawing a temporal edge, routing a query, deciding a search has seen enough — none of it is reasoning, all of it was being priced as reasoning, and one September preprint's tables put the difference at 84.9% of construction time and 36.7% of retrieval latency, per authors, on a single benchmark, not yet peer-reviewed. The correction on offer is not to build a smarter filing clerk. It is to stop sending the filing to the smartest and most expensive engine in the building, every turn, forever — and to reserve deliberation for the turns that actually contain a question worth deliberating about.
OpenZync is a self-hostable temporal knowledge graph for agent memory — typed ingest and relations resolved at write time, expensive model only in the reasoning path. Start with the memory & context docs and the openzync-mcp repository.
This is part of a series on agent memory. Read why context windows aren't memory, then how a temporal knowledge graph is built, then the honest map of agent memory tools, then the five patterns of graph memory, then the MCP memory-server field guide, then when agents talk to each other, who remembers, then the new attacks on AI memory, then team memory and who fixes a wrong fact, then the gap between benchmark scores and agentic memory, then what happens when agents remember things that never happened, then your agent doesn't need a knowledge graph, it needs a search box, then context engineering won't fix your agent's memory, then everyone ships an llms.txt, almost no agent reads it, then your agent's memory file is how mind viruses spread, then MCP and A2A have a foundation now, then the right to be forgotten meets agent memory, then cheap memory is the expensive option, then your RAG pipeline is not how ChatGPT remembers you, then your agent loses its mind after fifty turns, then smarter retrieval won't fix messy memory, then the post that started it all.