Règles de l'agent

Brancher l'endpoint MCP, c'est la moitié du travail. L'autre moitié consiste à amener l'agent à démarrer de lui-même depuis la base de connaissances, plutôt qu'après votre « va d'abord voir dans Notarium ». Cette page explique comment le graver une bonne fois pour toutes.

Pourquoi la connexion ne suffit pas

Quel outil appeler, c'est le modèle qui en décide. De son côté de la connexion, Notarium fait tout ce qu'il peut : à l'initialisation, il transmet le champ instructions (« appelle start_session en premier »), et la description de l'outil lui-même dit noir sur blanc qu'il est idempotent et qu'on peut le rappeler sans risque. Cela améliore nettement les chances, mais ce n'est pas une garantie — et, par construction du protocole, cela ne peut pas l'être.

La garantie, elle, vit de votre côté : dans les instructions permanentes de l'agent. L'effet pratique est simple : soit l'agent ouvre une session avec le contexte du projet, soit vous le lui rappelez à la main chaque fois, et l'interaction cesse d'être native.

Un appel manqué ne casse rien

L'absence de start_session ne casse pas le travail : les autres outils se suffisent à eux-mêmes, et les limites d'accès sont tenues par le jeton, pas par la discipline de l'agent. La seule différence tient au contexte — l'agent ne verra ni votre profil, ni le delta des changements, ni le dictionnaire des catégories convenues, ce qui le rend plus enclin à créer un doublon ou à nommer les choses à sa façon.

Où l'écrire

Presque tous les clients d'agents disposent d'un fichier d'instructions permanentes, injecté dans chaque session :

Client	Où il se trouve habituellement
Claude Code	`CLAUDE.md` à la racine du dépôt (plus un fichier global dans votre répertoire personnel)
Codex	`AGENTS.md` à la racine du dépôt
Cursor	les règles de projet dans `.cursor/rules`
Votre propre agent ou une intégration API	le prompt système

Le format et les chemins exacts sont fixés par le client, qui les fait évoluer indépendamment de nous — reportez-vous à sa documentation. Notarium n'exige rien de ce fichier : c'est du texte brut que lit votre agent.

Le bloc minimal

Trois règles couvrent le scénario principal — partir du contexte, ne pas créer de doublons, ranger le savoir là où il doit aller :

## Notarium — la base de connaissances du projet

- Au début d'une nouvelle session, appelle `start_session(project: "acme/website")`
  sur le serveur MCP `notarium` — profil, projets accessibles, index de ce
  projet, delta des changements depuis ta dernière visite et dictionnaire
  des catégories.
- **Cherche avant d'écrire :** `search("<sujet>", project: "acme/website")` —
  la recherche couvre aussi ta propre mémoire, les doublons sont donc repérés.
- Consigne les faits durables sur le projet via `remember_about_project`,
  ceux sur le propriétaire via `remember_about_user`, le savoir partagé
  et visible via `create_note`.

Mettez-y votre propre handle de projet. Il a généralement la forme space/project, mais pour le projet racine d'un espace il se réduit à un seul segment — simplement space. Ne le déduisez pas d'une règle : get_my_projects renvoie la liste toute faite, reprenez-le de là mot pour mot. Dans un fichier de règles, mieux vaut figer la valeur exacte, pour que l'agent n'ait pas à la chercher chaque fois.

Un appel au lieu de cinq

start_session est fait exactement pour ça : une seule requête renvoie ce qui, autrement, coûterait plusieurs appels exploratoires et du contexte en trop. Il est idempotent — le rappeler après une compaction du contexte est sans risque et sans effet de bord. La seule chose qui ne se répétera pas, c'est le delta des changements : par défaut, le premier appel déplace le signet de la « dernière visite », si bien qu'un second appel revient vide. Pour jeter un œil au delta sans déplacer le signet, appelez-le avec acknowledge: false.

Le bloc étendu : une carte du canon

Si un projet contient des notes à lire pour un rôle ou une tâche donnés, n'obligez pas l'agent à les retrouver à chaque session — donnez-lui une carte. Charger quelques notes précises coûte moins cher que « lis tout le projet » :

## Notarium

- Premier appel — `start_session(project: "acme/website")`.
- Ensuite, charge des notes précises plutôt que de lire le projet entier :
  - conventions de développement — `get_note("<id>")` ;
  - checklist de revue — `get_note("<id>")` ;
  - contexte autour d'un sujet — `recall("<sujet>", project: "acme/website")`.
- Avant toute écriture — `search("<sujet>", project: "acme/website")`.
- Tiens le journal de travail et les décisions d'une tâche dans Notarium,
  pas dans les fichiers du dépôt.

Les identifiants de notes sont stables : ils survivent à un renommage comme à un déplacement, la carte ne se périme donc pas quand vous réorganisez la base. Un lien [[par titre]] ne se casse pas non plus lors d'un renommage — l'ancien titre part dans l'historique des alias.

Deux couches de règles

Séparez les instructions selon leur durée de vie — vous n'aurez ainsi pas à les dupliquer dans chaque dépôt :

La couche globale (un fichier de règles partagé ou le prompt système) — ce qui est vrai en toutes circonstances : appeler start_session en premier, chercher avant d'écrire, où vont les faits sur le propriétaire. Pas de handle de projet ici.
La couche projet (un fichier dans le dépôt) — le handle de ce projet précis, la carte du canon, les accords locaux.

Brancher un nouveau dépôt sur la base de connaissances se résume alors à quelques lignes et un seul handle, tandis que les règles communes tiennent en un seul endroit.

Ce qui n'a pas sa place dans les règles

Les règles de l'agent ne sont pas un mécanisme de sécurité

Un fichier de règles est une indication, pas une frontière. Ce qu'un agent peut faire est déterminé par les permissions du jeton et le jeu d'outils : un jeton en lecture ne voit physiquement pas les outils d'écriture, et l'espace d'autrui reste hors d'atteinte par principe. N'essayez pas d'enfermer un agent avec du texte là où c'est la portée du jeton qu'il faut — voir Sécurité et visibilité.

Deux autres choses qui ne doivent pas y atterrir :

Les jetons. Un fichier de règles finit généralement dans git. Un jeton personnel se déclare dans la configuration de votre client MCP, pas dans une instruction.
Une paraphrase de la documentation de référence des outils. L'agent voit déjà les noms et les descriptions dans tools/list ; ils sont statiques et toujours à jour. Une copie dans le fichier de règles s'écarte vite de la réalité — écrivez des intentions et des accords, pas un doublon de la documentation.

Comment cela s'articule avec la curation du contexte

Deux moitiés d'une même tâche, dont aucune ne remplace l'autre :

Le fichier de règles garantit que l'appel à start_session a bien lieu.
La section Agents → Context décide de ce que cet appel rapporte : épingles always-load, jeux de contexte et mise en sourdine des catégories de mémoire bruyantes — le tout sous un budget de tokens commun.

Donc, si l'agent démarre avec du contexte mais pas le bon, le correctif n'est pas dans le fichier de règles — il est dans les jeux de contexte et épingles.

Ensuite

Connecter un agent — jeton, connecteur OAuth, transport.
Jeux de contexte et épingles — ce qui entre dans start_session.
Outils d'intention — le jeu complet et l'ordre des appels.
Mémoire de l'agent — en quoi remember_* diffère de create_note.