--- title: "Kontext-Sets und Pins" description: "Kuratieren, was ein Agent bei start_session bekommt: always-load-Pins, wiederverwendbare Kontext-Sets und das Stummschalten des Gedächtnisses." --- # Kontext-Sets und Pins Wenn ein Agent `start_session` aufruft, bekommt er nicht die ganze Wissensbasis, sondern den von dir kuratierten Startkontext. Der Bereich **Agents → Context** ist der Kontext-Builder dafür: Hier legst du genau fest, was der Agent zu Beginn sieht — welche Notizen immer geladen werden (Pins), welche wiederverwendbaren Bündel an einen Scope angehängt sind (Kontext-Sets) und welche Gedächtniskategorien stummgeschaltet sind. Tag-Pins und die Stummschaltung des Gedächtnisses sind file-first: Sie leben im Frontmatter der Notizen und überstehen ein erneutes Klonen des Repositorys. Kontext-Sets und Space-übergreifende Pins liegen in der Metadaten-Datenbank (ein bewusst in Kauf genommener Vorbehalt: Weder ein erneutes Klonen auf einen sauberen Host noch der Modus `none` bewahren sie). ## Always-load-Pins Ein Pin ist eine manuelle „Immer laden“-Markierung (Mitgliedschaft im Tag `always-load`, keine Reihenfolge). Pins wirken entlang zweier Achsen: - **Persönlich** — Notizen in deiner persönlichen Domäne landen in `profile.alwaysLoad` und werden bei **jeder** Session geladen. - **Projekt** — Notizen im Teilbaum eines markierten Projekts landen in `project.alwaysLoad` und werden geladen, wenn der Agent **in diesem Projekt** arbeitet (der `project`-Hinweis). Ein Pin ist daran gebunden, wo die Notiz liegt: Eine Notiz in der persönlichen Domäne wird ins Profil gepinnt, eine Notiz im Teilbaum eines Projekts ins Projektbündel. Der Builder zeigt genau das, was der Agent tatsächlich laden wird — die Kuratierung auf dem Server und in der Vorschau läuft über denselben Code. ## Kontext-Sets — Space-übergreifende Bündel Der Tag `always-load` bindet einen Pin an einen einzelnen Space. Kontext-Sets heben diese Grenze auf: Ein Kontext-Set ist eine **benannte, wiederverwendbare Sammlung von Notiz-Referenzen**, die du an einen anderen Scope anhängen kannst. Ein typisches Szenario: Du stellst aus Notizen im geteilten Space `conventions` ein Set „Frontend-Konventionen“ zusammen und hängen es an Projekte in einem anderen Space an. Jede Session dieser Projekte bekommt diese Notizen, und du pflegst das Set an einer einzigen Stelle — die Änderung wirkt überall. Es gibt auch eine leichtere Variante — den **Space-übergreifenden losen Pin**: eine einzelne Notiz, direkt aus einem anderen Space in einen Scope gepinnt, ohne Set als Hülle. Der Tag `always-load` bleibt für Pins innerhalb desselben Space; Sets und lose Pins sind für den Space-übergreifenden Fall da. Alles koexistiert, dedupliziert wird über die Notiz-ID. > [!note] Besitz ≥ Anhängen > Ein Set lebt in seinem Heimat-Space, und die Mitgliedschaft dort gewährt Sichtbarkeit und Bearbeitungsrecht. Ein persönliches Set lässt sich nur an deine persönliche Domäne anhängen; ein geteiltes Set (aus einem geteilten Space) an deine persönliche Domäne oder an ein beliebiges Projekt. Ein persönliches Set an ein Projekt zu hängen, geht nicht — es würde den Kontext nur für dich laden. ## Reihenfolge = Ladepriorität Die Reihenfolge von Pins und Sets in der Liste bestimmst du selbst (Drag-and-drop), sie ist nicht abgeleitet. Sie legt die Priorität fest: Was weiter oben steht, wird zuerst geladen und als Letztes gekürzt, wenn du an das Token-Budget stößt. Pins und Sets teilen sich eine gemeinsame Rangliste (du kannst ein Set über einen Pin ziehen). Die gesamte Ladereihenfolge lautet **Pins → Sets → Gedächtnis** (Spezifisches wiegt schwerer als Allgemeines), danach wird der Überschuss auf das Budget des Scopes gekürzt. ## Gedächtnis stummschalten (mute) Das Agentengedächtnis wird standardmäßig in den Kontext geladen. Erzeugt eine Kategorie nur Rauschen, schalte sie gezielt stumm (`mute`). Die Stummschaltung entfernt dieses Gedächtnis aus allen Kanälen, über die es den Agenten von selbst erreicht, ohne ausdrückliche Anfrage: - aus dem persönlichen Profil, das direkt bei `start_session` geladen wird; - aus dem Zusammenbau des `recall`-Bündels; - aus dem Kategorien-Wörterbuch in `start_session(project).knownValues`. > [!important] Search sieht stummgeschaltetes Gedächtnis mit Absicht > `search` filtert stummgeschaltetes Gedächtnis **nicht** heraus: Es indexiert das Gedächtnis gerade für die Deduplizierung nach dem Prinzip „vor dem Schreiben suchen“. Sonst fände der Agent eine stummgeschaltete Kategorie nicht und würde ein Duplikat neu anlegen. Die Stummschaltung bringt den Auto-Kontext zum Schweigen, sie löscht nichts: Explizite Suche und Audit sehen weiterhin alles. Die Umkehrung ist `Unmute` auf derselben Achse. ## Ein einziges Token-Budget Über den Abschnitten des Builders sitzt eine einzige Ladeanzeige, die exakt dem Budget des aktuellen Scopes entspricht. Eine persönliche Antwort hat ein Budget (zuerst Pins, dann Gedächtnis); eine Projektantwort hat ihr eigenes Budget, in dem zuerst die Projekt-Pins kommen und der persönliche Hintergrund in den Rest passt. Das Geladene bleibt immer ≤ dem Budget, und das Kürzen ist Element für Element sichtbar. Das Projektgedächtnis wird nicht sofort geladen, sondern auf Anfrage nachgezogen; wird ein bestimmter Projektfakt immer gebraucht, pinn die Notiz. ## Weiter - [Retrieval-Audit](/docs/agents/audit/) — der Zwilling des Builders zur Laufzeit: was der Agent tatsächlich abruft. - [Agentengedächtnis](/docs/agents/memory/) — wie das Gedächtnis aufgebaut ist, das du stummschaltest. - [Agenten-Regeln](/docs/agents/agent-files/) — die andere Hälfte der Aufgabe: dafür sorgen, dass `start_session` überhaupt aufgerufen wird. - [Intent-Tools](/docs/agents/intent-tools/) — `start_session` und die übrigen Tools.