Co-founder → Library) is a markdown workspace shared between you and the agent. It’s where the knowledge that doesn’t fit a form field lives: positioning arguments, pricing rationale, a paywall experiment write-up, notes from a support conversation.
Two documents are seeded on first open so you edit a skeleton instead of facing a blank page:
business_context.md— pinned always-on. Read on every single briefing.AGENTS.md— workspace rules the agent follows when reading and writing here.
Structure
Paths are free-form, up to 6 segments deep. A first segment matching a known department gets routed to the specialist that owns it:general, engineering, design, marketing, growth, aso, product, sales, support, finance, legal, research. Anything else is just a folder — still searchable, still retrievable, only without automatic routing.
Department → specialist reader
A specialist sees its own folder without having to semantically match into it, the same way it gets its remit.
Per-document settings
Each row’s... menu in the sidebar carries four things:
business_context.md and AGENTS.md can’t be scoped to a single app — they are account-level by design — and the agent cannot edit either one. It has to propose a patch instead.
Scope, concretely
A document scoped to an app is invisible to every other app’s briefing. This is what stops a pricing note for App A from steering a recommendation for App B. If you’re not sure, leave it company-wide: retrieval will only surface it when it actually matches. Scope lives on the document, not in the path — so paths are unique across your whole workspace. Two apps can’t both owngrowth/notes.md; give per-app variants distinct names (growth/notes-appeeky.md).
Pinning and scope combine: a pinned, app-scoped document is always-on for that app’s briefings and invisible to the rest. That’s how you give one product its own standing context without touching business_context.md.
The editor
Markdown, autosaved, with shortcuts as you type (## for a heading, - for a list). Open documents stack as tabs, so you can keep business_context.md next to the note you’re comparing it against. A status bar along the bottom shows what the document costs the agent:
user or agent), so an agent-written note is always distinguishable from yours and nothing is lost silently.
If a pinned document exceeds the always-on budget, a banner says so. It isn’t an error — the agent reads down to the last heading that fits and is told which sections were dropped, so it can fetch the rest with read_document when it needs them.
How documents reach the agent
AGENTS.md is prepended whenever any Library document makes it into the prompt — rules with no documents to apply to would be dead tokens.
Retrieval is semantic (pgvector, text-embedding-3-small) with an ilike fallback, so it works across languages: a Turkish question can match an English document. Embedding is best-effort; a document is never blocked from saving because of an embedding outage.
Agent tools
In chat and in the reasoner’s research phase:
Over MCP the same operations are
workspace_search, workspace_list, workspace_read, workspace_write, and workspace_delete. There, writes to business_context.md and AGENTS.md are gated behind an explicit confirm_owner_document flag rather than blocked outright — over MCP the caller may well be you.
Good things to put in it
- The argument behind your positioning, not just the one-liner — the agent quotes reasoning better than slogans.
- Experiments you already ran and what happened, so it stops proposing them.
- Pricing constraints with the reason attached (“MX price stays low, it’s a growth market for us”).
- Support themes that never show up in review text.
- A competitor teardown you’d otherwise keep in Notion.
Related docs
- Company Knowledge Base — how the Library relates to profiles and the token budget
- Knowledge Patches — the agent’s way of asking to change protected context
- Documents API — REST surface
- Second Brain — ingesting outside content into the Vault instead