MEX: shared project memory in Git for engineers and their coding agents
Team memory for engineers and their AI agents. Lives in your repo. Shared through Git.
At a glance
- What is it?
- MEX stores architecture notes, decisions, requirements and handoffs as Markdown inside the repository, with a local Hub for review and a CLI plus MCP server for agents. The interesting part is not the storage format but the review gate: knowledge changes are proposed in an Inbox and only become canonical after a person publishes them.
- Who is it for?
- Adopt MEX if your team already treats documentation review as part of the pull request and you want agents to read the same reviewed context humans do. Skip it if you need a hosted service that pushes notifications to teammates, since publishing writes files to your checkout and delivery is your Git workflow.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem MEX targets: context that dies with the session
The README opens with a specific failure. One engineer knows why a constraint exists. Another has the debugging history. 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 inside the repository: readable Markdown, code-linked explanations, reviewed knowledge contributions, and structured handoffs. The audience is a team where engineers and their coding agents both read and write context, and where the team already shares work through Git. It is not aimed at a single developer keeping private notes, although the README notes that working solo is supported because the next person using the memory can be you in a new session. The unit of value is the handoff between people and sessions, not the note itself.
What actually lives in the repo, and who is allowed to write it
The README maps retained knowledge to named locations. Wiki holds architecture, decisions, conventions and patterns, grounded by a Code Graph. An Inbox proposal adds to or corrects existing Wiki knowledge. Specs keep requirements, constraints and acceptance criteria. Relays carry progress, decisions, blockers, evidence and next actions. Workstream records remain readable for earlier workflow context. Members and Activity history record who was involved and what MEX logged. The write path is deliberately split. An agent can update a Wiki explanation and its code references when a human directs it, but a conclusion the team should review goes into the Inbox as a proposal awaiting explicit approval. That is the design decision worth noting: agent output is not canonical on arrival. Canonical memory moves through ordinary commit, push and pull, and each teammate keeps their own local indexes, drafts, identity selection and Hub. The README states plainly that no hosted MEX service, Docker, proxy, MEX account or MEX-owned model key is required.
Relays do not deliver anything, and that is the whole point
The handoff example is concrete. Alex changes webhook retry handling and Sam continues. Alex asks Codex to inspect existing architecture, decisions and code evidence before changing anything. Codex updates the Wiki and code references, and prepares an Inbox proposal for anything the team should approve. Alex then asks $mex-relay to draft a Relay covering what changed, which tests ran, what remains and where to look next, reviews the draft and publication preview in the Hub, explicitly publishes it, and commits and pushes both code and canonical MEX files. Sam pulls the branch, updates his local indexes, opens the Hub, takes the Relay, and asks his agent to read its context. His acknowledgement is another canonical change to commit and push. The README is direct about the boundary: the Relay carries the explanation and observed repository state, not the uncommitted code, and publishing writes files to Alex's checkout without notifying Sam or delivering anything until they share through Git. Anyone expecting a notification or a sync service will be surprised. Lifecycle and concurrency details sit in the Relay boundaries section, which is where a team should look before running two people through the same handoff.
How MEX works: a local Hub over a Code Graph, with Git as the only transport
The Hub is a local surface for people. Home, Search, Context and Code bring explanations and implementation evidence together, and the Context graph shows knowledge entities and their relationships, with a selection revealing direct code groundings and details. Inbox handles proposed additions and corrections; Relays preserve what the next person needs; existing Spec proposals and Workstream records stay readable; Team/Members supports attribution and local identity selection; Activity shows accepted MEX workflow events. Agents work through project instructions and the CLI, and there is an MCP server, described in the badges as source only. The Code Graph is built from the repository using tree-sitter, which is listed among the topics alongside code-graph and knowledge-graph. Release 0.8.1 notes a Hub that can keep serving requests during Graph construction, which tells you graph building is the slow part and that earlier versions made you wait. The architecture is deliberately boring: Markdown files in the repo, a local viewer, Git as the sharing layer. The cost of that choice is that nothing is coordinated for you.
Getting it running: Node 22.5, the mex-agent package, and the Hub
The repository requires Node.js 22.5 or later, uses TypeScript 5.9, and ships as the npm package mex-agent, which is what the version and download badges point at. The README's quick start is a link rather than inline commands, so the exact invocation is not reproduced in the material I have. What can be confirmed: installation is through npm, the Graph is built locally from your checkout, and the Hub runs as a local process you open in a browser. Configuration keys visible in the material are limited to feature names rather than a settings table: agent logging is described as configurable in 0.8.1, identity selection is per teammate and local, and the MCP server is source only, which implies you build or run it from the repository rather than consuming a prebuilt binary. Treat the quick start and command map sections of the README as the authoritative source for flags, and check RELEASE_NOTES.md for the 0.8.1 changes before pinning a version.
Where MEX is the wrong tool
MEX assumes Git is your coordination layer and that someone will review what lands. If your team wants a hosted knowledge base with server-side search, permissions and a notification when a handoff is waiting, MEX does not provide that. Publishing a Relay writes files to your checkout and stops there. The Inbox gate is also a real cost: an agent's conclusion is not usable by the team until a person approves it, so a team that wants agents writing directly to shared context will find the approval step in the way. There is a versioning risk too. The material shows a fast release cadence across 0.7.3, 0.8.0 and 0.8.1 within roughly two weeks, and 0.8.1 changes how the Hub behaves during Graph construction. Teams that pin versions and upgrade slowly should read the release notes rather than assume file formats are frozen. Finally, the whole model depends on discipline: canonical memory travels through commit and push, so a teammate who never pulls sees stale context, and an uncommitted Relay is invisible to everyone else.
Compared with a hosted agent-memory service
The obvious alternative is a hosted memory service where an agent's context lives on a vendor's servers and is retrieved through an API. That approach removes the Git step, gives you server-side search and often notifications, and hides the storage format. The difference in approach is where the source of truth sits. With a hosted service, the memory is outside the repository, and the repository is one consumer of it. With MEX, the memory is in the repository, reviewable in a pull request, and the Hub is a local reader over files you already own. That means MEX inherits Git's access control, history and branching, and inherits Git's clumsiness for anything that is not a file. It also means the memory is legible to a human without MEX installed. If your team's review culture is strong and your agents already run against a local checkout, MEX fits the grain. If your team needs cross-repository memory, central administration or push notifications, a hosted service is the better shape.
Licence, maintenance and what to check before adopting
MEX is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence, not legal advice, and teams with unusual distribution models should read the LICENSE file at the tagged release rather than the badge. Maintenance cost is mostly the upgrade path: the project publishes release notes per version, and the 0.8.x line moved quickly, so budget time to read them and to rebuild the Code Graph after upgrading. Operational cost is low by design because there is no server to run, but the local Hub and the Graph build are per-teammate work, and the MCP server being source only means it is not a managed component. Before adopting, verify three things: that Node.js 22.5 or later is available on every machine that will run the CLI, that your team accepts the Inbox approval step as part of normal review, and that Relay concurrency behaviour in the Relay boundaries section matches how your team actually hands work over. If any of those three fails, the tool will be fighting your process rather than fitting it.
Editorial conclusion
Adopt MEX if your team already treats documentation review as part of the pull request and you want agents to read the same reviewed context humans do. Skip it if you need a hosted service that pushes notifications to teammates, since publishing writes files to your checkout and delivery is your Git workflow. Before committing, verify Node.js 22.5 or later is available, read the Relay boundaries section for lifecycle and concurrency, and confirm whether your editor's MCP integration needs the source-only MCP server built locally.
Community notes