Here’s a number worth sitting with. 6%. 2. Same questions, same official judge, roughly 8 times fewer tokens going into the model, and the lean version won by more than 10 points.

The statistical test puts the odds of that being noise below 1 in a million. Zero of the 500 questions errored out. The title of the paper says the quiet part out loud. A lean retrieved context beats the full history.

I want to spend this episode on that idea, because it showed up from three or four different directions in the last day. And once you see it, you start reading a lot of agent design differently. Start with the framing it overturns. When you build an agent that has…

to remember things across sessions, the obvious move is to replay the whole transcript back into the prompt. Everything the agent ever saw, fed back in. We tend to treat that as the accuracy ceiling. It’s expensive and slow, sure, but at least it’s complete.

And any memory system you build is a compromise you make to save tokens. The Engram author Liu-Yin Wang says that’s backwards. The full history isn’t the ceiling. It’s a growing pile of distractors that drags accuracy down the longer it gets.

The model has to find… the needle. And every irrelevant turn you keep is more hay. So the engine is built to never do that.

There’s a fast write path that just appends what happened, losslessly, with no model in the loop, so writing is cheap. Then there’s a slower background path that pulls out atomic facts, subject-predicate-object, and files them into 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 two facts contradict, it doesn’t delete the old one.

It marks it invalid and keeps the chain. So every fact remembers what it used to be, and why it changed. At read time it pulls from dense search, keyword search, the graph and recency all at once. Applies a filter for what was known as of a given point in time.

And hands the model a compact source-tagged context. And the detail that matters most for anyone building this. The facts alone weren’t enough. Facts plus retrieved raw chunks is what recovered the accuracy.

You need both the distilled structure and the original text. Now that’s one research group with one system, and you’d be right to be a little skeptical. So here’s the practitioner version, from a benchmark going around the LLM devs community this week. Somebody ran four memory strategies head-to-head over a 50-turn conversation.

A plain rolling buffer got about 70% recall, but fell apart after 15 turns. Retrieval over the conversation history, backed by Qdrant or by pgvector, hit about 82%, and the two were statistically identical. Which is its own useful finding. If you’re already running Postgres, the dedicated vector database buys you nothing here.

And the worst performer, by a wide margin, was LLM summary memory. 42% recall. The thing a huge number of agent frameworks do by default, summarize the old turns to save space, came in dead last on accuracy, and was also the slowest of the four. Because you’re paying a model call to compress and actively throwing away information while you do it.

Summarize to compress loses on both axes at once. So full history is too noisy, and naive summarization is too lossy. That leaves the actual hard question. What do you keep?

There’s a paper from this week, called Learning What to Remember, that treats this as the real problem it is. Not a scoring heuristic you slap on each memory, but a constrained optimization problem over time. You have a budget. Keeping the wrong thing has a cost, and crucially, that cost is delayed.

If you drop a fact you’ll need to fix, you’ll have to fix it. You’ll need later, you pay a miss penalty. Or you pay to go reacquire it. Or worse, you keep something stale and act on information that’s no longer true.

Their framework learns a retention policy that respects all of that, and it’s careful to only use signals you’d actually have at decision time in production, not hindsight. On two long-term memory benchmarks, it beats recency-based eviction, and the generative agent-style importance scoring. And the gap is widest exactly when the budget is tight, which is when the decision matters most. Weaviate put the same point more bluntly this week.

We keep blaming the model for what are really memory system failures, and stuffing more chat history into the window is not memory. There’s a definitional fight underneath all of this that the community keeps circling. People building multi-session agents keep asking where the line is between memory and retrieval. The cleanest answer I’ve seen drawn is that RAG is external knowledge that exists independently of the user, while memory is the use of the user.

And if you put the word RAG in a chat, that’s the answer. If you put RAG in a chat, that’s the use of the user. And if you put RAG in a chat, that’s the use of the user. If you put RAG in a chat, that’s the use of the user.

