A shared Markdown file is a useful first memory. Multiple agents can read it, and hooks or agents can update it. Unforgetter started from this approach. The question is how much of the surrounding workflow you want to operate yourself.
Start with a shared record
Keep repository instructions next to the code. Put changing decisions and project status in a record the relevant agents can access. Use dates and source references so a reader can distinguish a decision from a suggestion.
Capture the changes
Choose what should be written after a session: decisions, corrections and open questions. A transcript is useful evidence, but it is not a substitute for an explicit current decision. Decide who can propose changes and which process publishes them.
Keep the old decision as history
When a rule changes, record the new rule and what it replaces. Agents should be able to find why it changed without treating both versions as current. Version control can help preserve the edits; clear temporal labels explain their meaning.
Enforce the access boundary
Folders organise files. Filesystem permissions, sandboxing and the integration determine what an agent can actually read. If one client’s material must be excluded, test that boundary before sharing the workspace.
Keep the workflow running
Check what happens when capture fails, two sessions propose conflicting changes, or the publisher has not run. A maintained memory needs a way to surface those gaps. Automation is possible with files; it remains your system to operate.
Where Unforgetter fits
Unforgetter is being built to take on that maintenance and serve a shared record to connected agents. The Cloud alpha currently provides retrieval; its managed capture and maintenance flow is still in build. The comparison sets out the current differences. Keep a simple file setup if it already does the job.