Projets et règles

Prononcez le nom quand vous enregistrez ou cherchez, et le projet existe à partir de ce moment — pas de structure de dossiers, pas de configuration ; en créer un coûte dix messages. Chaque projet a sa propre mémoire, ses propres connaissances et son propre focus, défini par un objectif d'une ligne. En local, le stockage est votre propre disque et ne regarde que vous ; en hébergé, votre forfait inclut une quantité fixe, et vous pouvez en ajouter quand vous en avez besoin. La mémoire de votre application n'est qu'un projet de plus, fonctionnant sur la même mécanique.

Chaque projet est un spécialiste. Il possède sa propre mémoire, ses propres règles, son propre historique de décisions. Lorsque vous ouvrez une session, votre agent arrive déjà informé : des règles, de l’état des choses, de ce qui a été décidé la semaine dernière. Vous n’avez pas besoin de tout expliquer à nouveau. Vous n’avez pas besoin de le lui rappeler. Les informations nécessaires sont déjà là.

La somme nécessaire pour financer le reste du projet

La minute la plus précieuse dans ce produit est celle que vous consacrez à définir les règles d’un projet. Écrivez-les une fois : comment ce projet doit être mené, ce qui est important, ce qu’il faut éviter – et chaque session qui s’ouvre par la suite les connaîtra automatiquement.

On ne raconte jamais l’histoire de son projet deux fois, ni à un nouvel agent, ni sur une autre machine. Ce temps d’une minute est consacré une seule fois, et l’agent qui arrivera demain le sait déjà.

Notes : où la dernière session s'est arrêtée

Votre agent rédige sa propre passation — où en est le travail, ce qui est en cours, ce qui vient ensuite — une note par session et par projet, les cinq dernières conservées. La session suivante s'ouvre avec elle. Vous démarrez le PC, dites « continue », et il reprend là où il s'était arrêté.

La couche d’équipe, à vos conditions

Quand vous partagez, c'est selon vos conditions. Sur la mémoire hébergée, une clé n'a pas besoin d'être toute-puissante. Limitez-la aux projets choisis, en lecture seule ou en lecture-écriture — la forme idéale pour un prestataire, une tâche CI ou un agent à usage unique qui n'a rien à voir dans le reste de votre travail. Votre brain, vos règles, vos clés.

Équipes humaines. Un prestataire reçoit une clé qui lui permet d’accéder uniquement au projet du client et à rien d’autre. Lorsque la mission prend fin, on révoque une clé — sans avoir à défaire la mémoire partagée.

Flottes d’agents. Un job CI, un bot de recherche, un agent à usage unique — chacun reçoit exactement la mémoire dont son travail a besoin. Un agent qui ne fait que lire ne peut jamais supprimer quoi que ce soit.

Plusieurs harnais, une mémoire. Exécutez Claude Code, OpenClaw et Codex sur le même Brain — mais attribuez à chacun une clé adaptée au degré de confiance que vous lui accordez. L’agent autonome toujours actif qui communique avec le monde extérieur n’a que des droits en lecture sur un projet ; votre outil principal a accès à tout. Mémoire partagée sans rayon d’explosion partagé — le problème auquel se heurte toute configuration à plusieurs agents, résolu là où il se situe.

Supprimer est délibéré

La suppression est intentionnelle. Tout ce que vous stockez peut être supprimé par vous-même : un projet, une phrase précise ou même le compte entier, depuis le panneau, derrière votre propre identité. Supprimer un projet entraîne la perte de son historique ; supprimer le compte détruit complètement la mémoire chiffrée. Ce que les agents peuvent ou ne peuvent pas modifier est une question distincte, à laquelle une réponse courte est donnée ci-dessous.

C’est entre le moment où l’on dit qu’on fera quelque chose et le moment où on le fait que le travail meurt silencieusement. Le Ledger comble cette lacune. Comme vos conversations sont archivées, il surveille les intentions et transforme chacune d’elles en une ligne prête pour vous.

