Code Review Agent Memory: Stop Repeat Comments

Your review agent flags the same style issue every PR because each run starts blank. With code review agent memory on a shared project layer, the reviewer reads the conventions and decisions your coding agents already saved — and stops repeating itself.

Why review agents repeat the same comments

Every review run starts blank. Your reviewer — whether it is Claude Code on a diff, Codex in a CI job, or a script calling an API — opens the pull request with the files in front of it and nothing else. It does not know what you decided last week.

That blank start explains the repeat-nitpick loop: the agent flags console.log leftovers the build strips anyway, re-asks a migration ordering you settled two sprints ago, or suggests npm after the repo standardized on pnpm. Each false flag teaches the team to ignore the reviewer.

The root cause matches why coding agents forget conventions: a conversation holds context only for its own lifetime. Compaction rewrites it lossily, /clear discards it, and a new CI run never had it. A rule that lives only in a prior chat stays invisible to the next review.

A reviewer without storage also misses real repeat defects. It does not know the checkout service breaks when a migration runs before the backfill, or that pushes straight to main break the staging check. It reviews the diff, not the history behind it.

The fix is to give the reviewer read access to the same place your coding agents write: one project memory that holds conventions, decisions, and recurring mistakes. The reviewer queries that memory at the start of each run, applies what it finds, and writes back anything new the PR taught it.

What a reviewer should actually remember

Keep review memory small: facts the next review needs, not diffs or transcripts.

First, conventions: package manager, test command, formatter, branch rules, required headers. For example: pnpm, not npm, pnpm test --filter checkout-service, never push directly to main, every migration needs a rollback note. These apply to every PR, so agents without memory re-ask them first.

Second, decisions with reasons. The team chose staging-first deploys because a direct production push skipped the contract check in March. A bare rule gets re-litigated; a rule with a one-line reason sticks. Store the decision plus the cause, not the thread.

Third, recurring mistakes: checkout migration ordering, missing Retry-After handling on 429s, tests that pass locally but flake in parallel. A reviewer that remembers these catches them before merge instead of re-explaining them.

Keep entries atomic: one fact per memory. You can then update or delete a single rule without untangling a paragraph that mixes three. Short facts also retrieve cleanly — a search for migration ordering returns that rule, not a bundle covering four unrelated topics.

Code review agent memory in minutes: REST or MCP

Code review agent memory connects through the same two paths your coding agents already use: the REST data plane or the remote MCP server. Pick REST when the reviewer is code — a CI job or script that calls the API directly. Pick MCP when the reviewer is an agent in an MCP-compatible client.

For REST, the reviewer needs one thing: a project key with the ak_ prefix against the data plane at https://api.memory.audaxic.com. The API is mem0-like: POST /add to store, POST /search to recall, GET /list paginated with limit and offset to audit, PUT /update to correct, DELETE /delete/{memory_id} to remove. The quickstart shows each request format, and the search API docs cover recall queries.

Search before reviewing, then store what is new:

curl -X POST https://api.memory.audaxic.com/search \
  -H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
  -H "X-Api-Version: 2026-09-25" \
  -H "Content-Type: application/json" \
  --data-binary @search.json

curl -X POST https://api.memory.audaxic.com/add \
  -H "Authorization: Bearer ak_YOUR_PROJECT_KEY" \
  -H "X-Api-Version: 2026-09-25" \
  -H "Content-Type: application/json" \
  --data-binary @new-fact.json

Pin the date-based X-Api-Version header in automation. The current version is 2026-09-25, so scripts fail loudly instead of silently changing behavior when the API moves.

For MCP, point the client at the remote server over Streamable HTTP with the same ak_ Bearer key:

{
  "mcpServers": {
    "audaxic-memory": {
      "url": "https://memory-mcp.audaxic.com/mcp",
      "headers": {
        "Authorization": "Bearer ak_YOUR_PROJECT_KEY"
      }
    }
  }
}

That endpoint serves Claude Desktop, Cursor, Windsurf, and any MCP-compatible client. Cursor connects through MCP only; there is no Cursor plugin. The MCP setup guide lists client steps and tools. REST and MCP read and write the same project memory, so CI and desktop reviewers never diverge.

