Agent Memory Repo: reviewable memory for AI agents
Recurring project knowledge can make the next session easier. A small pilot shows which information helps and how to keep it current.
Start small with fictional data.
Check each note’s source and currency.
Test a changed rule in a new session.
The short answer
You are explaining a project’s structure to an agent for the third time. Persistent memory sounds appealing, but it should remain inspectable: where did a note come from, who may change it and is it still current? We suggest starting with a small test project and fictional data.
How the concept works
Cognition describes Agent Memory Repo as memory across sessions. Notes are read, updated and linked. A separate periodic agent can consolidate entries and investigate contradictions. The GitHub project publishes the open specification under MIT; Git provides history and surfaces conflicts.
A short entry point instead of one enormous note
The specification uses MEMORY.md as an entry point linking to other files. Keep that overview brief. Our suggested pilot structure is one project page, one working-rules page and a list of open questions. Store decisions once and link to them elsewhere, making corrections manageable.
What makes the pilot useful
A useful trial finds the right information in the next session, incorporates changes and openly identifies uncertainty. Assess these three criteria separately. A long answer alone is not success. If an answer is wrong, ask which note it used and correct that underlying information first.
Your practical comparison
What you need
You need an agent with file access, Git and a separate test folder. The open specification defines a format; it does not automatically configure every application. Establish which files the agent may read and change. A local trial without a remote repository is sufficient to begin.
- Choose a fictional test project and three non-sensitive facts, such as an output format, a test rule and a defined term.
- Keep memory separate from the project itself. State which information may be recorded and who reviews changes.
- Record a source and a review date for each entry. Clearly label an assumption as an assumption.
- Ask a specific question in a new session. Compare its answer with the test notes and check whether the right information was found.
- Deliberately change one test rule. In another session, check whether the new version is used and the old statement treated as outdated.
- Inspect the Git diff. Only then decide whether to expand the pilot to additional information.
Example to get you started
Our test example: “In the Garden Plan project, bed always means a planting area. Status reports use completed, open and next steps. Test note, reviewed October 6, 2026.” Ask a new session: “How should my status report be structured?” It must give those exact fields without inventing additional project facts.
Things to consider
A saved error may return in later sessions. A local trial is also not automatically available on another computer. Check access and content before expanding it. This is a proposed pilot, not a product test we have performed.
Read next
Your first automation: start small and verify
A repeatable workflow with clear limits and failure paths.
AI automations with approval: draft first, act afterwards
Create a reviewable boundary between an AI suggestion and an external action.
Gemini Connected Apps: prepare a useful project pilot
New app connections have been announced. Check their value on a small task before connecting real project data.
Was this article helpful?
Your feedback helps us improve our articles.
Votes are counted per language version. Repeat voting is limited; totals do not necessarily represent distinct people. Privacy