Notebooks

Notebooks are durable, workspace-scoped knowledge surfaces — the place for the operational knowledge that doesn't belong to any single feature: runbooks, SOPs, environment gotchas, research logs, lessons your agents learn the hard way.

Where the knowledge base holds uploaded reference documents that ground AI generation, notebooks are living pages that humans and agents read and write during day-to-day work.

The model

• Every workspace has a default notebook; you can create more (plan limits below).
• A notebook contains pages — markdown documents, optionally organized into directories (paid plans).
• Humans create and delete notebooks in the web UI (Notebooks in the top bar). Agents can read and write pages but can never create or delete a notebook — the container is always under human control.
• Every page edit creates a version snapshot server-side.

Plan limits

	Free	Pro	Team	Enterprise
Notebooks per workspace	1	3	Unlimited	Unlimited
Pages per notebook	1	15	Unlimited	Unlimited
Characters per page	5,000	Unlimited	Unlimited	Unlimited
Directories	—	✓	✓	✓

Limits are enforced server-side regardless of which surface (UI, MCP) does the writing.

How agents use notebooks

Notebooks are designed to be read efficiently by agents — a page isn't just a blob of markdown. Via the MCP server:

1. Discover — list_notebooks, then read_notebook_toc for a notebook's directories and page titles (no content, cheap).
2. Search — search_notebook runs section-level semantic search and returns ranked hits, each with a recommendedView telling the agent the cheapest way to read that section.
3. Read — read_page supports structured views, from cheapest to most expensive: CONTEXT (orientation), OVERVIEW (outline), SECTIONS, PROCEDURE (ordered steps only), EVIDENCE, PATHS (decision trees), GRAPH, and MARKDOWN (full body, last resort).
4. Write — write_page / update_page for free-form markdown, or write_runbook_page for structured runbooks: the agent supplies typed fields (summary, prerequisites, steps, commands, validation, rollback) and the server assembles canonical markdown.

The structured views are what make notebooks agent-friendly: an agent following a runbook can fetch just the PROCEDURE steps instead of re-reading the whole page every turn.

What belongs in a notebook

• Runbooks — "how to deploy", "how to run the migration", "how to rotate this credential"
• Environment gotchas — the local-setup quirks that burn an hour each time someone forgets
• Research logs — findings worth keeping after the conversation that produced them is gone
• Agent lessons — corrections you've given an agent that should survive into future sessions

Feature-specific knowledge (decisions, issues, assumptions) belongs in the feature's workbook, not a notebook. Rule of thumb: if it's about one feature, workbook; if it's about how this team or environment works, notebook.