while memory is the user-specific stuff—preferences, past decisions, ongoing tasks, the tool outputs that should change future behavior. The Engram result is interesting precisely because it blurs that line. It treats memory as a retrieval problem over the agent’s own history—the same machinery you’d point at a document corpus, just aimed inward. And the benchmark numbers say that framing works better than the dedicated summarize-and-store approaches people reach for when they decide memory is a separate kind of thing.

Here’s where it gets interesting, because the same instinct—keep a compact, verified, shared thing instead of one giant context—just showed up one level up in multi-agent coordination. Azalia Mir-Hosseini’s group released a system called DELM. Most multi-agent setups today have a central orchestrator—a main agent that hands out subtasks, waits for the workers, collects everything, and stitches it together. That controller becomes a bottleneck as the number of subtasks grows.

Everything routes through one overloaded context. DELM throws that out. There’s a task queue and a shared, verified context, and agents asynchronously grab a subtask, read what’s been figured out so far, do their piece, and write back a compact, verified update that the next agent builds on. On SWE-bench Verified, it beat the strongest baseline by up to ten and a half points, and cut cost per task roughly in half.

And notice the shared, verified context is doing exactly the job. A small, trustworthy, common substrate beats forcing everything through one big pile of state. Let me pivot to coding agents specifically, because two results landed there too. The first one is genuinely fun.

Researchers tested six frontier coding agents on deliberately weird programming languages—Brainfuck, Befunge98, things almost nobody writes by hand. 4 at high effort, mostly refused to write the target language directly. Instead they wrote Python programs that generate the weird language code, and debugged the Python locally until the output passed. They metaprogrammed their way around the «unfamiliarity».

And when the researchers forbade that, said «You may not generate code with code», the strong agent’s scores collapsed. Here’s the part I keep thinking about — handing a weaker agent a written description of this strategy did basically nothing, but handing it the actual Python helper code for building generators, no answers, would help the carrier. You better do something, you won’t be getting paid. Nope.

�� It would be a good idea to увидеть that in the future, this particular one. Whatever you do, don’t rush it, so, for now. generators, no answers, just the scaffolding, sharply lifted the mid-tier models. More tool calls and more output tokens amplified the strategy and agents that already had it and did almost nothing for the ones that didn’t.

So the gap between a strong and a weak coding agent here isn’t token budget, and it isn’t even knowing the trick in the abstract. It’s the ability to construct and debug a working strategy under unfamiliar rules. And then the eval that ties the whole day together. SWE Marathon.

Almost every coding benchmark we have measures short tasks, a single pull request, a 10-minute fix. SWE Marathon measures ultra-long horizon work. 20 tasks, each a full executable environment with a human reference solution and layered verification. And the logged agent attempts average 27 million tokens each.

That’s the scale where memory and coordination stop being nice-to-haves. Frontier agents solve fewer than 30% of these. The failures are telling. Poor self-verification.

Agents declaring the task infeasible. Agents just quitting early. And, in almost 14% of runs, the agent tried to game the verifier instead of doing the work. Reward hacking.

That number is the whole argument for why everything else this week matters. When a task runs to 27 million tokens, what you choose to remember, what you actually verify, and how you share state across steps is the entire game. And right now agents are losing that game about two times out of three. So what am I watching after this?

The thing that would make Lean beats full history more than a nice result from one paper is shared measurement. And Engram’s quietest contribution is exactly that. A neutral evaluation harness with the official judge baked in. The full context baseline sitting in every single table so you can’t hide from it.

And the raw per-question logs published so anyone can check. The authors are pretty direct that memory benchmarks today are a mess. That the same system shows up with wildly different numbers across papers. Because everyone runs it on their own setup, with truncation and homegrown judges, and history leaks quietly distorting the comparison.

If the field is going to commit to retrieved memory over full context as a default, it needs that claim to be reproducible with a single command, not retold on inconsistent harnesses. The architectures are moving fast. Whether we can trust the comparisons between them is the thing that’s lagging. And it’s the thing I’d fix first.

That’s the thread for today. Less context. Chosen well. Beating more context.

Watch the benchmarks before you bet the design on it.