mex vs Manually Maintained Rules Files
Most teams currently manage AI coding agent context through manually maintained files: CLAUDE.md for Claude Code, .cursorrules for Cursor, AGENTS.md for Codex. These work initially but do not scale. There is no mechanism to detect when the rules drift from the implementation, no way to route only the relevant context to a task, and no shared foundation when multiple developers each maintain their own version.
mex replaces the manual approach with a wiki that grows from real coding work, connects claims to exact code symbols, and detects when those claims stop being true. The drift detection step runs without any AI tokens, which keeps the maintenance cost low as the codebase grows.
mex vs Proprietary Agent Memory Features
| Feature | mex | Commercial AI Tool Memory |
|---|
| License | MIT | Proprietary |
| Self-hosted | Yes (default) | No |
| Vendor-neutral | Yes | Per-tool only |
| Code-grounded | Yes | No |
| Drift detection | Yes | No |
| Version-controlled | Yes | Varies |
Commercial AI coding platforms such as Cursor, GitHub Copilot, and Windsurf each have their own memory or instructions mechanism, but these are proprietary, siloed in one tool, and stored on the provider's infrastructure. A team that uses multiple agents or switches tools must maintain separate context files for each. mex externalizes the memory layer into the repository itself, so the same wiki serves every tool the team uses.
The scenario where proprietary tool memory wins: if your team is fully committed to one AI coding tool with no plans to change, and you want memory managed without any CLI setup overhead, the built-in context features of that tool are simpler. mex is the better choice when the team uses multiple agents, wants to version-control their conventions alongside the code, or needs drift detection that is not tied to a specific vendor.