Adaptive Agent Memory Research was presented on Show HN on November 1 as a local memory tool for coding agents. The post links to krapcys1-maker’s public repository. The news is that community presentation, rather than a verified date for the software’s first release. SIExpo checked the original submission and the project’s current description; it has not installed the tool or reproduced its experiments.
### What is available
The README describes a working append-only event log, local search and context selection, exposed through MCP tools and a command-line interface. The author says the memory engine needs no cloud account, API key or vector database. The same page calls it a research engine rather than a finished product, and does not present independently confirmed superiority over conventional context compaction.
That distinction matters. Keeping a record is a verifiable software function; deciding which record will help a future task is a separate research objective. An archive does not establish that an agent always retrieves the right information or understands when it has ceased to be valid. Storage and usefulness need separate evaluation.
### Why an old decision can resemble its replacement
Consider a project that initially selects one database and later changes its decision. A search based only on the subject could return both records. The next task needs to distinguish the current decision, its historical predecessor and the evidence supporting the change. This is our illustrative example, not a reported AAMR customer case.
The scope document lists provenance, contradictions, correction, deletion and separation between users and projects as research requirements. It explicitly rejects the assumption that local storage is automatically safe. These are declared boundaries and research tasks, rather than proof that every protection has already been implemented and validated.
A separate research-question document asks how to evaluate updates, temporal validity and transfer between tasks. The public documentation consequently lets readers distinguish the available tool from the open question of whether its memory selection provides a durable advantage.
### What a useful evaluation would involve
For a team considering this approach, we suggest a small evaluation specified in advance: one history with a changed decision, another with withdrawn permission, and a third containing irrelevant but similar text. Compare both the context supplied to the agent and its subsequent behaviour under an equal budget. Retrieving the correct line alone does not establish that the final answer is correct.
Access needs its own rule as well. A memory of earlier permission is not fresh permission to act. Information copied from an external document does not become a user instruction merely because it has been stored. These are editorial evaluation proposals, not claims of measured AAMR defects.
Keeping an evidence trail would also help a reviewer distinguish a retrieval error from an interpretation error. If the current decision was absent from the supplied context, retrieval needs attention. If it was present but ignored, storing more history might not solve the problem. That diagnostic example explains why an evaluation should examine the whole path rather than only the archive size.
The project’s significance lies in openly asking what an agent should remember and how usefulness can be demonstrated. Public code and declared limitations make inspection possible. They do not yet justify a promise that long-term memory is solved or that a local log can replace human judgement about validity and authority.
Editorial verification: 2026-11-02T09:49:31.133144+00:00 (UTC; Europe/Sofia is UTC+02:00).
