> For the complete documentation index, see [llms.txt](https://notara.gitbook.io/notara-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notara.gitbook.io/notara-docs/libraries/load-policies.md).

# Load Policies

Load policies control when and how documents appear in the agent's context. Choosing the right policy for each document is the key to building a library that makes the agent smart without making it slow.

## The Three Policies

### `spine` — Always Injected

Spine documents are inserted into every single agent turn, before any user message is processed. They form the "always-on" foundation of the agent's knowledge.

Think of spine documents as the things you'd want every team member to know before touching any problem — the company overview, the product description, the "here's how we work" document.

**How it works:**

1. All spine documents are collected for the active libraries.
2. They are injected in priority order until the context budget is exhausted.
3. Any spine documents that don't fit within the budget are listed in the manifest by name (the agent knows they exist but can't read them).
4. The agent always sees the manifest first, so it knows what's available even if not everything is injected.

**When to use `spine`:**

* Documents that are always relevant, regardless of what the user is asking
* Short documents (< 2,000 words) that the agent needs frequently
* Reference material that answers common questions (e.g., "who is our CTO?", "what does our product do?")

**When NOT to use `spine`:**

* Large documents (API reference, long runbooks) — they'll consume the entire context budget
* Documents that are only relevant for specific queries (use `on_demand` instead)
* Sensitive documents you want to restrict (use `never`)

**Budget guidance:** Keep total spine content under \~20,000 tokens across all documents. With Claude 3.5 Sonnet's 200,000 token context window, this leaves plenty of room for conversation history, tool results, and dynamically retrieved documents. A typical spine library is 3–8 short documents.

### `on_demand` — Retrieved via Semantic Search

On-demand documents live in a vector index. When the agent processes a request, it runs a semantic similarity search over all `on_demand` documents in the active libraries and retrieves the most relevant ones.

This allows you to build large libraries — hundreds of documents — without overwhelming the context window. The agent reads the manifest, sees that many documents exist, and fetches only the ones relevant to the current query.

**How it works:**

1. The manifest tells the agent which `on_demand` documents exist (titles and descriptions).
2. The agent performs a semantic search for documents matching the current query.
3. The top matching documents are retrieved and added to the context.
4. The agent can also explicitly request a document by name if the manifest entry makes it obvious which one is needed.

**When to use `on_demand`:**

* Any library with more than \~8 documents
* API reference documentation
* Runbooks (each covering a specific scenario)
* Meeting notes archives
* Research documents on specific topics

**Writing good descriptions:** the agent uses the manifest entry — title and description — to decide which documents to fetch. Write clear, specific titles and descriptions. Instead of "Notes from 2026-03", write "Q1 2026 Architecture Review — decision to migrate from Mongo to Postgres, rationale and migration plan".

### `never` — Private

Documents set to `never` are completely invisible to the agent. They are:

* Not injected as spine
* Not indexed for semantic search
* Not listed in the manifest
* Not accessible via MCP resources
* Not readable by any external agent

They exist only for human team members to read via the dashboard.

**When to use `never`:**

* Sensitive employee information
* Financial projections or board materials
* Notes about a situation you're managing internally
* Draft documents that aren't ready for the agent
* Historical records that are no longer current and would confuse the agent if retrieved

## Choosing the Right Policy

Use this decision tree:

```
Is this document always relevant, regardless of the query?
  YES → Is it under ~2,000 words?
          YES → spine
          NO  → on_demand (large spine docs hurt more than help)
  NO  → Should the agent ever be able to read this?
          YES → on_demand
          NO  → never
```

## Changing a Policy

You can change a document's load policy at any time:

1. Open the document in the library.
2. Click the **Load Policy** badge at the top.
3. Select the new policy.
4. Click **Save**.

The manifest is regenerated automatically. The change takes effect on the next agent turn.

## The Context Budget in Practice

Here's a concrete example with a 200,000 token context window (Claude 3.5 Sonnet):

| Budget Allocation                    | Size             |
| ------------------------------------ | ---------------- |
| System prompt                        | \~2,000 tokens   |
| Spine documents (target)             | \~15,000 tokens  |
| Conversation history (last 20 turns) | \~10,000 tokens  |
| On-demand retrieved documents        | \~5,000 tokens   |
| Tool results                         | \~5,000 tokens   |
| Agent response                       | \~3,000 tokens   |
| **Available headroom**               | \~160,000 tokens |

This is deliberately conservative. The headroom exists for long tool chains, large API responses, and detailed reasoning. If you're hitting context limits, reduce spine document size first — they're the biggest lever.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://notara.gitbook.io/notara-docs/libraries/load-policies.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.