Same model, +10 points on Oolong: today's gains came from the harness

Here’s the number that anchors today. Take a long context reasoning benchmark called Oolong, hold the model fixed at GPT-5, and run a coding agent that does the obvious thing, loop a regex over the document and extract answers. 75%. Now keep the exact same model but change how the agent is wired.

Instead of one regex loop, let the parent agent write a script that spawns a fresh agent harness for each entry in the document, each with its own context window and its own tools all running in parallel. 36%. 77. So almost 10 points, sometimes more, with the model held constant.

The gain came from the scaffolding, not the weights. That paper called Recursive Agent Harnesses out of a team at PwC is the cleanest illustration of the thing that ran through the whole last day of work. The system you build around the model is increasingly where the performance lives. Look closely at what that paper is actually saying, because it names a pattern a lot of us have been building without a name.

There are two older ideas it sits between. One is recursive language models, where you recurse over plain model calls to chew through a context too big for the window, but those calls have no tools, no file system, they can’t run code. The other is the Oolong. The Oolong is the ordinary coding agent which has all the tools but only one context window, so when a task has thousands of independent entries it can’t reason about each one, it collapses the whole thing into a regex loop and skips the per-entry thinking entirely.

Recursive Agent Harnesses says, make the recursive unit a full harness. The parent looks at the document, decides how to split it, writes actual Python that fires off one task per entry, and each of those tasks is itself a complete agent with its own window, its own files, its own ability to spawn more sub-agents down to some depth limit. Because the spawning is just code, not a rigid tool schema, the parent controls concurrency and instructions and where outputs land, all in the same language it’s already reasoning in. And the authors are explicit that this isn’t theoretical, they point straight at anthropic’s dynamic workflows, where a coding agent writes code that orchestrates sub-agents at scale, and they treat the fact that it’s shipping in a real product as evidence that recursing over-harm is not a good thing.

And they treat the fact that it’s shipping in a real product as evidence that recursing over-harm is not a good thing. With the same model and different harnesses, is becoming the default move for anything bigger than a single context window. What I like here is the discipline of the experiment. They held the backbone fixed specifically so you can’t hand-wave the result away as a better model.

Same model, different harness. 10 points. That’s a clean attribution. Everything else today was about memory, and it came at the problem from three directions that don’t usually show up in the same conversation.

The first is capacity. There’s a paper called the power of memory, which is about memory and it’s about a push and run of your chips. called Memrefine that formalizes something it calls storage-budgeted memory management. The setup is mundane and real.

You’ve got an agent that’s been running a long time, its memory store has grown without bound, and you need to get it back under a fixed budget without throwing away the things future tasks will need. The naive approach is to use similarity, find near duplicates by embedding distance and prune. Memrefine’s whole argument is that surface similarity is a bad proxy for factual value, so it uses similarity only to propose candidate pairs, and then it hands the actual decision, delete this, merge these two, or keep both, to an LLM judge that reasons about the factual content, and it iterates until the store fits the budget. Across several memory frameworks and long-term conversation, benchmarks it consistently meets the budget while holding downstream accuracy, and it pulls away from rule-based pruning precisely when the budget is tightest.

That last bit. is the real finding. Recency and embedding proximity are the wrong things to optimize when you’re deciding what to forget, and they fail hardest exactly when you can least afford a wrong eviction. The second direction is coding agents specifically, and a project called PROJCTMEM.

It opens with a cost number worth holding onto, reconstructing project context at the start of a session, rereading files, rederiving decisions, rediscovering which fixes already failed, costs somewhere between $5,000 and $20,000, and a total of $100,000 tokens every time. And the bottleneck there isn’t the model being dumb, it’s that the project memory just isn’t there. So PROJCTMEM records your development as an append-only, plain-text log of typed events, issues, attempts, fixes, decisions, notes, and then deterministically projects that log into compact summaries it serves to the agent over MCP. But the part I find genuinely interesting isn’t the storage, it’s what they call the gate.

