Curate, Don't Accumulate: Lean Memory, Mergeable Code, Shared Context

6% on a 500-question benchmark. 2, so the lean version was 10 points more accurate while using roughly one-eighth of the tokens. Rated by the official judge, statistically airtight, zero errored questions out of 500. That comes from a system called Engram, from Lui and Wang, and it’s the cleanest version of an idea that turned up in something like half a dozen separate papers this week.

The agent’s problem was almost never too little context. It was too much of the wrong context. Let me stay on Engram for a minute. Because the architecture is the interesting part, not just the headline.

The right path is deliberately wrong. The right path is deliberately wrong. The right path is deliberately dumb and fast. When something happens it just appends a lossless episode.

No language model anywhere on the critical path. So writing is cheap and you never lose the raw record. Then a separate asynchronous path does the slow, careful work. It pulls out atomic facts and builds what they call a bitemporal knowledge graph.

Bitemporal meaning it tracks both when something was true in the world and when the system learned it. When a new fact contradicts an old one, it doesn’t delete the old one. It marks it invalid and keeps it, with a supersession chain, so every fact retains its provenance. You can always ask what the system believed at a particular point in time.

The read path then fuses several signals together. Dense vector similarity, plain lexical search, the graph structure, and recency, applies an as-of filter so you’re reasoning about the right moment, and hands back a compact context where every piece is tagged with where it came from. And there’s a second context. There’s a second contribution buried in that paper that I think matters as much as the engine.

Wang ships a neutral evaluation harness, with the official judge baked in, and the full history baseline sitting in every single results table. That’s a direct shot at a real problem in this corner of the field, which is that memory benchmarks have been a mess. The same system gets reported at completely different scores in different papers because of truncation, homegrown judges that don’t match the official one, and full history leaks where the supposedly lean system is quite a mess. The same thing happens in the case of memory benchmarks, where every number ships with a command to reproduce it.

That’s the standard the whole subfield should be held to. Now Engram wasn’t alone this week, and that’s what makes it a theme rather than a one-off. Two other memory designs landed in the same window, reaching for the same instinct from different directions. One is called infinite memory, and, instead of a knowledge graph, it treats memory as topic-structured documents.

New observations get staged in a buffer. Then periodically consolidated into coherent text organized by topic. And at retrieval time, the model reads through iterative tool calls rather than one single grab. It scores about 65% on its benchmark.

The other paper frames memory retention as a constrained optimization problem, deciding what to keep under an explicit budget, rather than the usual heuristic scoring where you just slap a salience number on everything. Different architectures. Knowledge graph versus topic documents. Versus optimization.

But one shared premise underneath all three. Structure the store and revise it over time. Don’t just pile up raw records and pray that retrieval sorts it out later. A vector database company, Weeviate, put the same point in one line this week.

Shoving more chat history into the context window is not memory. Okay, so that’s the memory side. The evaluation papers this week show you exactly what it costs when you get this wrong. And the big one is frontier code.

From Cognition and METR. The finding that got everyone’s attention is that more than half of the solutions that pass SWE-bench, the benchmark a lot of people have been quoting all year, are unmergeable slop. Code that passes the tests but no maintainer would actually accept. Frontier code was built to catch that.

Each task took more than 40 hours of work from leading open source maintainers, over a thousand hours in total. And it comes with more than 3,000 rubrics that grade code quality and watch specifically for reward hacking. The headline number is brutal in a useful way. 8%.

The framing they use is three eras of coding benchmarks. 2021 was autocomplete, measured by HumanEval, 2023 was passing tests, measured by SWE-bench and Terminal-Bench, and 2026 is maintainable code. The era where the question stops being does it run and becomes would you actually merge this. There’s one more thing in that release worth sitting with.

SWIKE asked for a historical run across older models, and on the easiest third of tasks, Opus jumped from a 41% pass rate to 74% in just four months. That’s the quantitative shape of something a lot of people felt around December of last year and couldn’t quite name, the sense that the tools suddenly got dramatically more reliable. The way he frames it, it’s the difference between getting to 95% success in two retries versus six retries. And that gap is exactly what decides whether you can leave an agent running in a loop unattended without it going off the rails.