Dites « vérifie le registre » et votre agent fait défiler les lignes une par une — vous répondez à chacune en un seul mot. Celles dont vous avez fini disparaissent ; les autres restent jusqu’à ce que vous vous en occupiez — ou jusqu’à ce qu’un travail ultérieur les montre terminées, abandonnées ou dépassées, et elles partent d’elles-mêmes. Aucun statut, aucun tableau obsolète ; la pile ne fait que rétrécir. Rien de ce que vous vouliez faire ne disparaît discrètement.

La mémoire d'un projet est privée à ce projet. Une procédure appartient à tout ce que vous faites. Écrivez un playbook en Markdown une fois, stockez-le pour tout votre compte, et n'importe quel agent dans n'importe quel projet, sur n'importe quelle machine, peut le récupérer et le suivre — le déploiement, le rapport hebdomadaire, l'exécution de la traduction, toujours de la même manière.

Vous écrivez le flux de travail une seule fois et jamais plus. Les playbooks ne sont jamais élagués. L'exemple détaillé est l'atlas : votre agent dessine la carte de tout votre système sous forme de playbooks, et une règle indique à chaque session qu'ils y sont. Playbooks et l'atlas →

Chaque projet est cloisonné. Ses propres enregistrements curés, ses propres règles, son propre graphe, ses propres notes, son propre plan, son propre registre. Les règles générales se situent au-dessus de tous et atteignent chaque projet ; les règles propres à un projet ne l’atteignent que lui. Les playbooks sont la seule étagère partagée sur tout le compte, car une procédure écrite une fois doit pouvoir s’exécuter partout.

Deux clients signifient deux projets et deux clés. Sur la mémoire hébergée, une clé limitée à un projet ne peut pas en voir un autre, ne peut pas en interroger un autre, et ne peut pas être informée qu'un autre existe. Les seuls éléments qui franchissent les frontières sont ceux que vous demandez : une recherche effectuée sans nommer de projet, et le proposeur lorsqu'il pense qu'une session a été classée au mauvais endroit.

Rien ne fuit, sauf si vous le demandez.

Les règles sont des instructions permanentes, chargées avec la plupart des messages. Le reste du briefing arrive au début de la session : ce que chaque projet est, où les dernières sessions se sont arrêtées, et un index de ce qui est connu — déjà devant votre agent avant qu'il ne réponde. Définissez des règles pour tout ce que vous faites, ou pour un seul projet, et elles façonnent la manière dont chaque agent travaille, partout. Enregistrer ou modifier une règle coûte un message ; en supprimer une est gratuit.

Les règles sont le programme du curateur.

Pendant que vous travaillez, la mémoire lit ce qui a été dit et conserve ce dont une session future aura besoin : les décisions enregistrées, les faits modifiés intégrés, les affirmations dépassées par la réalité supprimées. Vos règles sont le programme qui lui indique ce qui compte. Vous écrivez la loi une fois, et elle s'applique sans qu'on ait à la demander.

On ne le dépose jamais.

Pas de sauvegarde, pas de balise, pas de rituel « mémorise mon contexte ». La curation se fait pendant que vous travaillez, pas quand vous pensez à la demander. Vous ne classez jamais rien — et la mémoire fait son travail que quelqu'un pense ou non à l'interroger. Un stock que l'agent doit être prié de consulter ne vaut que par la volonté du modèle de le faire ; celui-ci fait le travail lui-même.

La seule chose qu’aucun modèle ne peut toucher

L'archive de la conversation brute est l'enregistrement original, et elle est hors de portée de tout agent. La menace vient de votre propre agent : une erreur, ou une instruction malveillante cachée dans quelque chose qu'il a été chargé de lire — et il ne peut toujours pas supprimer un seul message ni toucher votre historique récent. L'archive reste la vôtre.

← Comment ça marche Dites à votre agent de l’installer