AgentRecall-X: A Corrections Ledger That Tracks Whether Your Agent Actually Stops Repeating a Mistake

The problem AgentRecall-X picks, and who has it

Coding agents forget. You tell Claude Code not to touch a particular version string, it agrees, the session ends, and three days later it edits that version string again. The correction was real, the agent acknowledged it, and nothing persisted. AgentRecall-X is aimed at that specific failure: a human correction that the agent accepts inside one session and then violates in the next. The README frames the target user as someone running Claude Code (or another MCP client) across many sessions and many projects, where the same class of mistake recurs often enough that writing it down would pay off. The repository's topics list claude-code, claude-mcp and agent-learning, and the install snippet is written for Claude Code first, with a generic MCP JSON block for other clients. So the intended audience is narrow: people who already use a persistent agent, already correct it, and are frustrated that the corrections evaporate. If you use an agent once a month and rarely correct it, there is nothing here for you to compound.

The corrections ledger: severity, evidence, outcome

The core data model is a correction record, not a memory blob. According to the README, each correction is stored with severity, evidence, and outcome tracking, and persists across sessions, projects, and agent restarts. The README names the export format as corrections-export/v1 and lists the fields it governs: scrubbed egress, retraction, severity, and proof-confidence. That is a schema with opinions. Retraction matters because a correction you later decide was wrong should not keep steering the agent. Proof-confidence matters because a correction stated once in passing is weaker evidence than one the human restated. Severity matters because not every correction deserves equal weight in retrieval. The README describes five memory layers and keyword plus RRF retrieval, so corrections are one layer inside a larger store rather than the whole system. What the material does not give is the actual field names, allowed severity values, or the retraction mechanics. If you need to integrate against corrections-export/v1, you will be reading the repository, not this article.

The measurement harness is the actual differentiator

The README makes a specific claim about the field: no public benchmark measures whether a captured correction changes what a fresh agent does in a new session, and it names LongMemEval, LoCoMo, MemoryAgentBench and the Letta Leaderboard as retrieval or within-session tests. Whether that gap is exactly as described, the distinction is real enough to be worth building against. AgentRecall-X tracks two counters per correction: retrieved_count, incremented when the correction is surfaced, and an outcome recorded as heeded or recurred when the agent meets the same situation again. The harness components named in the README are predict-loo, described as leave-one-out with anti-self-confirming design and dual denominators, and a benchmark spec called HeedBench v1. The README also states that the heed instrument defaulted to heeded absent evidence before 2026-07-03, that this made the pre-reset 92.5% figure an instrument-biased upper bound the README itself tells you not to cite, and that the post-reset default is unknown. That level of self-reporting is unusual. A project that publishes the number its own instrument got wrong, and labels it do not cite, is telling you something about how to read everything else it publishes.

The published numbers are bad, and that is the point

The README's measurement table is the most informative part of the repository. Correction capture recall on a dual-blind audit with n=59 is 35.3%, with a confidence interval of 17.3 to 58.7. In plain terms, the maintainers captured roughly a third of the real corrections in their own live use. The evidence-grounded heed rate after the instrument reset is 0/3 events. Correction transfer recall on an offline benchmark is 0/4, with a Wilson interval of 0 to 49%. The README states that transfer recall cannot support a point estimate below 39 classes per the benchmark spec, so the 0/4 is not a claim that transfer never works, it is a claim that the corpus is too small to say. The maintainers diagnose the 0 as a density problem: 32 active corrections across 19 projects is too sparse to front-run mistakes, and they say this was confirmed five times by internal experiments rather than being a retrieval architecture problem. You should read that diagnosis as a hypothesis the project is still testing, not an established cause. The operational numbers are more encouraging: median session_start injection is 1,489 tokens, down from 2,010, with a Mem0 anchor of roughly 7K cited for comparison, and p95 warm session_start latency is 363 ms, down from 1,132 ms. Those are the numbers that determine whether you feel the tool during normal use.

Installing it: MCP server, SDK, CLI, skill

There are three npm packages: agent-recall-mcp, agent-recall-sdk and agent-recall-cli. For Claude Code the README gives a single command: claude mcp add --scope user agent-recall -- npx -y agent-recall-mcp. For other MCP clients it gives the JSON block with command npx and args -y and agent-recall-mcp under an mcpServers key named agent-recall. The README also documents a four-command session loop, exposed as slash commands: /arstart to open a session and load context, /arsave to save, /arrecall to search, and /arreflect to consolidate. The behavioural instruction the README asks you to put in the agent's first message of every session is to call session_start at the start, call remember with type correction when the human corrects the agent, and call session_end at the end. The README notes five default tools. The README states zero cloud by default, so the store is local unless you change that. What the material does not contain is a configuration reference: no environment variables, no storage path key, no retention setting. That is a gap you will hit on day one if you want the ledger somewhere other than the default.

