How to review what AI agents change in your notes

When you let an AI agent work in your notes, you need a way to check its changes before you rely on them. A coding agent is fast and fluent, and that's the problem: a wrong sentence reads exactly like a right one. In code, a test often fails when an agent gets something wrong. In a knowledge base, nothing fails. The wrong date just sits there.

A few things go wrong again and again:

• Quiet rewrites. You ask for a new note and the agent also "tidies" three old ones, changing the meaning of a sentence you wrote carefully.
• Overwritten edits. You fixed a number by hand yesterday. Today the agent rewrites the note from an older source and your fix is gone.
• Errors that spread. The next session reads the wrong fact as context, repeats it in two more notes, and now it looks confirmed.
• No record. A month later you can't tell which notes you wrote, which an agent wrote, and which anyone ever checked.

The fix has two parts: see every change before it sticks, and write down who checked what. This guide shows how to do both by hand with git and a few frontmatter fields, and after each step, how Knowtarium handles it. We build Knowtarium for this kind of review.

Git is the best free tool for this job. If your notes are a folder of markdown files, put them under git and commit before every agent session. Then everything the agent does is a diff you can read, keep in part, or throw away.

# once, in your notes folder
git init
git add -A && git commit -m "Notes before agents"
 
# before each agent session: a clean starting point on its own branch
git switch -c agent/2026-09-26-cleanup

Working on a branch keeps your main history clean: if the whole session was a mistake, you switch back and delete the branch. When the agent is done, read what it changed:

# which files changed, and how much
git status
git diff --stat
 
# read the changes word by word, which suits prose better than whole lines
git diff --word-diff
 
# keep the hunks you agree with (y = keep, n = skip, s = split, e = edit)
git add -p
git commit -m "Keep claude-code edits to pricing notes"
 
# throw away everything you didn't keep
git restore .
 
# back on main, bring in what you approved
git switch main
git merge agent/2026-09-26-cleanup

git add -p is the part that makes this a real review. It walks you through each changed hunk and lets you stage it or skip it, so you can keep the new note and drop the unrequested rewrite of an old one. Press s to split a large hunk into smaller ones and e to edit one by hand.

Put the agent's name in the commit message. git log then tells you which session wrote what, and git log -p -- path/to/note.md shows a single note's full history.

If you use Claude Code, it has three features that help. None of them replaces git, but they catch problems earlier.

Permission modes

A permission mode decides what Claude can do without asking. In Manual mode (config value default) it asks before editing files. acceptEdits lets it edit without asking, which Anthropic suggests when you'd rather review with git diff afterwards. plan mode has Claude research and propose changes without making them until you approve the plan. Press Shift+Tab to cycle modes during a session. Recent versions start interactive sessions in auto mode, where a classifier reviews actions instead of you, so switch to Manual or plan mode for sessions in notes you care about.

Checkpoints

Claude Code saves a checkpoint before each prompt you send. Run /rewind, or press Esc twice with an empty prompt, to restore the files, the conversation, or both. Know the limits: checkpoints don't track files changed by shell commands like mv or rm, usually don't restore edits made by subagents, and are deleted after about 30 days by default. Anthropic's docs say plainly that checkpoints are not a replacement for version control.

Permission rules

Rules in .claude/settings.json block or gate edits to specific folders. Deny rules win over everything else and apply in every mode:

{
  "permissions": {
    "ask": ["Edit(/decisions/**)"],
    "deny": ["Edit(/journal/**)", "Edit(/people/**)"]
  }
}

Here Claude can never edit journal/ or people/, and it has to ask before touching decisions/. Edit rules cover Claude's built-in file tools and file commands it recognises in the shell, but not a script that opens files itself. For a hard guarantee, Anthropic points to its sandbox.

Most agents read an instructions file before they start: AGENTS.md for Codex, Cursor and many others, CLAUDE.md for Claude Code. Put your editing rules there. Keep them short and concrete enough to check:

## Changing documents
 
- Never delete a document. Set `status: deprecated` and say why.
- Never edit files in journal/ or people/.
- Don't rewrite a paragraph you weren't asked to change.
- Sign every document you write in `generated`, with your name and version.
- Never add a `human:` entry to `verified`. Only a person does that.
- End the session with a list of every file you created, changed or moved.

The last rule is the useful one for review: a list of every touched file, which you can compare with git status. If they differ, look closer.

Instructions are context, not a lock. Anthropic's docs describe CLAUDE.md as something Claude reads, not configuration it enforces, which is why the permission rules above exist. Our guide to AGENTS.md and CLAUDE.md for a knowledge base has a full template.

On macOS and Linux you can also make a folder read-only with chmod -R a-w journal/. Treat it as a speed bump: an agent that can run shell commands can change permissions back.

A diff tells you what changed today. It doesn't tell next month's reader whether anyone checked a note. For that, write it into the note itself. The Open Knowledge Format (OKF), an open specification published by Google Cloud, has fields for exactly this:

---
type: Decision
title: Switch billing to annual plans
generated: { by: claude-code/2.1, at: 2026-09-26T09:12:00Z }
verified:
  - { by: human:maya, at: 2026-09-26T11:40:00Z }
stale_after: 2027-03-31T00:00:00Z
---

• generated says who wrote the current content and when. Agents sign as name/version, people as human:name.
• verified lists everyone who checked it since, with the time. A document with no entry is unverified, one checked only by agents or processes is machine-confirmed, and one checked by a human: actor is human-reviewed.
• stale_after is the moment the document stops being safe to quote.

The routine is simple. The agent writes and signs generated, never verified. You review the diff, then add your own verified entry. With that in place, finding what nobody has checked is one command:

# documents nobody has checked yet: no verified line at all
grep -rL "^verified:" --include="*.md" .

1. Commit, then start a branch for the session.
2. Start the agent in Manual or plan mode, with deny rules for folders it should never touch.
3. Give it one task. Ask for a list of touched files at the end.
4. Compare that list with git status, then read git diff --word-diff.
5. Keep what you agree with using git add -p, and restore the rest.
6. Add your verified entry to each note you checked, commit with the agent's name in the message, and merge.

Each tool catches something different:

For a few dozen notes and one agent, git and this routine can be enough. It gets tedious when agents write every day, when one change touches ten notes, or when your own edit makes five other notes wrong without you noticing. That's the part Knowtarium is built for: agent changes wait in its queue, and your own edits wait there until you ask an agent to check them.

Knowtarium turns the routine above into a review queue on top of the same OKF files. Your agents keep working on the folder directly, and the app shows you what they did and what still needs a look.

The review queue

One list holds everything waiting for a check:

• changes an agent made, waiting for you;
• edits you made, waiting for an agent to check them;
• documents past their stale_after date, and the ones that expire in the next 30 days.

Diffs, then approve

Open an item and you see the change as a diff against the last verified version, with the document's full history. Approve it, or send it back with a comment. Approving adds you to verified with the time, which is the human: entry you'd otherwise type by hand.

Checks in both directions

The review runs the other way too. When you edit a document yourself, the edit is marked as yours and waits in the queue until an agent checks it against every connected document. Knowtarium doesn't call an AI itself: you ask your agent to check today's edits, and it proposes fixes wherever something no longer matches. Those fixes wait for your review like any other change.

Trust tiers

The same rules hold for every agent: agents can't mark anything as checked by a person, can't overwrite an edit you made (conflicts come to you), and can't skip your review. Knowtarium runs on macOS, Windows and Linux. See the features and how agents connect.