So prüfst du, was KI-Agenten in deinen Notizen ändern

Wenn du einen KI-Agenten in deinen Notizen arbeiten lässt, brauchst du einen Weg, seine Änderungen zu prüfen, bevor du dich darauf verlässt. Ein Coding-Agent ist schnell und formuliert flüssig, und genau das ist das Problem: Ein falscher Satz liest sich genauso wie ein richtiger. Bei Code schlägt oft ein Test fehl, wenn ein Agent etwas falsch macht. In einer Wissensdatenbank schlägt nichts fehl. Das falsche Datum steht einfach da.

Ein paar Dinge gehen immer wieder schief:

• Stille Umformulierungen. Du bittest um eine neue Notiz, und der Agent „räumt“ nebenbei drei alte auf und ändert dabei den Sinn eines Satzes, den du sorgfältig geschrieben hast.
• Überschriebene Änderungen. Du hast gestern von Hand eine Zahl korrigiert. Heute schreibt der Agent die Notiz aus einer älteren Quelle neu, und deine Korrektur ist weg.
• Fehler, die sich ausbreiten. Die nächste Sitzung liest den falschen Fakt als Kontext, wiederholt ihn in zwei weiteren Notizen, und jetzt sieht er bestätigt aus.
• Keine Aufzeichnung. Einen Monat später kannst du nicht mehr sagen, welche Notizen du geschrieben hast, welche ein Agent und welche je jemand geprüft hat.

Die Lösung hat zwei Teile: jede Änderung sehen, bevor sie bleibt, und aufschreiben, wer was geprüft hat. Diese Anleitung zeigt, wie du beides von Hand mit Git und ein paar Frontmatter-Feldern machst, und nach jedem Schritt, wie Knowtarium es handhabt. Genau dafür bauen wir Knowtarium: Änderungen von Agenten sind dort standardmäßig signiert und lassen sich rückgängig machen, und eine Prüfung, bevor eine Änderung bleibt, schaltest du pro Ordner ein.

Git ist das beste kostenlose Tool für diese Aufgabe. Wenn deine Notizen ein Ordner mit Markdown-Dateien sind, stell sie unter Git und committe vor jeder Agenten-Sitzung. Dann ist alles, was der Agent tut, ein Diff, den du lesen, zum Teil behalten oder verwerfen kannst.

# einmal, in deinem Notizordner
$ git init$ git add -A && git commit -m "Notes before agents"
 
# vor jeder Agenten-Sitzung: ein sauberer Ausgangspunkt auf einem eigenen Branch
$ git switch -c agent/2026-09-26-cleanup

Ein Branch hält deinen Hauptverlauf sauber: War die ganze Sitzung ein Fehler, wechselst du zurück und löschst den Branch. Wenn der Agent fertig ist, lies, was er geändert hat:

# welche Dateien sich geändert haben, und wie stark
$ git status$ git diff --stat
 
# die Änderungen Wort für Wort lesen, das passt besser zu Text als ganze Zeilen
$ git diff --word-diff
 
# die Stücke behalten, mit denen du einverstanden bist (y = behalten, n = überspringen, s = teilen, e = bearbeiten)
$ git add -p$ git commit -m "Keep claude-code edits to pricing notes"
 
# alles verwerfen, was du nicht behalten hast
$ git restore .
 
# zurück auf main, das Freigegebene übernehmen
$ git switch main$ git merge agent/2026-09-26-cleanup

git add -p macht daraus eine echte Prüfung. Es geht jedes geänderte Stück (Hunk) mit dir durch und lässt dich es übernehmen oder überspringen, so behältst du die neue Notiz und verwirfst das ungefragte Umschreiben einer alten. Drück s, um ein großes Stück in kleinere zu teilen, und e, um eines von Hand zu bearbeiten.

Schreib den Namen des Agenten in die Commit-Nachricht. Dann sagt dir git log, welche Sitzung was geschrieben hat, und git log -p -- path/to/note.md zeigt den ganzen Verlauf einer einzelnen Notiz.

In Knowtarium

In Knowtarium wird jede Änderung eines Agenten als neue Version gespeichert, signiert mit dem eigenen Schlüssel des Agenten. Der Verlauf der Notiz listet also jede Version mit Urheber und Zeitpunkt, See changes zeigt die Änderung des Agenten als Diff, und Undo holt die vorherige Version zurück. Für Ordner, die du vorher lesen willst, schalte Review ein („Ask me first“): Änderungen von Agenten warten dort als Diffs, bis du sie freigibst oder mit einem Kommentar ablehnst.

(öffnet in voller Größe in einem neuen Tab) (öffnet in voller Größe in einem neuen Tab)

Wenn du Claude Code nutzt, helfen dir drei seiner Funktionen. Keine davon ersetzt Git, aber sie fangen Probleme früher ab.

Berechtigungsmodi

