Agent rules

Connecting the MCP endpoint is half the job. The other half is getting the agent to start from the knowledge base on its own, rather than after your "go check Notarium first." This page is about wiring that in once.

Why connecting isn't enough

Which tool to call is the model's decision. On its side of the wire Notarium does everything it can: at initialization it hands over instructions ("call start_session first"), and the tool's own description says outright that it's idempotent and safe to call again. That moves the odds a long way, but it's not a guarantee — and by the design of the protocol it can't be.

The guarantee lives on your side, in the agent's standing instructions. The practical effect is simple: either the agent opens a session with the project's context, or you remind it by hand every time and the interaction stops feeling native.

Where to put it

Almost every agent client has a standing-instructions file that gets mixed into every session:

The format and the exact paths are set by the client and change independently of us — check its documentation. Notarium asks nothing of the file: it's plain text that your agent reads.

The minimal block

Three rules cover the main scenario — start from context, don't spawn duplicates, put knowledge where it belongs:

## Notarium — the project knowledge base

- At the start of a new session, call `start_session(project: "acme/website")`
  on the `notarium` MCP server — profile, available projects, the index of
  this project, the delta of changes since your last visit, and the
  dictionary of categories.
- **Search before you write:** `search("<topic>", project: "acme/website")` —
  search covers your own memory too, so duplicates get caught.
- Record durable facts about the project with `remember_about_project`,
  about the owner with `remember_about_user`, shared visible knowledge
  with `create_note`.

Substitute your own project handle. It usually looks like space/project, but for the root project of a space it collapses to a single segment — just space. Don't derive it from a rule: get_my_projects returns the ready-made list, so take it from there verbatim. In a rules file it's better to hard-code the exact value, so the agent doesn't go looking for it every time.

The extended block: a map of the canon

If a project has notes that should be read for a particular role or task, don't make the agent hunt for them again every session — give it a map. Loading a few specific notes is cheaper than "read the whole project":

## Notarium

- First call — `start_session(project: "acme/website")`.
- After that load specific notes rather than reading the whole project:
  - development conventions — `get_note("<id>")`;
  - the review checklist — `get_note("<id>")`;
  - context around a topic — `recall("<topic>", project: "acme/website")`.
- Before any write — `search("<topic>", project: "acme/website")`.
- Keep the work log and the decisions on a task in Notarium,
  not in repository files.

Note ids are stable: they survive a rename and a move, so the map doesn't rot when you reorganize the base. A [[by title]] link won't break on a rename either — the old title goes into alias history.

Two layers of rules

Split instructions by lifetime — that way you don't have to duplicate them in every repository:

• The global layer (a shared rules file or the system prompt) — what's always true: call start_session first, search before writing, where facts about the owner go. No project handle here.
• The project layer (a file in the repository) — the handle of this specific project, the map of the canon, local agreements.

Then hooking a new repository up to the knowledge base is a few lines with a single handle, while the shared rules live in one place.

What doesn't belong in the rules

Two more things that shouldn't end up there:

• Tokens. A rules file usually lives in git. A personal token belongs in your MCP client's configuration, not in an instruction.
• A retelling of the tool reference. The agent already sees the names and descriptions in tools/list; they're static and always current. A copy in the rules file drifts from reality fast — write down intent and agreements, not a duplicate of the documentation.

How this fits with context curation

Two halves of one job, and neither replaces the other:

• The rules file makes sure the start_session call happens.
• The Agents → Context section decides what that call brings back: always-load pins, context sets, and muting for noisy memory categories — all under a shared token budget.

So if the agent starts with context but not the right one, the fix isn't in the rules file — it's in context sets and pins.

Next

• Connecting an agent — token, OAuth connector, transport.
• Context sets and pins — what goes into start_session.
• Intent tools — the full set and the order of calls.
• Agent memory — how remember_* differs from create_note.