AI agent memory for code review: remembering feedback and conventions

The short answer

AI agent memory for code review means keeping review knowledge in durable files outside the chat: your standing conventions, the rulings you have made, and the suggestions you rejected along with the reason. The agent reads those files before it reviews, and appends to them when a review settles something.

Without it, every review starts from zero. The agent re-flags the pattern you deliberately chose three weeks ago and re-proposes the refactor you already turned down. The rest of this guide covers what to store, where to put it, and how to run the loop without it rotting.

What actually needs remembering

Most review output is disposable. The valuable part is thin, and it is the part that gets lost. Sort it before you store anything, so the memory stays small enough to be worth reading.

Worth storing	Why
Standing review conventions	“Errors at boundaries only” stops being re-argued every review.
One-off rulings and exemptions	“This module is generated, do not review style in it.”
Rejected suggestions and the reason	This is how an agent remembers code review feedback instead of repeating it next month.
Follow-ups deferred during review	The thing you said you would fix later, with a way to close it.
Facts about the codebase	Which layer owns validation, which crate is the shared core.

What does not belong: raw diffs, whole review transcripts, characterizations of your teammates, and anything secret. A store full of transcripts becomes a second codebase nobody reads.

Where the memory can live

There is no single right answer, and some of the honest options involve no product at all.

Option	Where it wins	Where it costs you
Repo files (CLAUDE.md, AGENTS.md, docs/review-conventions.md)	Versioned, reviewable, and shared with every contributor automatically	Scoped to one repository, and maintained entirely by hand
Your issue tracker	The deferred fix is already assigned, dated, and visible to people who never run an agent	Agents reach a tracker through an integration, so it is read at review time only when that connection is configured
An embedding-based memory store or memory server	Handles large volumes and fuzzy recall well	Retrieval is by similarity, so what comes back is not always predictable from what you wrote. Some expose their store as readable JSON, some do not. Check before you commit.
A notes vault the agent reads and writes	Plain files you can read, edit, and carry across repositories and machines	One more thing to keep tidy, and the agent has to be told to use it

If your review knowledge is project-specific and one repository covers it, stop at the first row. The rest of this guide describes the last one.

Running the loop

Start a review by asking what you already know about this part of the code. jotura is the command-line tool that ships with Jotura, a local-first markdown notes app. The memory it reads and writes is ordinary .md files in a Memory folder in your vault.

jotura context "review the auth refactor in the api service"
jotura memory recall "error handling conventions" --project api

context returns your conventions, the most relevant memories, and open follow-ups in one pack. recall is the targeted version, and it is the step that stops an agent contradicting a decision you already made. --project matches a field in each memory note’s frontmatter, and the match is exact, so a typo returns an empty result that reads like “nothing recorded”.

The app and the CLI are free. The only paid part is Jotura Sync, which this loop does not need. One command installs the app, the CLI, and the agent skills into your home directory:

curl -fsSL jotura.io/install.sh | bash

irm jotura.io/install.ps1 | iex

If piping a remote script into your shell is not for you, the download page has the installers, and jotura skill install all wires up the agents afterwards. Name one with jotura skill install claude.

Recall hides stale memories by default

Recall skips anything superseded, resolved, or dated more than 180 days ago. Pass --include-stale to see those too, ranked below the fresh entries.

jotura memory recall "review" --kind decision --include-stale

That default is a filter, not a judgment. A six-month-old decision that is still correct vanishes from recall until you re-log or supersede it, so re-confirming what still holds is upkeep you own.

Log what a review settles

When a review produces a decision, record it while the reasoning is still in context.

jotura memory log --kind decision --title "Validation stays at the HTTP boundary, not in handlers" --project api --importance high

That writes Memory/Decisions/2026-08-30 validation-stays-at-the-http-boundary-not-in-handlers.md, with kind, status, importance, and date in its frontmatter. With no --body, a decision gets a section template: Context, Options considered, Decision and why, Outcome. To pipe the reasoning in instead, --body - reads it from standard input.