Ein Berechtigungsmodus legt fest, was Claude tun darf, ohne zu fragen. Im Modus Manual (Konfigurationswert default) fragt es, bevor es Dateien bearbeitet. acceptEdits lässt es ohne Nachfrage bearbeiten, was Anthropic empfiehlt, wenn du lieber hinterher mit git diff prüfst. Im Modus plan recherchiert Claude und schlägt Änderungen vor, ohne sie umzusetzen, bis du den Plan freigibst. Mit Shift+Tab wechselst du während einer Sitzung durch die Modi. Neuere Versionen starten interaktive Sitzungen im Auto-Modus, in dem ein Klassifikator die Aktionen prüft statt du. Wechsle also für Sitzungen in Notizen, die dir wichtig sind, in den Modus Manual oder plan.

Checkpoints

Claude Code speichert vor jedem Prompt, den du schickst, einen Checkpoint. Führ /rewind aus oder drück bei leerem Prompt zweimal Esc, um die Dateien, das Gespräch oder beides wiederherzustellen. Kenn die Grenzen: Checkpoints verfolgen keine Dateien, die durch Shell-Befehle wie mv oder rm geändert wurden, stellen Änderungen von Subagenten meist nicht wieder her und werden standardmäßig nach etwa 30 Tagen gelöscht. Die Doku von Anthropic sagt klar, dass Checkpoints kein Ersatz für eine Versionsverwaltung sind.

Berechtigungsregeln

Regeln in .claude/settings.json sperren Änderungen an bestimmten Ordnern oder machen sie von einer Nachfrage abhängig. Deny-Regeln haben Vorrang vor allem anderen und gelten in jedem Modus:

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

Hier darf Claude journal/ und people/ nie bearbeiten und muss fragen, bevor es decisions/ anfasst. Edit-Regeln gelten für Claudes eingebaute Datei-Tools und für Dateibefehle, die es in der Shell erkennt, aber nicht für ein Skript, das selbst Dateien öffnet. Für eine harte Garantie verweist Anthropic auf seine Sandbox.

Die meisten Agenten lesen vor dem Start eine Datei mit Anweisungen: AGENTS.md bei Codex, Cursor und vielen anderen, CLAUDE.md bei Claude Code. Schreib deine Regeln fürs Bearbeiten dort hinein. Halte sie kurz und so konkret, dass man sie überprüfen kann:

## Dokumente ändern
 
- Lösch nie ein Dokument. Setz `status: deprecated` und sag, warum.
- Bearbeite nie Dateien in journal/ oder people/.
- Schreib keinen Absatz um, den du nicht ändern solltest.
- Signiere jedes Dokument, das du schreibst, in `generated`, mit deinem Namen und deiner Version.
- Füg nie einen `human:`-Eintrag zu `verified` hinzu. Das macht nur ein Mensch.
- Beende die Sitzung mit einer Liste aller Dateien, die du angelegt, geändert oder verschoben hast.

Die letzte Regel ist die nützlichste für die Prüfung: eine Liste aller angefassten Dateien, die du mit git status vergleichen kannst. Weichen sie voneinander ab, schau genauer hin.

Anweisungen sind Kontext, kein Schloss. Die Doku von Anthropic beschreibt CLAUDE.md als etwas, das Claude liest, nicht als Konfiguration, die es durchsetzt; deshalb gibt es die Berechtigungsregeln oben. Unsere Anleitung zu AGENTS.md und CLAUDE.md für eine Wissensdatenbank hat eine vollständige Vorlage.

Unter macOS und Linux kannst du einen Ordner außerdem mit chmod -R a-w journal/ schreibschützen. Sieh das als Bremsschwelle: Ein Agent, der Shell-Befehle ausführen kann, kann die Rechte auch wieder ändern.

Ein Diff sagt dir, was sich heute geändert hat. Er sagt der Person, die nächsten Monat liest, nicht, ob jemand eine Notiz geprüft hat. Dafür schreibst du es in die Notiz selbst. Das Open Knowledge Format (OKF), eine offene Spezifikation von Google Cloud, hat genau dafür Felder:

---
type: Decision
title: Abrechnung auf Jahrespläne umstellen
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 sagt, wer den aktuellen Inhalt wann geschrieben hat. Agenten signieren als name/version, Menschen als human:name.
• verified listet alle, die ihn seitdem geprüft haben, mit Zeitpunkt. Ein Dokument ohne Eintrag ist unverified, eines, das nur Agenten oder Prozesse geprüft haben, ist machine-confirmed, und eines, das ein human:-Akteur geprüft hat, ist human-reviewed.
• stale_after ist der Zeitpunkt, ab dem man das Dokument nicht mehr bedenkenlos zitieren kann.

Die Routine ist einfach. Der Agent schreibt und signiert generated, nie verified. Du prüfst den Diff und fügst dann deinen eigenen verified-Eintrag hinzu. Steht das, findest du mit einem einzigen Befehl, was noch niemand geprüft hat:

# Dokumente, die noch niemand geprüft hat: gar keine verified-Zeile
$ grep -rL "^verified:" --include="*.md" .

