--- title: "Jeux de contexte et épingles" description: "Curation de ce qu'un agent reçoit au start_session : épingles always-load, jeux de contexte réutilisables et mise en sourdine de la mémoire." --- # Jeux de contexte et épingles Lorsqu'un agent appelle `start_session`, il ne reçoit pas toute la base de connaissances, mais le contexte de départ que vous composez. La section **Agents → Context** est un constructeur de ce contexte de départ : c'est ici que vous décidez précisément ce que l'agent voit au démarrage — quelles notes se chargent systématiquement (épingles), quels regroupements réutilisables sont rattachés à une portée (jeux de contexte) et quelles catégories de mémoire sont mises en sourdine. Les épingles par tag et la mise en sourdine de la mémoire sont file-first : elles vivent dans le frontmatter des notes et survivent à un nouveau clonage du dépôt. Les jeux de contexte et les épingles inter-espaces, eux, sont stockés dans la base de métadonnées (une réserve assumée : ni un nouveau clonage sur un hôte vierge ni le mode `none` ne les conserveront). ## Épingles always-load Une épingle est une marque manuelle « toujours charger » (l'appartenance au tag `always-load`, et non un ordre). Les épingles fonctionnent selon deux axes : - **Personnel** — les notes de votre domaine personnel entrent dans `profile.alwaysLoad` et se chargent à **chaque** session. - **Projet** — les notes du sous-arbre d'un projet marqué entrent dans `project.alwaysLoad` et se chargent lorsque l'agent travaille **dans ce projet** (l'indication `project`). Une épingle est liée à l'emplacement de la note : une note du domaine personnel s'épingle dans le profil, une note d'un sous-arbre de projet s'épingle dans le regroupement du projet. Le constructeur montre exactement ce que l'agent chargera réellement — la curation sur le serveur et dans l'aperçu passe par le même code. ## Jeux de contexte — regroupements inter-espaces Le tag `always-load` lie une épingle à un seul espace. Les jeux de contexte lèvent cette limite : un jeu de contexte est une **collection nommée et réutilisable de références vers des notes**, que vous pouvez rattacher à une autre portée. Scénario typique : vous composez un jeu « Conventions frontend » à partir de notes de l'espace partagé `conventions`, puis vous le rattachez à des projets d'un autre espace. Chaque session de ces projets reçoit ces notes, et vous modifiez le jeu à un seul endroit — la mise à jour se propage partout. Il existe aussi une option plus légère : l'**épingle libre inter-espaces**, une note épinglée directement dans une portée depuis un autre espace, sans passer par un jeu. Le tag `always-load` reste réservé aux épingles au sein d'un même espace ; les jeux et les épingles libres servent au cas inter-espaces. Tous coexistent, et la déduplication se fait par note-id. > [!note] Propriété ≥ rattachement > Un jeu vit dans son espace d'origine, et en être membre donne la visibilité et le droit de le modifier. Un jeu personnel ne se rattache qu'à votre domaine personnel ; un jeu partagé (issu d'un espace partagé) se rattache à votre domaine personnel ou à n'importe quel projet. Rattacher un jeu personnel à un projet est impossible — il ne chargerait le contexte que pour vous. ## Ordre = priorité de chargement L'ordre des épingles et des jeux dans la liste est le vôtre (glisser-déposer), il n'est pas dérivé. Il fixe la priorité : ce qui est placé au-dessus se charge en premier et est rogné en dernier quand le budget de tokens est atteint. Les épingles et les jeux partagent une seule liste classée (vous pouvez placer un jeu au-dessus d'une épingle). L'ordre de chargement global est **épingles → jeux → mémoire** (le spécifique l'emporte sur le général), puis le surplus est rogné pour tenir dans le budget de la portée. ## Mise en sourdine de la mémoire (mute) La mémoire de l'agent se charge dans le contexte par défaut. Si une catégorie est bruyante, mettez-la en sourdine de façon ciblée (`mute`). La mise en sourdine retire cette mémoire de partout où elle parvient à l'agent d'elle-même, sans demande explicite : - le profil personnel, qui se charge dès `start_session` ; - l'assemblage du bloc de contexte `recall` ; - le dictionnaire des catégories dans `start_session(project).knownValues`. > [!important] Search voit la mémoire en sourdine, à dessein > `search` ne filtre **pas** la mémoire en sourdine : il indexe la mémoire précisément pour la déduplication « chercher avant d'écrire ». Sinon, l'agent ne trouverait pas une catégorie mise en sourdine et en recréerait un doublon. La mise en sourdine étouffe le contexte automatique ; ce n'est pas une suppression : la recherche explicite et l'audit voient toujours tout. L'opération inverse est `Unmute`, sur le même axe. ## Un budget de tokens unique Au-dessus des sections du constructeur se trouve une seule jauge de chargement, correspondant exactement au budget de la portée courante. Une réponse personnelle porte un seul budget (les épingles d'abord, puis la mémoire) ; une réponse de projet a le sien, où les épingles de projet viennent en premier et où l'arrière-plan personnel se loge dans ce qui reste. Ce qui est chargé est toujours inférieur ou égal au budget, et le rognage est visible élément par élément. La mémoire de projet ne se charge pas d'emblée : elle est récupérée à la demande ; si un fait précis du projet est toujours nécessaire, épinglez la note. ## Pour aller plus loin - [Audit de récupération](/docs/agents/audit/) — le jumeau du constructeur à l'exécution : ce que l'agent récupère réellement. - [Mémoire de l'agent](/docs/agents/memory/) — comment se construit la mémoire que vous mettez en sourdine. - [Règles de l'agent](/docs/agents/agent-files/) — l'autre moitié du travail : faire en sorte que `start_session` soit réellement appelé. - [Outils d'intention](/docs/agents/intent-tools/) — `start_session` et les autres outils.