MEX review: shared project memory for engineers and their coding agents

The problem MEX addresses: context that dies in a session

The README opens with a scenario that most teams recognise. One engineer knows why a constraint exists, another holds the debugging history, and a coding agent found an edge case in a session nobody else will read. The next teammate reconstructs all of it. MEX's answer is to give that knowledge a durable home in the repository rather than in a chat transcript or a wiki nobody updates.

The scope is deliberately narrow. The project targets teams where engineers and their coding agents work in the same codebase and already share work through Git. The README states that no hosted MEX service, Docker, proxy, MEX account or MEX-owned model key is required, which tells you the intended deployment is a local install per engineer with the repository as the only shared channel. That is a real constraint, not a marketing line: it means MEX inherits Git's review, blame and access model, and it also inherits Git's latency.

Wiki, Inbox, Relays and the Code Graph: how MEX works

MEX splits memory into a few named stores. Canonical knowledge lives in a Wiki of architecture, decisions, conventions and patterns, grounded against code through the Code Graph. Proposed additions or corrections sit in an Inbox until someone approves them. Specs hold requirements, constraints and acceptance criteria. Relays carry a handoff: progress, decisions, blockers, evidence and next actions. Workstream records remain readable for earlier workflow context, and Members plus Activity history record who was involved.

The Code Graph is built with tree-sitter and stored in SQLite, according to the package keywords and the repository layout. Agents retrieve from these stores through project instructions and the CLI, while people explore and review them in a local Hub. Two properties of this design are worth stating plainly. First, the graph is local to each checkout: the README says each teammate keeps their own local indexes, drafts, identity selection and Hub. Second, canonical memory travels only through commit, push and pull. The README is explicit that publishing a Relay writes files to the author's checkout and does not notify or deliver anything until the files are shared through Git.

Installing mex-agent and running a first Relay

The package is published on npm as mex-agent, and the binary it exposes is called mex. The engines field in package.json requires Node.js 22.5 or newer, so check that before anything else.

npm install -g mex-agent

That installs the CLI globally, after which the mex binary is on your path. The README does not spell out a version check command, so confirm your Node runtime against the engines field yourself before installing.

The README describes an end-to-end flow rather than a single setup command, so the practical first use is to let an agent read existing context before it changes code. In the worked example, an engineer asks their coding agent to inspect architecture, relevant decisions and code evidence before making a change and running tests. The repository also ships a setup.sh at the top level and a skills directory, and the handoff step in the README is invoked as a skill:

$mex-relay

That skill drafts a Relay covering what changed, which tests ran, what remains, and where to look next. The README's sequence is specific: review the draft and the publication preview in the Hub, publish explicitly, then review, commit and push the code and canonical MEX files through Git. The next engineer pulls the branch, updates local indexes as needed, opens the Hub, takes the Relay, and asks their agent to read its context. Their acknowledgement is another canonical change to commit and push.

Where MEX breaks down: staleness, delivery and the wrong team shape

The failure mode is written into the architecture. Because canonical memory is only as good as the last commit, a Relay that is published but never pushed is invisible to everyone else, and a Wiki page that nobody re-grounds drifts away from the code it describes. MEX mitigates this with the Code Graph and with Inbox proposals that must be approved, but approval is a human step, and the README does not document an automatic check that fails a build when a canonical file contradicts the current source.

Concurrency is a second boundary. The README points to a Relay boundaries section for lifecycle and concurrency details, which implies that two engineers editing the same Wiki page or publishing Relays on the same branch will meet the ordinary merge conflicts of any text file. There is no hosted coordination layer to serialise that for you. If your team wants memory that updates itself and reaches everyone without a pull, MEX is the wrong tool by design.

The third boundary is team shape. MEX is per-repository. A solo engineer working across many unrelated repositories gets the retrieval benefit inside each one, but the shared-knowledge benefit, which is the whole point of the Inbox and Relay review loop, mostly disappears.

MEX compared with a hosted memory API

The obvious alternative for agent memory is a hosted service that exposes an API or an MCP endpoint and stores context outside your repository. The difference is not the feature list, it is where the source of truth lives and who can read it.

With a hosted memory API, writes go to a remote store, retrieval happens over the network, and sharing is automatic because there is nothing to commit. You get lower friction and cross-repository memory, and you take on an external dependency, an account, and a copy of your architecture notes on someone else's infrastructure. MEX inverts every one of those properties. Memory is Markdown in the repository, retrieval is local, sharing is a Git operation, and review happens in a pull request. The README frames this as the design intent: Git is the sharing layer, and no MEX account or MEX-owned model key is involved.

Neither approach is strictly better. Pick MEX when the review trail matters and when engineers should be able to read the memory without a client. Pick a hosted store when you need memory that spans repositories or reaches a teammate who never pulls.

Maintenance, releases and the MIT licence

The repository is not archived and the last push was on 2026-09-09, which is recent enough that the project is being worked on. The release cadence visible in the notes is roughly weekly: v0.7.3 on 2026-08-26, v0.8.0 on 2026-09-02, and v0.8.1 on 2026-09-09. The package.json in the repository lists version 0.8.2, so the working tree is ahead of the latest tagged release.

That pace is the upgrade cost. MEX writes canonical files into your repository, so a release that changes the shape of Wiki entries, Inbox proposals or Relays can produce diffs in files your team has already reviewed. The 0.8.1 notes describe a Context graph, Inbox contributions, open-to-team Relays, configurable agent logging, safer grounding, and a Hub that keeps serving requests during Graph construction, which is a broad surface for a single minor version. Budget for reading RELEASE_NOTES.md before bumping, and expect the Hub and CLI to move together since they are built from the same repository.

The licence is MIT, declared in both LICENSE and package.json. That permits commercial use and modification, and it also means downstream users carry no warranty. This is a description of the licence text, not legal advice; if your organisation has rules about the provenance of tooling that writes into source repositories, route the question to whoever handles that.

Editorial conclusion

Adopt MEX if your team already reviews code through pull requests and you want agent context to travel the same path, because the canonical memory is plain Markdown in the repository and nothing is delivered until someone commits and pushes it. Skip it if you want a hosted service that syncs memory automatically, or if you work alone across unrelated repositories where a per-repo knowledge base has little to compound. Before committing to it, verify two things: that every engineer's Node runtime satisfies the engines field of the mex-agent package, and that your team accepts reviewing Inbox proposals and Relay publications as ordinary work, since an unreviewed canonical file is exactly the stale documentation MEX is meant to replace.

Frequently asked questions

Official sources

1. License: MIT
2. mex-memory/mex on GitHub
3. Project website
4. README
5. Releases