Before the agent acts, there’s a lot of deterministic pre-action check that warns it when it’s about to repeat a fix that already failed, or edit a file that’s known to be fragile. They call the idea memory as governance, memory that doesn’t just answer the agent’s questions but actually intervenes on its next action. It ships as a tiny Python package, three dependencies, runs fully offline with no telemetry, and the immutable log doubles as a provenance trail you can audit later. I’ll be honest about the evidence, it’s a two-month self-study across ten of the author’s own projects, two hundred and seven logged events, so this is a framing contribution more than a benchmark result.

But the framing, memory that acts rather than memory that answers, is the part worth stealing. The third direction is the price of all that persistence, which is security. There’s a survey out on long-term memory security in LLM Agents, and its core claim is that writable, cross-session memory is a fundamentally different threat class than the prompt injection we already worry about. Three properties of memory are the following.

First, it’s the ability to make it different, persistence, the bad data sticks around, statefulness, it changes the agent’s behavior going forward, and propagation, it can spread. The survey lays out a memory life cycle, six phases from writing and storing through retrieving, executing, sharing and finally forgetting and rolling back, and maps where attacks and defenses live across all of them. And its conclusion is pointed, you cannot retrofit this kind of security at retrieval time or execution time by filtering what comes back out. It has to be anchored at storage time, with provenance, versioning and retention policy baked in from the start.

And the concrete attack that makes this vivid landed the same day, in a paper introducing what it calls multi-session memory poisoning. The attacker never touches the weights or the code, they just interact with the agent through completely normal channels and plant memories that, once those memories get retrieved later, steer the agent’s answers for future users. Think about that next to PROJCTMEM’s append-only log and the surveys call for storage time provenance. Those are two answers to the same question coming from opposite directions, one from the builder who wants reproducibility, one from the attacker who wants to corrupt it.

Now here’s where it gets practical, because all of this abstract memory talk has a very hands-on version, and it showed up on the Claude Code subreddit. md files of the 155 most starred typescript, Python, Rust on GitHub, 43% of them ship one. The median is roughly in line with Anthropic’s own guidance to keep these files short, under a couple hundred lines. But the outliers are wild, Bun’s file is 75,000 characters.

OpenClause is seven times the median in token count, and the orthodox view says big files are a mistake, that bloat causes the model to start ignoring instructions, and there’s context-wrought research backing that up. OpenClause files belong to the most agent-native teams, the ones where agents are doing most of the work, and when you look at what’s in OpenClause file, the bulk of it is verification gates that read like scar tissue, rules added every time an agent hallucinated something. So who’s right, is that bloat a bug or is it load-bearing? And notice that’s the exact same delete-merge-preserve judgment Memrefine is trying to automate, just scaled down to a file a human edits by hand.

We don’t have a principled answer yet for either one. Retrieval got its own correction too, and it rhymes with the memory story. A paper called Code2R goes after the assumption underneath most of our retrieval systems, that semantic similarity is a good enough stand-in for relevance. The failure case is sharp.

On a query with a constraint in it, a document can be topically very close to what you asked while supporting the exact opposite, satisfying an attribute you wanted excluded, or affirming a relationship you wanted negated. They call it constraint-violating evidence, and the cruel part is it ranks high precisely because it looks so similar. That’s the same lesson Memrefine taught on the memory side. Similarity is cheap, and it’s frequently wrong about what you actually want.

And to close the loop back on harnesses, one product note. Xiaomi released an open-source agentic coding harness called MemoCode, and they’re claiming it beats Claude Code on ultra-long tasks, the 200-plus-step variety. Take the leaderboard claim with the usual grain of salt, vendor benchmarks, being what they are, but the direction is the tell. It’s the same bet as recursive agent harnesses and the same bet as dynamic workflows, more deliberate orchestration pointed straight at the long horizon.

So what am I watching from here? Two things. The harness gains are real but they’re measured on synthetic Oolong data, and the authors themselves flag that generalizing to messy real-world long-context corpora is still open, so I want to see that number hold up off the synthetic benchmark. And the memory security work and the memory poisoning attack showed up on the same day, which tells you the race is on.

The question is simply which side ships first into the agent’s people are already running every day. That’s the one I’d keep an eye on.