Most AI code reviewers know your diff and nothing else. They read the lines that changed, apply what they know about code in general, and comment. That catches typos and off-by-ones. It misses the comment that matters most: “we tried this before, and here is what broke”.
That knowledge lives in the team, not in the diff. So we built a reviewer that reads the pull request with the team's memory beside it.
Same diff, two reviews
Say a pull request tidies up the CLI package and deletes apps/cli/.npmignore, which looks redundant next to the files list in package.json. A generic reviewer might say:
Consider sorting the “files” array alphabetically for readability.
A reviewer grounded in the team's memory says:
Blocker. Without .npmignore, npm falls back to .gitignore, which ignores dist/. Last time this shipped a CLI package with no binary. Keep the file.
Memory: “CLI .npmignore required to ship dist/”, approved by the team.
The second comment is only possible because someone learned that lesson once, and it was kept. That is the whole idea.
How a memory-grounded review works
- The diff is read with the project's approved memory. Rules, decisions, risks and past failures relevant to the changed files are put next to the code. Only memories a person approved are used.
- Each finding cites the memory it comes from. You see why something was flagged, and you can open the memory to check it. A finding without a citation is still allowed, but you can tell the two apart.
- The verdict follows your policy. Per repo you choose which severities to show (blocker, warning, nit, praise) and when the bot approves or requests changes. With grounded only, the verdict counts only findings that cite a memory, so it rests on what the team actually decided.
- It runs in CI. One command writes the GitHub Actions workflow, and every pull request gets a review with inline comments. You can also review any open PR on demand from the app.
memmo ci # writes .github/workflows/memmo-review.yml
gh secret set MEMMO_TOKEN # a project token from the appIt learns what you don't want to hear again
The fastest way to make developers ignore a review bot is to repeat a comment they already dismissed. So feedback is part of the loop.
- React 👍 or 👎 on the GitHub comments, or mark findings Useful or Noise in the app.
- Useful findings raise the confidence of the memory they cite. Noise lowers it, so weak memories fade instead of nagging.
- Findings the team already dismissed are suppressed in later reviews, so the same comment doesn't come back on the next pull request.
Reviews and agents teach each other
Merged pull requests propose new memories too. A decision argued out in review becomes a candidate rule, and once a person approves it, two things happen: the next review checks for it, and the next Claude Code session is warned about it before it writes a line. That loop is how memory stays current without anyone maintaining a document.
If you want the agent side of the story, read how we stop Claude Code repeating mistakes. For setup details, the reviews docs cover every option.
Your key, your budget
Reviews run on your own Anthropic, OpenAI or Google key, within a monthly AI budget you set per project. When the budget is reached, reviews pause and say so.