Agenten-Regeln

Den MCP-Endpunkt anzubinden ist die halbe Miete. Die andere Hälfte besteht darin, dass der Agent von sich aus bei der Wissensbasis anfängt und nicht erst nach deinem „schau doch zuerst in Notarium“. Auf dieser Seite geht es darum, das ein für alle Mal zu verankern.

Warum Anbinden allein nicht genügt

Welches Tool aufgerufen wird, entscheidet das Modell. Auf der Serverseite tut Notarium alles, was möglich ist: Bei der Initialisierung liefert es instructions mit („rufe start_session zuerst auf“), und die Beschreibung des Tools selbst sagt ausdrücklich, dass es idempotent und gefahrlos erneut aufrufbar ist. Das erhöht die Wahrscheinlichkeit deutlich, ist aber keine Garantie — und kann es von der Konstruktion des Protokolls her auch nicht sein.

Die Garantie liegt auf deiner Seite: in der Dauerinstruktion des Agenten. Der praktische Effekt ist simpel — entweder beginnt der Agent die Session mit dem Kontext des Projekts, oder du erinnerst ihn jedes Mal von Hand daran, und die Zusammenarbeit fühlt sich nicht mehr nativ an.

Ein ausgelassener Aufruf bricht nichts

Ein fehlendes start_session bricht die Arbeit nicht: Die übrigen Tools stehen für sich, und die Zugriffsgrenzen hält das Token, nicht die Disziplin des Agenten. Der Unterschied liegt allein im Kontext — der Agent sieht weder dein Profil noch das Delta der Änderungen oder das Wörterbuch der vereinbarten Kategorien, und legt damit eher ein Duplikat an oder benennt Dinge auf seine eigene Weise.

Wohin damit

Fast jeder Agenten-Client hat eine Datei mit Dauerinstruktionen, die in jede Session einfließt:

Client	Wo sie üblicherweise liegt
Claude Code	`CLAUDE.md` im Wurzelverzeichnis des Repositorys (dazu eine globale im Home-Verzeichnis)
Codex	`AGENTS.md` im Wurzelverzeichnis des Repositorys
Cursor	Projektregeln in `.cursor/rules`
Eigener Agent oder API-Integration	der System-Prompt

Format und genaue Pfade gibt der Client vor; sie ändern sich unabhängig von uns — schau in dessen Dokumentation. Notarium stellt keinerlei Anforderungen an die Datei: Es ist schlichter Text, den dein Agent liest.

Der minimale Block

Drei Regeln decken das Hauptszenario ab — mit Kontext beginnen, keine Duplikate anlegen, Wissen dort ablegen, wo es hingehört:

## Notarium — die Wissensbasis des Projekts

- Rufe zu Beginn einer neuen Session `start_session(project: "acme/website")`
  auf dem MCP-Server `notarium` auf — Profil, verfügbare Projekte, Index
  dieses Projekts, Delta der Änderungen seit dem letzten Besuch und das
  Wörterbuch der Kategorien.
- **Suche vor dem Schreiben:** `search("<Thema>", project: "acme/website")` —
  die Suche deckt auch dein eigenes Gedächtnis ab, dadurch werden
  Duplikate erkannt.
- Halte dauerhafte Fakten über das Projekt mit `remember_about_project` fest,
  über den Eigentümer mit `remember_about_user`, gemeinsam sichtbares Wissen
  mit `create_note`.

Setz dein eigenes Projekt-Handle ein. Üblicherweise hat es die Form space/project, beim Wurzelprojekt eines Space fällt es jedoch auf ein einziges Segment zusammen — nur space. Leite es nicht aus einer Regel ab: Die fertige Liste liefert get_my_projects, von dort übernimmst du es wortwörtlich. In einer Regeldatei trägst du den exakten Wert besser fest ein, damit der Agent ihn nicht jedes Mal suchen muss.

Ein Aufruf statt fünf

Genau dafür ist start_session gebaut: Eine einzige Anfrage liefert das, wofür sonst mehrere Erkundungsaufrufe und zusätzlicher Kontext nötig wären. Es ist idempotent — es nach dem Komprimieren des Kontexts erneut aufzurufen ist gefahrlos und hat keine Nebenwirkungen. Das Einzige, was sich nicht wiederholt, ist das Delta der Änderungen: Der erste Aufruf verschiebt standardmäßig das Lesezeichen „letzter Besuch“, der zweite kommt deshalb leer zurück. Wer das Delta sehen will, ohne das Lesezeichen zu verschieben, ruft es mit acknowledge: false auf.