It’s the dividing line between supervised assistance and the autonomous loops people are starting to actually run. Which is why the next paper is such a good companion piece. It’s called CapCode, and it’s a clever inversion of how you catch a cheating model. Normally you try to anticipate every shortcut a model might exploit and patch each one, which is a losing game.

CapCode instead builds coding datasets with randomized tests. And that’s exactly what decides whether you can leave an agent running in a loop unattended without it going off the rails. It’s the same goal FrontierCode’s anti-cheat rubrics are chasing, approached from the opposite end. So if a model posts a score well above that cap, that’s not impressive, that’s impossible.

And the impossibility itself is your evidence of cheating. They pair it with a reward design that discourages optimizing past the cap during training. And the nice property is that it still preserves the ranking between models, it just flags the deception. That’s the same goal FrontierCode’s anti-cheat rubrics are chasing, approached from the opposite end.

And that’s exactly what it’s doing. One designs the test so cheating is visible, the other hand-grains for it. Underneath, both the memory story and the eval story sits retrieval quality. And there’s a benchmark this week that isolates exactly that, called SWE Explore.

Instead of scoring an agent on whether it ultimately fixed the bub, it hands the agent a repository and an issue, and asks one narrower question, give me a ranked list of the relevant code regions under a fixed line budget. And the ground truth is clever. They derived it line by line from independent agent trajectories that actually solved the same issue. So the answer key is the specific code that real successful solutions actually looked at.

Across 848 issues, 10 programming languages, and 203 repositories, the finding is that agentic explorers, agents that actively navigate the repo, form a clear tier above classical retrieval methods. Finding the right file is mostly solved now. The frontier is line-level coverage. And efficiency is key.

It’s important to be able to get the right lines, in the right order, without blowing the budget. Which is the same compact and correct target Engram is optimizing for on the memory side. Same problem, different layer of the stack. And then the orchestration layer rhymes with the memory layer so closely, it’s almost funny.

There’s a paper called DELM from Yujin Mao and Azaliya Mirhosini on decentralized multi-agent systems. Most multi-agent setups today use a central controller, a main agent that hands out work, collects everyone’s output, and gets the most out of the system. As you add subtasks, that controller becomes a bottleneck, both for communication, and for integration. DELM drops the central controller entirely, and replaces it with a shared verified context plus a task queue.

Agents asynchronously claim subtasks, read the accumulated progress so far, do their local reasoning, and write back compact verified updates that everyone else can build on. No routing every message through one coordinator. And it works. On SWE-bench Verified, it takes the top spot across the board.

And it works. It’s easy. It takes the top spot across the board. It takes the top spot across every metric they report.

5 points over the strongest baseline, while cutting the cost per task by about half. It adds almost 6 points on a long-context multi-document benchmark, too. Step back and look at the shape of that result. A shared, curated, verified substrate beats funneling everything through one big context.

That is the exact same finding Engram reported. Just moved up a level, from one agent’s memory to a whole swarm’s shared state. So that’s the week. Memory systems.

Evaluation. Repo exploration. And multi-agent orchestration. Four different subfields, all landing on the same conclusion in the same few days.

Curate, don’t accumulate. And all of it is happening while adoption keeps climbing. A follow-up study of coding agent use in new GitHub projects found it more than twice as high as the previous cohort, and more intensive in how it’s used. The thing I’d watch from here goes back to where we started.

Engram’s whole argument is that memory benchmarks aren’t reproducible enough to compare systems honestly. That the scores floating around are measured on inconsistent harnesses. So the real question for next quarter isn’t who posts the highest number. It’s whether Engram, InfiniMemory, and the rest converge on one neutral shared harness, or keep grading themselves on their own.

Because until they do, every impressive lean-beats-full result is hard to trust against the one published next to it.