How a memory-backed review handles a real PR

Take a concrete PR: a contributor adds a retry loop to the billing worker and reorders a checkout migration. Without memory, the reviewer asks which package manager to use and misses the migration ordering, because that context lives in a closed PR from last month.

With memory, the reviewer starts with a search combining repo, touched areas, and rules: billing-worker checkout-service review rules retries migrations. It returns four facts: the team uses pnpm, retries require backoff with a reason in the PR description, migrations run after the backfill, and staging-first deploys are mandatory.

The review changes three ways. First, it checks instead of asking: it runs the stored test command and reports the result. Second, it cites the stored reason — the provider rate-limits bursts, which is why the project requires backoff — and flags the missing justification in the PR description. Third, it catches the ordering bug the stateless run missed: this migration runs before the backfill, the exact pattern from the March incident.

The reviewer then writes back one fact, not a PR summary. If discussion settled the backoff interval, that interval becomes a memory. If the PR introduced no new rule, the reviewer writes nothing.

Verify the loop as you would any agent memory. Ask for something only a prior session could know, or call GET /list with a small limit and confirm the stored rule is there. If the reviewer repeats a recorded exception, confirm it searched first and uses the right project key — a wrong-project key makes memory look empty.

Keep the memory clean: update wrong facts, delete stale ones

Review memory rots without upkeep. Rules change and exceptions expire, and a reviewer enforcing last quarter's convention loses trust fast. That upkeep keeps code review agent memory trustworthy — the same habit behind shared memory.

Correct with PUT /update when the fact still applies but the detail changed: test command moved packages, backoff interval changed, staging header gained a required value. Do not add a second memory that contradicts the first; two competing facts force every future search to return both and make the reviewer guess.

Delete with DELETE /delete/{memory_id} when the rule no longer applies: deploy freeze lifted, flaky test fixed at the source, hotfix exception expired. Stale facts hurt more than missing facts because the reviewer still states them with confidence.

Audit with GET /list on a schedule matching PR volume. Pull the first page with limit=20, scan for duplicates and contradictions, then merge or remove. The full wipe DELETE /delete fits only a true project restart — selective deletes preserve good rules while removing noise.

An add counts per memory extracted from a message batch: one /add call extracting five memories counts as five adds, so one atomic fact per call keeps accounting predictable. Retrieval is tiered: the first 10 memories count as one request, each additional 10 as one more. Save small and search narrow — the Hobby tier's 10,000 adds and 1,000 retrieves per month stretch far before you need Starter at $12 per month.

One shared layer for reviewers and coding agents

The largest win: reviewer and coders read the same project memory. The coding agent writes the decision while implementing — checkout migrations run after the backfill because the March deploy broke — and the reviewer enforces it on the next PR with no copy-paste between tools. One memory per project means switching agents never resets context, from Claude Code to Codex or from coding to review.

Claude Code installs with npx @audaxic/memory-claude install, Codex with npx @audaxic/memory-codex install, and OpenCode with npm install -g @audaxic/memory-opencode. Point each at the same project's ak_ key. MCP clients join the same project with the same key. The Claude Code persistent memory setup walks through the plugin flow and the recall check.

Data is isolated per organization with namespace-scoped vector search, customer data is never used for training, and servers run in the US and EU. Inside the organization, the project is the boundary: a reviewer holding the checkout key sees checkout rules and nothing else. Projects are unlimited on every plan from Hobby through Enterprise, so give the reviewer its own key to the same project. Graph memory is included on all plans with flat monthly pricing and no per-token fees, so adding a reviewer changes retrieval volume, not the billing model.

To seed the reviewer instead of starting empty, import the conversations that predate setup. The importer covers past Claude Code, Codex, and OpenCode sessions with correct timestamps via npm install -g @audaxic/memory-import. Import once per project before enabling the reviewer, so when the next PR repeats an old mistake, the reviewer already knows.

FAQ

Written by Efe — Oct 09, 2026 · More articles · X @AudaxicTech