Reglas del agente

Conectar el endpoint MCP es la mitad del trabajo. La otra mitad es conseguir que el agente arranque por su cuenta desde la base de conocimiento, y no después de tu «primero pásate por Notarium». Esta página va de cómo dejar eso fijado una sola vez.

Por qué no basta con conectarlo

Qué herramienta llamar lo decide el modelo. Del lado del servidor, Notarium hace todo lo que está en su mano: al inicializar entrega instructions («llama primero a start_session»), y la descripción de la propia herramienta dice sin rodeos que es idempotente y que volver a llamarla es seguro. Eso sube bastante las probabilidades, pero no es una garantía, y por cómo está diseñado el protocolo no puede serlo.

La garantía vive de tu lado: en la instrucción permanente del agente. El efecto práctico es simple: o el agente abre la sesión con el contexto del proyecto, o se lo recuerdas a mano cada vez y la interacción deja de sentirse nativa.

Saltarse la llamada no rompe nada

Omitir start_session no rompe el trabajo: las demás herramientas se bastan solas, y los límites de acceso los sostiene el token, no la disciplina del agente. La única diferencia está en el contexto: el agente no verá tu perfil, ni el delta de cambios, ni el diccionario de categorías acordadas, así que es más probable que cree un duplicado o que nombre las cosas a su manera.

Dónde escribirlo

Casi todos los clientes de agente tienen un archivo de instrucciones permanentes que se mezcla en cada sesión:

Cliente	Dónde suele estar
Claude Code	`CLAUDE.md` en la raíz del repositorio (más uno global en tu directorio personal)
Codex	`AGENTS.md` en la raíz del repositorio
Cursor	reglas del proyecto en `.cursor/rules`
Tu propio agente o una integración por API	el prompt de sistema

El formato y las rutas exactas los define el cliente y los cambia al margen de nosotros: consulta su documentación. Notarium no exige nada del archivo: es texto plano que lee tu agente.

El bloque mínimo

Tres reglas cubren el escenario principal — arrancar con contexto, no generar duplicados y poner el conocimiento donde corresponde:

## Notarium — la base de conocimiento del proyecto

- Al inicio de una sesión nueva, llama a `start_session(project: "acme/website")`
  en el servidor MCP `notarium`: perfil, proyectos disponibles, índice de este
  proyecto, delta de cambios desde tu última visita y diccionario de categorías.
- **Busca antes de escribir:** `search("<tema>", project: "acme/website")` —
  la búsqueda cubre también tu propia memoria, así que los duplicados se detectan.
- Los hechos duraderos sobre el proyecto, escríbelos con `remember_about_project`;
  los del propietario, con `remember_about_user`; el conocimiento compartido y
  visible, con `create_note`.

Sustituye el handle por el de tu proyecto. Normalmente tiene la forma space/project, pero en el proyecto raíz de un espacio se reduce a un solo segmento: solo space. No lo deduzcas por una regla: get_my_projects devuelve la lista ya hecha, y de ahí conviene tomarlo tal cual. En un archivo de reglas es mejor fijar el valor exacto, para que el agente no tenga que buscarlo cada vez.

Una llamada en lugar de cinco

start_session está hecho justo para esto: en una sola petición entrega lo que de otro modo costaría varias llamadas exploratorias y contexto de más. Es idempotente: volver a llamarlo tras una compactación de contexto es seguro y no tiene efectos secundarios. Lo único que no se repite es el delta de cambios: por defecto, la primera llamada mueve el marcador de «última visita», así que la segunda lo devuelve vacío. Para echarle un vistazo al delta sin mover el marcador, llámalo con acknowledge: false.

El bloque ampliado: un mapa del canon

Si un proyecto tiene notas que conviene leer para un rol o una tarea concretos, no obligues al agente a buscarlas de nuevo cada sesión: dale un mapa. Cargar unas pocas notas concretas sale más barato que «lee el proyecto entero»:

## Notarium

- Primera llamada: `start_session(project: "acme/website")`.
- Después carga notas concretas en vez de leer el proyecto entero:
  - convenciones de desarrollo — `get_note("<id>")`;
  - checklist de revisión — `get_note("<id>")`;
  - contexto alrededor de un tema — `recall("<tema>", project: "acme/website")`.
- Antes de cualquier escritura — `search("<tema>", project: "acme/website")`.
- Lleva el registro de trabajo y las decisiones de una tarea en Notarium,
  no en archivos del repositorio.

Los identificadores de nota son estables: sobreviven a un renombrado y a un traslado, así que el mapa no se pudre cuando reorganizas la base. Un enlace [[por título]] tampoco se rompe al renombrar: el título antiguo pasa al historial de alias.

Dos capas de reglas

Separa las instrucciones por tiempo de vida — así no tienes que duplicarlas en cada repositorio:

La capa global (un archivo de reglas compartido o el prompt de sistema) — lo que siempre es cierto: llamar primero a start_session, buscar antes de escribir, dónde van los hechos sobre el propietario. Aquí no hay handle de proyecto.
La capa de proyecto (un archivo en el repositorio) — el handle de ese proyecto concreto, el mapa del canon, los acuerdos locales.

Así, enganchar un repositorio nuevo a la base de conocimiento son unas pocas líneas con un único handle, mientras que las reglas comunes viven en un solo sitio.

Qué no debe ir en las reglas

Las reglas del agente no son un mecanismo de seguridad

Un archivo de reglas es una pista, no una frontera. Lo que un agente puede hacer lo determinan los permisos del token y el conjunto de herramientas: un token read no ve físicamente las herramientas de escritura, y el espacio de otra persona es inalcanzable por diseño. No intentes acotar al agente con texto donde hace falta el alcance del token: consulta Seguridad y visibilidad.

Otras dos cosas que tampoco deberían acabar ahí:

Los tokens. Un archivo de reglas suele vivir en git. Un token personal se define en la configuración de tu cliente MCP, no en una instrucción.
Una paráfrasis de la referencia de herramientas. Los nombres y las descripciones el agente ya los ve en tools/list; son estáticos y siempre están al día. Una copia en el archivo de reglas se aleja de la realidad enseguida: escribe intenciones y acuerdos, no un duplicado de la documentación.

Cómo encaja esto con la curación del contexto

Dos mitades de una misma tarea, y ninguna sustituye a la otra:

El archivo de reglas se encarga de que la llamada a start_session ocurra.
La sección Agents → Context decide qué trae exactamente esa llamada: pins de carga permanente, conjuntos de contexto y silenciado de las categorías de memoria ruidosas, todo bajo un presupuesto de tokens común.

Por eso, si el agente arranca con contexto pero no con el que toca, lo que hay que tocar no es el archivo de reglas, sino los conjuntos de contexto y pins.

Conectar un agente — token, conector OAuth, transporte.
Conjuntos de contexto y pins — qué entra en start_session.
Herramientas de intención — el conjunto completo y el orden de las llamadas.
Memoria del agente — en qué se diferencia remember_* de create_note.