AI Engineer World's Fair 2026
Memory Harnesses for Long-Running Research Agents
Read the talk
Memory Harnesses for Long-Running Research Agents
A local research-agent experiment shows when durable memory helps, why ranking matters more than simply enabling recall, and how correct evidence can still produce a wrong answer.
From a talk by Stefania Druga
Before you start: Familiarity with language-model context windows, tool-using agents, and retrieval-augmented generation will help; the Python example requires only basic Python.
When the agent forgets the work
An agent starts contradicting itself. It repeats a task it already completed, or drifts away from the question it was supposed to answer. These are the concrete failures behind context bloat: a longer history does not guarantee that the model retains a usable account of its work. Stefania Druga, introducing herself as a research scientist at Sakana AI in Tokyo, uses these failures to motivate experiments with memory harnesses for research agents running on-device.
Longer tasks make that problem harder to avoid. Druga points to METR’s task-completion time horizons as evidence of growing task scope. Those horizons measure human-expert task duration at a specified model success probability, rather than uninterrupted autonomous runtime. She pairs that trend with her observation of fewer model releases and forecasts a convergence later in the year: more long-horizon work, with fewer opportunities to rely on a new model to fix its weaknesses. The release-frequency claim and convergence are her interpretation, not measurements established by METR’s chart.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A local model and a Mac surrounded by fans
The motivation for running locally is partly economic. Druga recounts a recent Coinbase CEO post reporting lower AI spending alongside increased usage. In her account, the change combined more local models with better routing, caching, cleaner context, and visibility into which tasks consumed AI resources. Memory management belongs in that same operational picture: what reaches the model affects both its behavior and the bill.
The capability threshold is changing too. Druga cites enthusiasm around GLM, briefly referring to “Fable going away,” and describes DeepSeek V4 Flash running on an M3 Ultra. RAM remains a bottleneck, but her reason for experimenting now is that local models are becoming useful for agentic tasks and tool use.
Her evaluation machine is a Mac in Tokyo, controlled from her phone while the talk is underway. After days of continuous evaluations, it became hot enough that her husband placed additional fans around it. The host is an M3 Ultra with 96 GB of memory and 28 CPU cores; the two models are Qwen 27B, quantized to four bits, and DeepSeek V4 Flash. The photograph makes the operational setting tangible: these experiments run on one machine, with physical cooling and throughput constraints.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Memory is a write–manage–read loop
Memory is a control loop around the model, not just a database. Writing determines what becomes a memory; management determines how it is organized and retained; reading determines what returns to the model at the moment of use. Druga starts with research agents built using smolagents, with no durable memory in her experimental configuration, so that the harness supplies the memory being tested.
The harness separates three concerns:
- Core: traces that are always shown to the agent.
- Recall: the variable block that selects memories for the current task.
- Archive: information retained across sessions.
Keeping these roles separate makes the recall block an experimental variable instead of mixing every form of persistence into one feature.
The recall experiment climbs a policy ladder:
| Policy | What enters the recall block |
|---|---|
| No recall | Nothing |
| Vector RAG | Memories retrieved by similarity |
| Decisions ledger | Per-turn decisions, prioritized for recall |
| Oracle | The correct memory supplied as ground truth |
The ledger preserves decisions made during individual turns so that they can be prioritized later. The oracle supplies the memory that ought to be retrieved on each loop. Druga holds the model fixed while changing the recall-block variables, making it possible to study the harness separately from a model upgrade.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When all the evidence already fits
The first task is a literature review with an evidence imbalance. Druga describes a Nature paper claiming 742,000 promising materials and says the claim was later retracted. In her corpus, the prominent original claim has headlines and citations behind it, while the retraction is a much smaller piece of evidence. The question is whether the agent can recover the correction rather than reproduce the more conspicuous claim.
For this literature-review task, Druga reports the same performance with and without memory, while memory added cost. All the papers and relevant information already fit in the context window. The experiment therefore establishes a useful boundary: external memory did not add capability merely by existing. The model already had access to the evidence it needed.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The answer is at step 124; the question arrives at step 500
The next experiment changes the availability of evidence. In the long-horizon benchmark Druga calls XBench, the answer appears at step 124, but the agent is asked for it at step 500. By then, that earlier evidence lies outside the active context window. A successful answer requires the harness to bring back the relevant earlier record.
The displayed example asks for the name of the count of Apulia. Its comparison marks Roger II as the incorrect gate-only answer and Robert Guiscard as the correct rank-only answer. Druga tests this kind of question with memory disabled, with different recall policies, and with oracle-provided memory. The distinction is now concrete: a policy must recover the right earlier evidence, not merely decide that some memory might be useful.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Retrieving the right memory is only half the problem
Across 68 XBench questions, with multiple experimental cells and seeds, Druga reports that the rank-only ledger performed best, outperforming a gate that decided whether memory was needed. Ranked recall also produced correct answers more frequently than running without it. The useful distinction is between deciding whether to recall and deciding which memory deserves priority. The reported experiment favors the latter intervention.
The oracle does not reach perfect performance. It supplies the correct memory, but it cannot force the model to use that memory correctly. The model may ignore it, become confused, or still select the wrong information. Correct retrieval and correct evidence use are separate failure points. An oracle condition removes the need to discover the right memory; it does not remove the rest of the reasoning task.
A small Python evaluation boundary makes that separation explicit. Using the count-of-Apulia example, the recall policy first selects records; an answer function then receives those records. The oracle chooses step 124 directly, while an ordinary policy must select from the archive. The abbreviated record below illustrates the boundary rather than reproducing Druga’s harness implementation.
python
from collections.abc import Callable, Sequence
from dataclasses import dataclass
@dataclass(frozen=True)
class Memory:
step: int
text: str
Recall = Callable[[str, Sequence[Memory]], Sequence[Memory]]
Answer = Callable[[str, Sequence[Memory]], str]
question = "What is the name of the count of Apulia?"
archive = [Memory(124, "The count of Apulia is Robert Guiscard.")]
def no_recall(question: str, archive: Sequence[Memory]) -> Sequence[Memory]:
return []
def oracle(question: str, archive: Sequence[Memory]) -> Sequence[Memory]:
return [memory for memory in archive if memory.step == 124]
def evaluate(recall: Recall, answer: Answer) -> dict[str, object]:
recalled = list(recall(question, archive))
prediction = answer(question, recalled)
return {
"recalled_steps": [memory.step for memory in recalled],
"prediction": prediction,
"correct": prediction.strip().casefold() == "robert guiscard",
}
Even when recalled_steps contains 124, correct can remain false. Keeping both fields makes that failure visible instead of treating successful retrieval as a successful answer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Bad memory spends tokens in the wrong direction
Druga also changes what the harness supplies: arbitrary examples, evidence from the wrong step, and evidence from the most recent step. These ablations probe whether the benefit comes from relevant selection rather than simply adding text or favoring recency. Druga reports that ranked recall remained the best-performing condition in these ablations, with benefits on both Qwen 27B and DeepSeek V4 Flash. She also reports testing on a benchmark she calls SpiderV2, without specifying the variant.
Druga reports that structured recall reduced token use and cost in the long-horizon experiments, without giving numerical savings. Irrelevant memory consumes context directly, but it can also send the agent down an unproductive path. The cost of a bad retrieval can therefore extend beyond the tokens used to insert it: the agent may spend further turns acting on it. A recall policy affects both evidence quality and the work that follows.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make recall policy an evaluation target
The engineering implication is to treat recall policy as a first-class evaluation target. That requires explicit choices rather than a single memory-enabled switch:
- Memory contents: which facts, decisions, or traces should be stored?
- Ranking: what makes one record more useful than another for this question?
- Recall function: how does the harness select what the model receives?
- Persistence: what survives repeated runs and multiple sessions?
These choices determine the information available at the point of action. Evaluating them separately helps distinguish a storage problem from a selection problem or a failure to use retrieved evidence.
The ledger experiment occupies only one part of a much broader landscape. Druga points to an open-source cookbook collection she attributes to Diamond, describing more than thirty runnable examples. She then broadens the design space to short-term and long-term memory, cognitive techniques, and the use of evaluation results. Approaches range from simple filesystem retrieval to trained memory models, with different degrees of structure. The central design question remains what to retain and how to make it useful on a later turn.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Control over the pipeline has a throughput cost
Running locally gives Druga control over the data, the complete compute traces, and the evaluations. That control is what she means by sovereignty in this experiment: the ability to inspect and change every step of the pipeline. It also makes the harness a useful research instrument, because the model, memory policy, and evaluation conditions can be managed together.
The operational cost is time. In Druga’s local setup, DeepSeek V4 Flash queries ran serially, without batch querying. That is a limitation of the reported setup, not a model-wide prohibition on batching. Evaluations took long enough to continue on the machine in Tokyo during the talk; she had also run them during her flight. Complete control did not mean high throughput.
For Druga, the ability to control and measure the entire pipeline still makes local experimentation worthwhile. She connects that capability to Sakana AI’s broader commitment to sovereign AI in Japan, closing with an invitation to people interested in joining that work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Explains how METR measures task horizons using human completion times and model success probabilities.
Official model specifications, reasoning modes, evaluation tables, and local inference instructions.
Further reading
Nir Diamant's collection of 30 runnable notebooks covering memory buffers, retrieval, graphs, memory frameworks, and evaluations.
Benchmark datasets and evaluation tools for enterprise text-to-SQL and repository-level data workflows.
Hugging Face's lightweight library for building agents that execute tools and code.
Read the complete timestamped transcript
- 0:00
[on-hold jingle] Hello. Welcome. Uh, this is a big room, so you're...
- 0:16
if you're in the back, don't hesitate to come closer. Um, my name is Stefania Druga. I'm a research scientist at Sakana AI in Tokyo. Uh, I used to be based here, and AI engineering, uh, is home community for me before being the Hyperloop, so it's very good to be back.
- 0:34
And today, I'm gonna talk to you about memory harnesses for long-running research agents on-device.
- 0:42
So if you work with long-horizon tasks, you probably ran into this issue of context bloat, right? Like, when the model starts contradicting itself, or it has to redo the work because it forgot it did that task in the first place, or it starts to drift from your questions because it forgot them.
- 1:03
And this, this matters now more than ever because from this recent projections from Meter, we see that the trend is to solve longer and longer, uh, horizon tasks, and also that we're getting fewer and fewer model releases.
- 1:20
So at some point later this year, we're gonna have this convergence, right? Where we'll get many more long-term horizon tasks and fewer model releases. So that makes this issue of dealing with context rot a priority.
- 1:36
And why did I wanted to, to tackle this problem on local models and with a local harness? Uh, maybe some of you have seen this tweet. It's only two days old.
- 1:46
Uh, the CEO of Coinbase actually shared how their company managed to reduce their AI spend while actually increasing, uh, the AI usage. And the way they did that was by transitioning to use many more local mo- uh, models, but also having better practices like using better routing, better caching, keeping the context clean, and then having better
- 2:11
visibility for what people are using it for what. Uh, what kind of task. So we are seeing the local models, like, crossing the line, right? Like, GLM is on everyone's minds, like, especially with Fable going away.
- 2:26
Uh, DeepSeek V4 Flash can now be run on, uh, M3 Ultra. And there's still a bottleneck for RAM. It's tricky. But these local models are starting to be useful for agentic tasks and for tool use.
- 2:43
So I wanted to show you what has been my setup for the experiments I'm gonna share with you today. Uh, [chuckles] this, this is my Mac. It's still running evaluations right now, uh, back in my desk in Tokyo, and I'm controlling it from my phone.
- 2:57
Um, and after running evals nonstop for a couple of days, it started to get hot, so I had my husband put fans around it. Um, we're running out of fans.
- 3:08
But the, the machine is still running, and the evals are still giving results. Um, on this M3 Ultra with ninety-six gigabytes and twenty-eight core CPUs, I'm using two models.
- 3:21
I'm using the Qwen 27B quantized at four-bit and the DeepSeek V4 Flash.
- 3:29
And before I show you how I build the memory harness on this machine, I wanted to tell you what this l-- what is this an example of, right? Like, memory, when we design a harness for memory, this is the mental model I want you to have in mind.
- 3:45
Um, you can think of memory as a write, manage, read loop. So it's not just the database store. It's actually this control loop around the model.
- 3:55
More concretely, how did I take that loop and customize it? So this is my harness design. Like, I started with research agents that are the small agents because they have zero durable memory, and I wanted all the memory to come from the harness.
- 4:08
And then, um, in the middle, I have a core, which is always shown to, to the agent, um, of traces. And then I have a recall block, where I'm testing different modes, and an archival block, where I'm kee-ke-keeping track of information across different, um, sessions.
- 4:28
And in that recall block, I'm actually going through a ladder of modes that I'm testing. The baseline is, like, not to use memory at all, no recall at all.
- 4:38
So I'm, I'm testing for that. Uh, next is to use RAG vector, vector RAG, um, just to see whatever, like, the harness would pull in terms of similarity. Then is to use a decisions, uh, ledger, where I actually keep track of what decisions are being made for every turn, and then I can prioritize them.
- 5:01
And last but not least, and this piece is very important, I have a, what I call an oracle, but basically, this is the ground truth. So this is like telling the harness for every loop what the correct memory that needs to be retrieved is.
- 5:18
And the model is fixed across all the different tasks, so the only things that I'm changing is, like, these different variables in the recall block.
- 5:27
And I wanted to, to give you an example of a first task that I tested. So I wanted to see if I give the agent a task of doing literature review, and I'm including a lot of papers in the corpus where there was a big scientific claim.
- 5:43
Like, this is actually a Nature paper where they said they discovered seven hundred forty-two thousand promising materials. Like, it was a very big claim, which got retracted later. But the retraction, ju- it's a s- much smaller
- 6:00
Like haystack needle in that corpus than the headlines and the citations. So I wanted to see if, if the system can retrieve the right answer for these type of questions.
- 6:14
And what I found was, because, like, for these tasks, all the papers and all the information fit into the context, the memory actually didn't add more capability. It was the same performance with memory and without memory, and it only added more cost.
- 6:32
So when your task fits in context, the harness doesn't add much.
- 6:39
However, if I start to run tasks that are longer-term horizon, and the entire task and the relevant context doesn't, uh, fit, then having a good memory harness really starts to pay off.
- 6:55
So this is another example of a task that I ran. This is actually from an established benchmark for long-horizon tasks memory. It's called XBench. And this is an example of a question, right?
- 7:07
So I'm asking a question, and then, like, the right answer is in a v- like step one twenty-four. But the moment when I ask the question, I'm asking it, like, at step five hundred.
- 7:22
So it's completely outside of the context window, and the model needs to use the memory harness to retrieve the specific answer from the right step. So I'm testing this by, uh, changing the different policy ladder that I explained before with memory off, uh, by deploying recall, different types of recall, and by using the oracle as a reference.
- 7:49
And what I found was that with the ranked recall, the model gets the right answer, um, more frequently than without. And here is a breakdown of the decomposition of performance on this XBench tasks.
- 8:05
So I ran over, uh, sixty-eight questions, and for each of these questions, there were, like, multiple, um, cells and lots of different seeds. And what I found was that the rank-only ledger performed the best,
- 8:24
and it performed better than, like, just gating the harness by saying, "Do you need to use memory or do you not need to use memory?" And you're probably gonna ask, like, "Why is the oracle not hitting, like, the max?"
- 8:38
And I'm gonna explain that too. So the oracle, what it does, it provides the right information, the right memory to the model, but it doesn't force it to use it.
- 8:48
So the model can get the right memory but still retrieve the wrong information or choose to ignore it or be confused. So that's why the oracle in this case doesn't hit the max performance.
- 8:59
And I've done lots of ablations on these tasks to see, like, what happens if I give arbitrary, um, examples. What happens if I give it the wrong step? What happens if I give it the most recent step?
- 9:14
And I still found that the best performing condition was the one with the ranked policy for recall. And this actually works on several models, not only on the Qwen 27B but also on the DS4 Flash, and it also works across different benchmarks.
- 9:33
I also tried it on the SpiderV2 benchmark.
- 9:36
And it's not just that it gives you better recall, it actually costs less. So maybe a good heuristic to have here is that bad memory is expensive because it spends more token and it can send agent the wrong way.
- 9:52
But having, like, a good structural policy for recall can save you a lot of tokens and, uh, budget.
- 10:02
So one thing that I want to encourage you from this experiment is to consider the recall policy as a first-class metric and to start to think about how you might use it in your systems.
- 10:15
Like, what are the type of memories that you want to store? What-- How do you rank them? Like, how do you design your recall function? And then, um, what are the type-- What survives when you run this over and over and over in, uh, multiple sessions, multiple runs?
- 10:35
And this is just a simple first kind of experiment. Um, but the memory technique landscape is very rich. Um, so there's over thirty runnable cookbooks that are shared in this open source repository from, um, Diamond.
- 10:53
And memory is complex. We have short-term, long-term, different cognitive tech-techniques. Uh, we can use, start to use evaluation results as well. Um, and right now, there's actually a, a pretty broad landscape of solutions, right?
- 11:08
So going from simple file system retrieval to training memory models, um, there is, there is a wide spectrum of solutions from less structural to completely structured. Um, so I think there's a lot of research we're gonna see in this space.
- 11:26
Uh, it's important. Um, it becomes more and more relevant. And for me, it's been super fun to, to test this on local models, um, because I got to control everything.
- 11:38
I got to control the data I was using, the entire traces of compute and evaluations, and, um, yeah, I, I see that as an example of sovereignty. And it comes at a cost.
- 11:51
Uh, I didn't tell you that these local models, I can only what? Uh, run them in serial. Like, they don't support batch querying for the DeepSeek V4 Flash. So that's why I am still running evaluations back on my computer in Tokyo, or I w- I was doing it on the flight on my way here because it takes
- 12:08
a long time. Um, but I still think it's very powerful, and it's a very good test for what memory can do when you can control every single step of the pipeline.
- 12:20
And this sovereign capability is part of a bigger ecosystem that is very important for us at Sakana AI in, in Japan. Um, we believe in the importance of sovereign AI today more than ever, and we are also hiring.
- 12:34
So if you're interested and wanna hear more about this, and if you wanna come join us in Japan, come talk to me. Uh, thank you very much. [audience clapping] [outro jingle]