Where it fails, and when it is the wrong tool

The honest failure mode is written into the project's own table. If you install AgentRecall-X expecting that your agent will stop repeating mistakes, the published evidence does not support that expectation yet. Capture recall of 35.3% means most of your corrections never enter the ledger at all, and a correction that was never captured cannot be heeded. Transfer recall of 0/4 on the offline benchmark means that in the tested setup, a captured correction did not reliably change what a fresh agent did. The maintainers' density explanation is plausible and also untested at scale: 32 corrections across 19 projects is a small corpus, and the README itself says the data is insufficient to quantify uplift. There is a second, structural limitation. The system depends on the agent calling remember when the human corrects it. That is a behavioural contract, not an enforced one. An agent that forgets to log a correction is indistinguishable from a session where no correction happened, and the README's own capture number suggests this is exactly what occurs. If your workflow needs guaranteed capture, you would have to log corrections yourself through the SDK or CLI. Finally, this is the wrong tool if your actual problem is retrieval quality over a large document corpus. AgentRecall-X is a corrections ledger with keyword plus RRF retrieval over five memory layers, not a general-purpose semantic memory engine, and the README's own framing puts the ledger and the harness first.

The alternative, and the difference in approach

The obvious alternative named in the README is Mem0, described there as having roughly 60K stars and a session_start injection anchor of about 7K tokens, against AgentRecall-X's measured median of 1,489. Mem0 is a general memory layer: you store facts and preferences, and retrieval surfaces relevant ones. The difference is what gets stored and what gets measured. Mem0's unit is a memory; AgentRecall-X's unit is a correction with severity, evidence, proof-confidence and a retraction path, plus two outcome counters. Mem0 answers whether a relevant memory was retrieved. AgentRecall-X attempts to answer whether a correction changed behaviour, which is why the README argues the field's benchmarks do not cover it. The trade-off is maturity and coverage. Mem0 is a broader, more established memory system; AgentRecall-X is narrower, newer, and its own numbers say the behavioural half of its thesis is not yet demonstrated. If you want a memory layer that reliably recalls context, the broader tool is the safer pick. If you specifically want a governed record of corrections with an audit trail, that data model is the reason to look here. The README also lists Graphiti/Zep, Supermemory and Letta as field neighbours, and criticizes the space for self-reported numbers on the same two or three retrieval benchmarks that are hard to reproduce independently. That criticism applies to AgentRecall-X too, and the project's answer is docs/eval/REPRODUCE.md, which the README says regenerates every number in the table from committed artifacts.

Licence, maintenance cost, and what to verify first

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is permissive and unsurprising for a developer tool, and it means you can vendor the ledger format into your own stack. This is not legal advice; read the LICENSE file and your own obligations if you plan to redistribute. Maintenance cost is the real question here, and the release history is informative. v3.4.48 landed 2026-09-08, v3.4.47 on 2026-08-31, and v3.4.40 on 2026-07-27 with a changelog line reading naming at scale: classifier fix, hygiene trash scan, root MANIFEST, hot-path perf. Weekly-to-monthly patch releases with classifier fixes and hot-path performance work suggest the project is actively changing behaviour under the hood, which means pinning a version is reasonable and upgrading should be tested rather than assumed. The ledger schema is versioned as corrections-export/v1, which is a signal the format is meant to be stable, but a v1 label is a promise, not a guarantee. Three things to verify before you commit: run the reproduction steps in docs/eval/REPRODUCE.md and confirm the baseline JSON files regenerate on your machine; count how many corrections your own projects accumulate in a month, against the 32-across-19-projects figure the maintainers cite as too sparse; and check whether your MCP client reliably issues the remember call, because the 35.3% capture figure is the ceiling you inherit if it does not.

Editorial conclusion

Adopt AgentRecall-X if you already correct your coding agent repeatedly and want those corrections stored as structured, severity-tagged records that survive session restarts, and if you are willing to treat the heed metric as an open experiment rather than a proven uplift. Do not adopt it if you need a retrieval engine that reliably surfaces the right past correction in a fresh session: the project's own offline transfer benchmark scores 0/4 on its corpus, which the maintainers attribute to sparse correction density rather than retrieval design. Before installing, read docs/eval/REPRODUCE.md and regenerate the baseline JSON files yourself, then check how many active corrections your own projects would actually accumulate, because 32 corrections across 19 projects is the density at which the maintainers say the loop cannot front-run mistakes.

Official sources

1. Goldentrii/AgentRecall-X on GitHub
2. Issues
3. License: MIT
4. README
5. Releases