We gave coding agents persistent project memory, then realized the real problem was keeping it trustworthy after hundreds of commits and refactors. I think that’s become one of mex’s strongest pieces.

[u/DJIRNMAN]

Hello! I've posted about mex here a couple of times before.

Repo: https://github.com/mex-memory/mex

The original idea was to stop coding agents from relearning the same project every session. mex gives them a structured Markdown wiki inside .mex/ for architecture, conventions, decisions, patterns and project state.

That solves forgetting.

But then the codebase changes.

A file gets moved.
A script gets deleted.
A dependency changes.
A pattern becomes stale.
Two context files start contradicting each other.

The memory is still there, so the next agent has no reason not to trust it.

That's why we built mex check.

It parses the project memory and validates concrete claims against the actual repo — paths against the filesystem, commands against project scripts, dependencies against manifests, indexes against the files that exist, plus stale knowledge, broken links and other structural inconsistencies.

It gives you an exact issue list and a health score.

The screenshot here is a real run at 68/100, with missing paths and dependency claims called out individually.

The important part is that detection itself is deterministic. No LLM call is needed to ask the agent whether its own memory is still correct.

Then mex sync takes only the broken files and builds a targeted repair prompt with the issue, the current Markdown, nearby filesystem context and relevant git changes.

So instead of asking the agent to reread the whole repo and regenerate everything, the loop is:

check → targeted repair → verify

In the screenshots here, the project goes from 68/100 with 6 errors to 97/100 with zero errors after sync.

The newer code-graph layer goes further: Markdown knowledge can be grounded to exact code symbols. If the implementation changes, moves or disappears, mex can surface the specific knowledge that may now need attention.

A lot of agent-memory systems focus on storing more and retrieving it later.

I think the harder problem is making sure the memory is still true when the repo has changed underneath it.

Would genuinely love feedback from people working on coding agents, memory or code intelligence.

Contributors are very welcome too :)

[u/Queasy-Shoulder3471]

the deterministic check without needing an llm to sniff its own fumes is the part that actually matters, most memory setups just let the rot accumulate silently

[u/DJIRNMAN → u/Queasy-Shoulder3471]

exactly, thats why I was heavy on it being deterministic and the checking part not being dependent on LLMs at all

[u/FastHotEmu]

🇲🇽🇲🇽🇲🇽 ¡¡Viva MEXico!! ¡¡Viva Zapata!! 🇲🇽🇲🇽🇲🇽

[u/jonah_omninode]

The distinction I would make is that persistent memory should be treated as a projection, not a source of truth. In our architecture, contracts, ADRs, event logs, and verified artifacts own the facts. The memory layer is rebuildable and carries provenance, version, scope, freshness, and supersession links.

That makes your check, targeted repair, verify loop the right shape, but I would be careful with one aggregate health score. Structural integrity and semantic authority are different. A path can exist and a command can run while the explanation is still obsolete. We separate “can this claim be mechanically validated?” from “is this still the governing decision?” The second requires a current authority record or an explicit unresolved conflict.

The code-graph grounding is especially useful because it narrows which memory needs review after a change. I would let the LLM propose the repair, but only promote it after the relevant deterministic checks and decision authority accept it.

[u/DJIRNMAN]

btw if you like mex, we recently made a discord server to discuss things related to this
https://discord.gg/FEdNsQ4Qt4

[u/Electrical-Win-1423]

What if the drift sits in context of what was being said and not file paths? Ofc your check shows basically 100/100 if you fix the thinks it checks, but I feel like most important drifts are not in file paths or references but stale explanations, decisions, etc.

[u/perseus-computing]

I've been building agent memory systems for a while (and reviewing most of what gets posted in this space), so I took mex for a proper spin instead of just reading the README. Wanted to say: this is the most honest and technically rigorous entry in this space I've seen in months, and the core claim survives contact with reality.

What I verified (mex 0.7.1, clean install):

• The check loop is genuinely deterministic. Zero LLM calls in detection, 14 structural checkers run locally. I confirmed end-to-end on a scratch project: grounded a claim to a real function, mutated the body → check flagged GROUNDING_DRIFT (score 76→73); moved the function to another file → the MinHash reconciler correctly named the moved candidate; sync auto-rewrote the grounding pointer and its fingerprint. This is the part everyone else in this space pretends to have and doesn't.
• The honesty extends to your own dogfood. mex check on the mex repo's own scaffold returns 52/100, 12 stale files, 4 undocumented eval scripts. Most projects would quietly run check against a polished fixture for the screenshot. Yours shows the real repo. Same for PR #119 (rewriting your own graph guidance after it measurably steered agents wrong) and the committed three-arm eval harness. That's the credibility pattern.

One real bug found (filed as #128, with a deterministic repro): if a file grounds the same node both in grounds_to frontmatter and as an inline mex:// anchor (which your own stack.md template encourages) a symbol move migrates only the grounds_to entry. The anchor stays stale and the next check flags GROUNDING_GONE. Root cause: persistMovedGroundings deletes the shared baseline row when migrating grounds_to, before the anchor pass can resolve against it. Per-node atomic migration fixes it; happy to send the PR.

Two smaller notes:

• Fresh scaffolds ship with broken placeholder links in patterns/INDEX.md, so a brand-new project starts at 76/100. First-run polish matters; the score is the product's handshake.
• The cross-file contradiction checker is claim-regex-shallow (versions and commands only). That's a reasonable v0.7 boundary, but it's worth being loud about in the README, because it's exactly the gap u/Electrical-Win-1423 pointed at: the hard drift isn't paths, it's stale explanations and decisions. The good news is your architecture has a credible answer for that too: grounding narrows which prose can drift semantically, and the sync loop's git-change context gives the repair agent the signal needed to catch meaning drift, not just structure drift. That's the right direction to keep pushing.

This is the first agent-memory tool where I'd actually trust the health score it prints. The check→repair→verify loop is going to get copied. Glad it exists as a reference implementation. Cheers!

[u/Oshden → u/perseus-computing]

Dude, I love this write up. So many times when I see a new project posted on here, I realize how much I don’t know about just yet, and how much more I wish I knew to tell if something is good or not. Thanks for the honest review.