1. Committe und leg dann einen Branch für die Sitzung an.
2. Starte den Agenten im Modus Manual oder plan, mit Deny-Regeln für Ordner, die er nie anfassen soll.
3. Gib ihm eine Aufgabe. Bitte am Ende um eine Liste der angefassten Dateien.
4. Vergleich diese Liste mit git status und lies dann git diff --word-diff.
5. Behalte mit git add -p, womit du einverstanden bist, und stell den Rest wieder her.
6. Füg jeder Notiz, die du geprüft hast, deinen verified-Eintrag hinzu, committe mit dem Namen des Agenten in der Nachricht und merge.

Jedes Tool fängt etwas anderes ab:

Für ein paar Dutzend Notizen und einen Agenten können Git und diese Routine reichen. Mühsam wird es, wenn Agenten jeden Tag schreiben, wenn eine Änderung zehn Notizen betrifft oder wenn deine eigene Änderung fünf andere Notizen falsch macht, ohne dass du es merkst. Genau dafür ist Knowtarium gebaut: Jede Änderung eines Agenten ist signiert und einen Klick vom Rückgängigmachen entfernt, und wo du Review einschaltest, warten Änderungen von Agenten auf dich und deine eigenen Änderungen, bis du einen Agenten bittest, sie zu prüfen.

Knowtarium baut die Routine von oben in eine Ende-zu-Ende-verschlüsselte Wissensdatenbank ein. Deine Agenten verbinden sich über MCP und arbeiten an denselben OKF-Dokumenten, und die App zeigt dir, was sie getan haben und was noch einen Blick braucht. Die Prüfung gibt es in zwei Stärken: standardmäßig Undo für jede Änderung, und vorherige Freigabe, wo du sie haben willst.

Jede Änderung signiert und rückgängig zu machen

Standardmäßig wird die Änderung eines Agenten sofort als nächste Version des Dokuments gespeichert, signiert mit dem eigenen Schlüssel des Agenten. Ein Punkt in der Seitenleiste markiert die Dokumente, die er bearbeitet hat, bis du sie öffnest, eine Zeile unter dem Titel sagt, welcher Agent wann, mit einem Link zu den Änderungen und einem Undo, und die Seite des Workspace listet, was Agenten in den letzten 14 Tagen bearbeitet haben. Undo holt die vorherige Version als deine eigene Änderung zurück, und der Verlauf bewahrt jede Version zum Wiederherstellen auf, so lange du einstellst (zu Beginn 30 Tage, bis zu einem Jahr).

Ask me first: erst Diffs, dann Freigabe

Schalte Review für einen Workspace oder einen Ordner ein, und Änderungen von Agenten warten dort stattdessen als Vorschläge. Öffne einen, und du siehst den Diff mit der Zusammenfassung des Agenten und wer ihn vorgeschlagen hat. Gib ihn frei, lehn ihn mit einem Kommentar ab oder gib mehrere auf einmal frei. Die Freigabe trägt dich mit Uhrzeit in verified ein, das ist der human:-Eintrag, den du sonst von Hand tippen würdest. Der Vorschlag des Agenten bringt seine eigene Prüfung schon mit, also ist die Notiz nach deiner Freigabe vollständig verifiziert.

(öffnet in voller Größe in einem neuen Tab) (öffnet in voller Größe in einem neuen Tab)

In diesen Ordnern sammelt eine Liste alles, was auf eine Prüfung wartet:

• Änderungen, die ein Agent vorgeschlagen hat und die auf dich warten;
• Änderungen, die du gemacht hast und die auf die Prüfung durch einen Agenten warten;
• Konflikte, die ein Agent beim Prüfen gefunden hat.

Dokumente, deren stale_after-Datum vorbei ist oder bald kommt, stehen auf der Seite Stale and expiring, egal, wo sie liegen.

Prüfungen in beide Richtungen

In Ordnern mit Review läuft die Prüfung auch andersherum. Wenn du selbst ein Dokument bearbeitest, ist die Änderung als deine signiert und wartet in der Liste, bis ein Agent sie mit jedem verbundenen Dokument abgleicht. Knowtarium ruft selbst keine KI auf: Du bittest deinen Agenten, die Änderungen von heute zu prüfen, und er erfasst seine Prüfung oder meldet einen Konflikt, wo etwas nicht mehr zusammenpasst.

Vertrauensstufen

In Ordnern mit Review hat jedes Dokument eine Vertrauensstufe:

Für jeden Agenten gelten dieselben Regeln: Agenten können nichts als von einem Menschen geprüft markieren, sie löschen ein Dokument nur, wenn du ihnen das erlaubt hast, und in Ordnern mit Review können sie deine Prüfung nicht überspringen. Deine Dokumente sind Ende-zu-Ende-verschlüsselt, wir können sie also nicht lesen; die Agenten, die du verbindest, sehen, was sie lesen. Sieh dir die Funktionen an und wie sich Agenten verbinden.