Skip to content

On this page you will see how MMW differs from three familiar ways of “teaching an agent to remember”, and decide whether you need it or whether what you have is enough.

The running question: where should the agreement “staging is deployed with the systemd unit app-staging” live so that all your assistants and colleagues know it?

Built-in assistant memoryNotes file (CLAUDE.md, AGENTS.md)Your own vector databaseMMW
Works across clientsWithin its own productIf the client reads that fileIf you build the integrationAny MCP client
Source of a factUsually not shownGit historyUp to yousource_id, hash, revision
Outdated facts and conflictsUsually not shownBy hand, in reviewUp to youstale and conflict statuses
Shared team memory with permissionsDepends on the productAnyone with repository accessUp to youRoles and record visibility
Keeping secrets out of memoryDepends on the productBy handUp to youMemory Guard
Effort to get startedNoneMinutesWeeks of development plus upkeepMinutes: a key and a config

The “usually” and “depends on the product” cells are deliberately cautious: other products change, so check their documentation.

The memory built into ChatGPT or Claude is convenient: turn it on and it works, nothing to configure.

Where it falls short.

  • It lives inside one product and one account. An agreement ChatGPT remembered is invisible to Cursor or Codex.
  • As a rule, you cannot share it with a team under your own rules such as “the unit sees this fact, only I see that one”.
  • You cannot see where a fact came from or whether its source has changed.

When it is enough. Personal preferences in a single assistant: answer style, your name, language. MMW does not have to replace it; the two do not interfere.

Notes files: CLAUDE.md, AGENTS.md and similar

Section titled “Notes files: CLAUDE.md, AGENTS.md and similar”

An instructions file in the repository is simple and transparent: it lives in Git, shows up in review and costs nothing.

Where it falls short.

  • The whole file goes into context. The more facts it holds, the more room it takes in every session, even when those facts are irrelevant. An agent reads MMW memory selectively, through search.
  • Agents rarely extend such a file on their own, and when they do, the changes need review and a merge.
  • The file belongs to one repository. Knowledge that spans repositories (how the infrastructure works, what was decided on a call) has no place to live.
  • There are no statuses: an outdated paragraph looks exactly like a current one.

When it is enough. Stable project rules: code style, build commands, things not to do. A good combination: permanent rules in CLAUDE.md, changing facts and decisions in MMW.

You can run a vector database, write an MCP server and keep memory on your own infrastructure. That gives you full control.

What you would have to build.

  • An MCP server, authentication and keys for every client.
  • Data isolation between people and projects, visibility rules, an audit log.
  • Detection of conflicting and outdated facts.
  • Secret redaction before writes and protection against instructions planted in memory.
  • Knowledge handover when people leave, time-limited access for contractors.
  • Backups, upgrades, monitoring.

When it is worth it. When you already have a team ready to maintain all of this and special data requirements. If data must stay on your own servers but you would rather not build everything yourself, MMW offers an On-Premise option; see Plans.

  • MMW does not guarantee a fact is correct: there is deliberately no verified status. It shows provenance and discrepancies; the decision stays with a person.
  • MMW does not read conversations on its own. Empty memory stays empty until the agent starts saving, so give it rules; see Best practices.
  • Search over uploaded session history is not available yet.