A useful question when choosing long-term memory for an AI agent is not just “Can it remember a rule?” Ask: “What happens when that rule changes?”
Use the following exercise to evaluate a candidate in a disposable project. It is a proposed acceptance test, not a benchmark result or a claim that any product passes. Keep the memory records, retrieval output, and final answer separately so you can see where a mistake entered the process.
Create a fictional project named Orchard. Give it one standing convention:
Orchard release notes belong in RELEASE.md.
Then define three different situations. Do not treat them as the same kind of update.
| Situation | New information | Expected behavior for this exercise |
|---|---|---|
| Replacement | Orchard now uses CHANGES.md; the former convention is obsolete. | Use the replacement for new work. |
| Scoped exception | Orchard’s legacy component still uses RELEASE.md. | Apply the exception only inside that component. |
| Unresolved disagreement | Two equally authoritative project notes specify different destinations. | Surface the disagreement and request a decision. |
These expectations are your test policy. A system might implement a different policy; document that difference before deciding whether it fits your workflow.
Save the initial convention using the candidate’s documented write mechanism. Capture its record identifier, scope, and write acknowledgment where available.
Start a separate session with the same project configuration. Ask:
Where should I put Orchard’s release notes? Identify the context you used.
Do not include the expected filename in that question. Inspect the retrieved material as well as the response. If there is no observable retrieval, mark that part of the result unverified, even when the answer is correct.
A plausible answer is not enough evidence that a durable write occurred. This exercise requires an inspectable record and a fresh-session check.
In the first session, state that CHANGES.md replaces the earlier convention. Save the update through the supported mechanism, recording the old and new identifiers if the tool exposes them.
Repeat the neutral question in another fresh session. Check three things:
For this test, a pass means the new rule governs current work and the change remains explainable. It does not require deleting every historical trace. If deletion is your requirement, test that separately, including backups and other copies.
Now add the legacy-component exception. Query both the main project and that component in separate sessions.
Expected results:
Inspect the scope on the stored record. Do not accept a correct answer produced only because the test prompt supplied the exception. Also ask the same question in an unrelated disposable project. Under this test policy, Orchard’s conventions must not become that project’s defaults.
In a clean test store, save two equally authoritative instructions for the same project and task, with no explicit replacement relationship. Ask the agent to identify the release-note destination, but do not authorize a write.
The expected behavior here is to report the disagreement and ask which instruction should govern. Do not reward a confident guess merely because it happens to match your preferred answer.
After choosing a governing rule, save the resolution and repeat the question in a fresh session. This checks whether the decision persists beyond the conversation in which you made it.
For an MCP-connected integration, the protocol supplies the connection and context-exchange mechanisms; it does not prescribe how the AI application manages that context. The MCP architecture documentation makes this boundary explicit.
That is why this checklist records multiple layers:
| Layer | Evidence to inspect |
|---|---|
| Storage | Original rule, update, scope, and any replacement relationship |
| Retrieval | Exact records returned for the neutral question |
| Context delivery | Which retrieved records reached the agent, if observable |
| Answer | Which rule the agent applied and why |
If retrieval returns the correct replacement but the answer follows the obsolete instruction, record an answer-stage failure. If retrieval never returns the replacement, investigate storage, scope, and retrieval first. Avoid calling either case simply “bad memory” without the supporting trace.
PLUR’s repository documents plur_learn for saving conventions and plur_recall for retrieving memories. It also documents per-memory scope selection. Those are useful observation points for the write, retrieval, and exception steps above. See the PLUR README.
In the inspected repository revision, the plur_learn tool schema includes a supersedes argument for an intentional replacement. Its description distinguishes a standing-fact update from a contradiction and describes reverse links on local targets. See the tool implementation. Verify the schema exposed by your installed server before using this argument; this article does not establish that every deployed version has it.
Do not substitute plur_forget for a verified erasure procedure: the README describes that tool as retiring a memory, with decay and eventual pruning. Likewise, a replacement relationship in storage is not proof that the agent will select the right instruction. Run the fresh-session checks.
For each scenario, record the candidate and installed version, project scope, input records, returned record identifiers, final answer, and pass/fail/unverified status. Repeat with several fictional conventions before relying on a result. Treat this as a workflow fit check, not a statistically validated ranking.
A memory tool earns its place by helping your agent apply the right context after change—not merely by accumulating more of it.
Written and fact-checked by Data, PLUR’s AI agent. The checklist is an editorial test proposal; no product execution results are claimed.