Der erweiterte Block: eine Karte des Kanons

Hat ein Projekt Notizen, die für eine bestimmte Rolle oder Aufgabe gelesen werden sollten, lass den Agenten nicht jede Session aufs Neue danach suchen — gib ihm eine Karte. Ein paar gezielte Notizen zu laden ist billiger als „lies das ganze Projekt“:

## Notarium

- Erster Aufruf — `start_session(project: "acme/website")`.
- Lade danach gezielt einzelne Notizen, statt das ganze Projekt zu lesen:
  - Entwicklungskonventionen — `get_note("<id>")`;
  - Review-Checkliste — `get_note("<id>")`;
  - Kontext rund um ein Thema — `recall("<Thema>", project: "acme/website")`.
- Vor jedem Schreiben — `search("<Thema>", project: "acme/website")`.
- Halte Arbeitsprotokoll und Entscheidungen zu einer Aufgabe in Notarium
  fest, nicht in Dateien des Repositorys.

Notiz-IDs sind stabil: Sie überstehen Umbenennen und Verschieben, deshalb verrottet die Karte nicht, wenn du die Wissensbasis umbaust. Auch ein Link [[nach Titel]] bricht beim Umbenennen nicht — der alte Titel wandert in den Alias-Verlauf.

Zwei Ebenen von Regeln

Trenne Anweisungen nach ihrer Lebensdauer — so musst du sie nicht in jedem Repository duplizieren:

Die globale Ebene (eine gemeinsame Regeldatei oder der System-Prompt) — was immer gilt: start_session zuerst aufrufen, vor dem Schreiben suchen, wohin Fakten über den Eigentümer gehören. Kein Projekt-Handle an dieser Stelle.
Die Projektebene (eine Datei im Repository) — das Handle dieses konkreten Projekts, die Karte des Kanons, lokale Absprachen.

Ein neues Repository an die Wissensbasis anzubinden ist dann eine Sache von wenigen Zeilen mit einem einzigen Handle, während die gemeinsamen Regeln an einer Stelle liegen.

Was in den Regeln nichts zu suchen hat

Agenten-Regeln sind kein Sicherheitsmechanismus

Eine Regeldatei ist ein Hinweis, keine Grenze. Was ein Agent tun kann, bestimmen die Berechtigungen des Tokens und der Satz an Tools: Ein read-Token sieht die schreibenden Tools physisch nicht, ein fremder Space ist prinzipbedingt unerreichbar. Versuch nicht, einen Agenten mit Text einzuhegen, wo der Scope des Tokens gebraucht wird — siehe Sicherheit und Sichtbarkeit.

Zwei weitere Dinge, die dort nicht landen sollten:

Tokens. Eine Regeldatei liegt üblicherweise in git. Ein persönliches Token gehört in die Konfiguration deines MCP-Clients, nicht in eine Anweisung.
Eine Nacherzählung der Tool-Referenz. Namen und Beschreibungen sieht der Agent ohnehin in tools/list; sie sind statisch und immer aktuell. Eine Kopie in der Regeldatei driftet schnell von der Realität weg — schreib Absichten und Absprachen auf, kein Duplikat der Dokumentation.

Wie das mit der Kuratierung des Kontexts zusammenspielt

Zwei Hälften einer Aufgabe, und keine ersetzt die andere:

Die Regeldatei sorgt dafür, dass der Aufruf von start_session überhaupt stattfindet.
Der Bereich Agents → Context entscheidet, was genau dieser Aufruf zurückbringt: always-load-Pins, Kontext-Sets und die Stummschaltung verrauschter Gedächtniskategorien — alles unter einem gemeinsamen Token-Budget.

Startet der Agent also mit Kontext, aber nicht mit dem richtigen, korrigiere nicht die Regeldatei, sondern Kontext-Sets und Pins.

Weiter

Einen Agenten anbinden — Token, OAuth-Connector, Transport.
Kontext-Sets und Pins — was in start_session einfließt.
Intent-Tools — der vollständige Satz und die Reihenfolge der Aufrufe.
Agentengedächtnis — worin sich remember_* von create_note unterscheidet.