--- title: "Conjuntos de contexto y pins" description: "Curar lo que un agente recibe en start_session: pins de carga permanente, conjuntos de contexto reutilizables entre espacios y silenciado de memoria." --- # Conjuntos de contexto y pins Cuando un agente llama a `start_session`, no recibe toda la base de conocimiento, sino el contexto inicial que tú curas. La sección **Agents → Context** es el constructor de ese contexto inicial. Aquí decides exactamente qué ve el agente al arrancar: qué notas se cargan siempre (los pins), qué paquetes reutilizables están adjuntos a un alcance (los conjuntos de contexto) y qué categorías de memoria están silenciadas. Los pins por etiqueta y el silenciado de memoria son file-first: viven en el frontmatter de las notas y sobreviven a un nuevo clonado del repositorio. Los conjuntos de contexto y los pins entre espacios se guardan en la base de datos de metadatos (una salvedad deliberada: ni un nuevo clonado en un host limpio ni el modo `none` los conservan). ## Pins de carga permanente Un pin es una marca manual de «cargar siempre» (pertenencia a la etiqueta `always-load`, no un orden). Los pins funcionan en dos ejes: - **Personal** — las notas de tu dominio personal van a `profile.alwaysLoad` y se cargan en **cada** sesión. - **Proyecto** — las notas del subárbol de un proyecto marcado van a `project.alwaysLoad` y se cargan cuando el agente trabaja **en ese proyecto** (la pista `project`). Un pin queda ligado al lugar donde vive la nota: una nota del dominio personal se fija en el perfil, y una del subárbol de un proyecto, en el paquete de ese proyecto. El constructor muestra exactamente lo que el agente cargará de verdad: la curación en el servidor y en la vista previa pasa por el mismo código. ## Conjuntos de contexto — paquetes entre espacios La etiqueta `always-load` vincula un pin a un único espacio. Los conjuntos de contexto quitan ese límite: un conjunto de contexto es una **colección de referencias a notas, con nombre y reutilizable**, que puedes adjuntar a otro alcance. Un escenario típico: armas un conjunto «Convenciones de frontend» con notas del espacio compartido `conventions` y lo adjuntas a proyectos de otro espacio. Cada sesión de esos proyectos recibe esas notas, y tú editas el conjunto en un único sitio: se actualiza en todas partes. También existe una opción más ligera, el **pin suelto entre espacios**: una sola nota fijada directamente en un alcance desde otro espacio, sin envoltorio de conjunto. La etiqueta `always-load` se reserva para los pins dentro del mismo espacio; los conjuntos y los pins sueltos sirven para cruzar espacios. Todos conviven, y la deduplicación se hace por id de nota. > [!note] Propiedad ≥ adjunción > Un conjunto vive en su espacio de origen, y la membresía allí concede visibilidad y permiso de edición. Un conjunto personal se adjunta solo a tu dominio personal; uno compartido (de un espacio compartido) se adjunta a tu dominio personal o a cualquier proyecto. Adjuntar un conjunto personal a un proyecto no es posible: cargaría contexto solo para ti. ## Orden = prioridad de carga El orden de los pins y los conjuntos en la lista lo pones tú (arrastrando y soltando), no se deriva de nada. Ese orden fija la prioridad: lo que está más arriba se carga primero y es lo último que se recorta cuando se alcanza el presupuesto de tokens. Pins y conjuntos comparten una única lista ordenada (puedes subir un conjunto por encima de un pin). El orden de carga global es **pins → conjuntos → memoria** (lo específico pesa más que lo general); después, el excedente se recorta hasta el presupuesto del alcance. ## Silenciado de memoria (mute) La memoria del agente se carga en el contexto por defecto. Si una categoría hace ruido, silénciala de forma selectiva (`mute`). El silenciado quita esa memoria de todos los puntos por los que llega al agente por sí sola, sin petición explícita: - el perfil personal, que se carga nada más ejecutarse `start_session`; - el ensamblado del paquete de `recall`; - el diccionario de categorías en `start_session(project).knownValues`. > [!important] La búsqueda ve la memoria silenciada a propósito > `search` **no** filtra la memoria silenciada: la indexa precisamente para la deduplicación de «buscar antes de escribir». De lo contrario, el agente no encontraría una categoría silenciada y recrearía un duplicado. El silenciado acalla el contexto automático, no borra nada: la búsqueda explícita y la auditoría siguen viéndolo todo. Lo inverso es `Unmute`, en el mismo eje. ## Un único presupuesto de tokens Por encima de las secciones del constructor hay un solo indicador de carga, que coincide exactamente con el presupuesto del alcance actual. Una respuesta personal lleva un presupuesto (primero los pins, luego la memoria); una de proyecto lleva el suyo, donde primero van los pins del proyecto y el contexto personal de fondo entra en lo que queda. Lo cargado siempre es ≤ el presupuesto, y el recorte se ve elemento por elemento. La memoria del proyecto no se carga de inmediato: se trae a petición; si un hecho concreto del proyecto hace falta siempre, fija la nota con un pin. ## Siguiente - [Auditoría de recuperación](/docs/agents/audit/) — el gemelo del constructor en tiempo de ejecución: lo que el agente extrae de verdad. - [Memoria del agente](/docs/agents/memory/) — cómo se construye la memoria que silencias. - [Reglas del agente](/docs/agents/agent-files/) — la otra mitad del trabajo: conseguir que `start_session` llegue a llamarse. - [Herramientas de intención](/docs/agents/intent-tools/) — `start_session` y el resto de las herramientas.