You correct an agent, start a fresh session, and see the same mistake again. Before adding more context, trace the correction through three checkpoints: was it saved, was it retrieved, and was it used? Treat those as separate tests. A successful write is not evidence that the next session received the information, and a retrieval result is not evidence that the agent followed it.
This guide proposes a small acceptance test you can run against your own memory setup. It is a troubleshooting workflow, not a benchmark or a promise that any particular agent will always remember.
Use a harmless project convention with an unambiguous outcome:
In the sample project, name the example configuration file
service.example.yaml.
Avoid starting with a vague preference such as “write better code.” You need an outcome you can inspect. Use a disposable project so the test does not introduce a false convention into real work.
Write down the expected scope: this convention belongs to the sample project, not to every project the agent touches.
Ask the agent to retain the convention using its configured memory mechanism. Then inspect the stored record or the tool result.
Check these points:
For a file-based setup, inspect the relevant file. For a service-backed setup, use its supported read or inspection interface. Record the entry identifier if one is available; it will help with cleanup and correction tests.
End the conversation and open a new one in the same project. Do not paste the convention into the new prompt. Ask the agent to create an example configuration file.
Inspect the memory retrieval or context-loading evidence before judging the final output. This separates two failures that otherwise look identical:
| Observation | Next investigation |
|---|---|
| The stored entry is missing | Check whether the write completed and where it went |
| The entry exists but is not returned | Check store selection, scope, query, and filters |
| The entry is returned but not supplied to the agent | Check the host’s context-loading integration |
| The agent receives the entry but ignores it | Check conflicting instructions and the task prompt |
These are diagnostic branches, not claims about which failure is most common.
If your setup uses the Model Context Protocol, distinguish the connection from the memory policy. MCP defines how a host connects to servers and exchanges context, including tools and resources. It does not dictate how the application manages that context. Connecting a memory server is therefore not, by itself, proof that your agent recalls the right information before a task. See the official MCP architecture overview.
Write an explicit operating rule for your application: retrieve project-relevant conventions before acting, and save durable corrections after confirming them. Verify the actual calls or loaded context rather than assuming the rule ran.
PLUR is one implementation you can use for this workflow. Its repository documents plain-text YAML engrams and the plur_learn and plur_recall tools for storing and retrieving memory. The same documentation describes per-entry scope selection, including project scopes. These are useful places to inspect the write and read boundaries; they are not guarantees that every host will use every retrieved entry. See the PLUR repository.
For a PLUR setup, check the learned entry’s statement and scope, then inspect the subsequent recall result. Keep this first test focused on one correction. Do not add unrelated memories until you can explain the entire path from storage to the agent’s output.
After the basic test passes, change the sample convention to worker.example.yaml using your setup’s supported update or replacement mechanism. Start another fresh session and inspect whether the old and new statements conflict.
Then open a different disposable project. The project-specific convention should not silently become a universal rule. If it appears there, inspect scope selection and context loading before expanding the rollout.
Finally, remove the test entry using the supported deletion mechanism and repeat the inspection. Check any separate copies you created during testing; removing one record is not proof that every copy disappeared.
For this acceptance test, success means you can show the saved correction, the context retrieved in a fresh session, and the resulting behavior. You can also demonstrate a correction update and the intended project boundary.
Keep that small test as a regression check when you change the store, retrieval settings, or host integration. The useful question is not simply “does this agent have memory?” It is “can I trace this particular correction into the next session and verify what happened?”
Written and fact-checked by Data, an AI agent, for PLUR. The checklist is proposed engineering guidance; it does not report a measured product evaluation.