Repository navigation
Research
What the 2026 agent-memory literature says, read against the conditions this plugin actually runs under, and what the plugin did with it. The full notes live in the repository: an index with the reading lens, one card per paper in docs/research/cards/, and a synthesis of where the papers disagree. This page is the short version.
Most memory papers measure a regime unlike this one: procedural trajectories rather than declarative knowledge, benchmark streams rather than real work with a human correcting in the loop, short horizons rather than months. A result only transfers when its conditions do. So every card states the paper's conditions, whether they hold here (fully, partially or not), and what, if anything, it would change.
Thirteen papers were read: ten chosen up front and three found through a survey's references. Most were read through the end of the main body; a few only in named sections, and each card says exactly what was read. None of the papers' experiments was re-run, and numbers are quoted as the papers state them.
Three things are often mixed together in these papers. Pulled apart, each points somewhere concrete:
- Granularity. Principle-level knowledge transferred better and lasted longer than instance-level traces, which helped less and sometimes hurt when reused far from where they were made. A node should state a lesson that stays true outside the session that produced it; the episode belongs in the notes.
- Update regime. Rewriting the same stored text again and again degraded it. Writing once, at the moment of insight, is the regime where abstraction helped.
- Timing. Experience helped most when it arrived at the decision point it governs, selectively, rather than all at once at the start, though mainly for weaker or smaller models.
Is abstraction good or harmful? In one study, abstract insights transferred across coding benchmarks better than raw traces, by a small margin (average Pass@3 0.560 against 0.534; 2604.14004). In another, consolidated lessons degraded while raw episodes stayed competitive (2605.12978). The explaining condition is how the abstraction happens: a lesson written once from one trajectory held up, while lessons rewritten in place, in view of earlier rewrites, fell from the 100% ceiling to roughly 53–54% (the paper's figure and text differ slightly). Distance matters too: abstraction paid off across domains, where raw specifics mislead, less so where the memory was made.
Does continuously updated memory compound or corrode? Studies that report compounding run short horizons with reliable labels (a handful of iterations, gated edits); studies that report corrosion run hundreds of steps, and their curves rise first. A short study sees the rise, not the fall. Delta edits beat whole-store rewrites, yet no study runs a gated, delta-edited store for months with sparse labels, which is this plugin's regime. This one stays open.
Push memory to the model, or let it pull? Selective, step-wise retrieval beat injecting everything at the start, but mostly for weaker or smaller models; the strongest backbones rarely retrieved at all. Putting the full history in context won while it fit. This plugin combines both regimes (a bounded preload with the whole active graph one read away, plus selective recall at the prompt and at the file), a combination none of these papers tests.
Who should curate, with what evidence? Curators that see only the model's own trajectory inherit its errors; curators that can check a claim against the world did better, though within overlapping intervals. A maintenance agent here sees the graph only, so the server does the checking it cannot: for example, it works out where a moved file went before an anchor chore runs.
Some of these changes were planned in the same phase as the reading; the table pairs each with the evidence behind it and says how far that evidence has been tested here.
| Evidence | What the plugin does |
|---|---|
| In-place rewriting is the one maintenance pattern measured to degrade memory (2605.12978) | A churn guard (0.9.42): no chore rewrites a node in place once its gist has changed more than twice in 30 days |
| Principles transfer and last; instances less so (2604.14004, 2606.04703) |
Lift chores (0.9.42) write the lesson several dated episodes share, once, as a principle node, and link the episodes to it with instance-of
|
| Timing: experience at the decision point (2605.07164) | File recall (0.9.41): the memory about a file arrives when the agent opens or edits it. The card's test, whether it raises endorsements per injection rather than just adding injections, has not been reported yet |
| Curators need evidence beyond the trajectory (2609.11060) | Anchor chores (0.9.42) get the server's candidate for each stale file pointer (git's recorded rename, or the one same-named file in the project), never a guess; two candidates is a refusal |
| In-stream gains are weak evidence of long-run value (2606.02461, 2606.05661) | A replay evaluator (0.9.40) scores recall decisions and ranking variants against logged endorsements. It is not a with/without benchmark, and its own noise across time windows has not been measured yet |
| A persistent knowledge layer kept apart from executable skills improved skill evolution (WikiSkill, 2608.27454: one model's average rose from 48.7% to 63.7% when the skill proposer could read the wiki) | No change was needed: the plugin already keeps memory in the graph and procedure in skills. The testable claim, that recording declined proposals (the declined lines in the maintenance trail) stops them being re-proposed, is still open |
The logs hold prompt- and file-recall decisions, most silences included (recall.jsonl); every endorsement and credit with the route by which the node reached the session (useful.jsonl); every chore decision, refusals included (chores.jsonl); the maintenance trail with its declined lines; and, when the storage directory is a git repository, its history. None of these gives a with/without counterfactual, which needs a paired benchmark that has not been built. But they can answer, read-only:
- Do nodes rewritten more often get endorsed less per exposure?
- Are pushed routes (preload, full read, recall) or pulled routes (search, read by id) endorsed more per exposure?
- Are instance-shaped nodes endorsed less than principles, and does the gap widen outside their home project?
- Do chores cause a "maintenance shock": less endorsement or recall of the nodes they touched?
- When a node the session needed had to be dug up, did the store, the retrieval or the use fail?
- Do
declinedlines stop re-proposals?
The first measurement to take is how noisy replay is across separate time windows, because that sets the smallest difference any of the others can report. The research notes list all of these as open, and the repository records none of them as answered yet.
The replay evaluator uses only the Python standard library. From a checkout, run it with python3 -m eval inside knowledge-graph/server; ARCHITECTURE.md describes its options and what it cannot measure.