printf '%s' "$reasoning" | jotura memory log --kind decision --title "Validation stays at the HTTP boundary" --body -

The command also returns similar existing memories. That is your cue to supersede the old one rather than leave two notes disagreeing.

jotura memory supersede "Memory/Decisions/2026-02-11 validation-lives-in-handlers.md" --by "Memory/Decisions/2026-08-30 validation-stays-at-the-http-boundary-not-in-handlers.md"

Log deferred work as a follow-up, then close it by path when the fix lands.

jotura memory log --kind followup --title "Split the oversized request parser" --project api
jotura memory resolve "Memory/Followups/2026-08-30 split-the-oversized-request-parser.md"

Conventions that apply to every review

Rulings are specific. Conventions are general, and they belong in one note the agent reads before it files anything. jotura conventions prints it. The installed skill tells the agent to update that note when you correct its review feedback, because a correction from you is the strongest signal there is. Check that it did: the note is a file, and that one command shows its current state.

Getting recall to happen without asking

jotura hook install claude adds a SessionStart hook that injects the context digest when a Claude Code session begins, so the first review starts warm even if the agent never calls recall itself. It covers Claude Code only.

Keeping the memory honest

Read it yourself, regularly. The notes are ordinary markdown files in an ordinary folder, so open them and check what your agent believes. Edit or delete anything wrong. Our guide on auditing what your AI agent remembers goes through this in detail.

Treat old memories as claims, not laws. A decision about a service you have since rewritten deserves re-confirming, not obeying.

Close loops. A decision that turned out badly deserves its outcome appended. A follow-up that shipped deserves resolving. Memory that only ever grows becomes noise.

Sharing review conventions across a team

Agent configuration lives in an Agents folder inside the vault: instruction files, skills, and subagent definitions, all plain files. jotura agents sync writes them out to the machine-level locations each tool expects: ~/.claude/CLAUDE.md and skills, ~/.codex/AGENTS.md, ~/.gemini/GEMINI.md, and ~/.copilot/copilot-instructions.md. Those are your personal per-machine files, separate from anything committed in a repository.

jotura agents status
jotura agents sync --dry-run
jotura agents sync

Run the dry run first. When a file changed in both the vault and the system location, sync skips it and exits 16; resolve with --prefer vault or --prefer system.

Sharing that folder with teammates, or syncing it to a second machine of your own, needs Jotura Sync. It costs 4 pounds a month or 40 pounds a year, there is no free trial, and both sides need a subscription. Sync is end to end encrypted, so the server never sees your notes, your file names, or your keys. If you would rather not pay, commit the same conventions to the repository instead. Our guide to team-shared agent instructions covers that setup.

What this does not do

It does not make the agent a better reviewer of code it has never seen. Memory removes repetition and contradiction, which is most of the frustration, but review quality still comes from the model and the context you give it.

Mid-session recall stays discretionary. The hook covers the start of a session; after that the agent runs recall because its skill tells it to, and it can skip the step. If a review contradicts a decision you know is recorded, say so and ask it to check.

Writes are protected only when the agent asks. jotura read returns a content hash, and jotura edit --if-hash <hash> refuses the write and exits 2 if the file changed since that read. The flag is optional, so an agent that omits it can still overwrite a concurrent change. jotura memory log does not hash-check at all: two decisions logged under the same title on the same day land on one path, and the second wins.

Some product limits too. Jotura is closed source. There is no iOS app, no plugin system, no graph view, no canvas, and no publish-to-web. If any of those is a requirement, the repo-file approach above still works.

FAQ

Does the memory get sent to my AI provider? Only when your agent reads a note into its context, which is the point of recall. Jotura itself sends nothing: no telemetry, no tracking. The notes sit on your disk as plain markdown.

Can I use this with more than one coding agent? Yes. The memory notes and the Agents folder are shared, so Claude Code, Codex, Gemini, and Copilot read the same decisions.

Is a notes vault overkill if I only review one repository? Probably. Put the conventions in a file in that repository and let code review handle them. The vault earns its place when the knowledge spans repositories, machines, or agents. The CLI reference lists the full agent surface.