> ## Documentation Index > Fetch the complete documentation index at: https://cofounder.appeeky.com/llms.txt > Use this file to discover all available pages before exploring further. # Library (workspace documents) > A markdown workspace your Co-founder reads — business context, departmental notes, and research — with per-app scope, pinning, and revision history. The **Library** (`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: ``` business_context.md # always injected AGENTS.md # workspace rules growth/paywall-tests.md aso/keyword-strategy.md engineering/release-process.md finance/unit-economics.md research/ daily/2026-07-25.md topics/cli-growth.md sessions/ # agent-written run logs ``` Department folders: `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 | Folder | Gets it by default | | ---------------------- | ---------------------------------------------- | | `growth/` | Ads Agent | | `aso/`, `marketing/` | ASO Agent, Social Media Agent | | `product/`, `support/` | Product Intelligence Agent | | `engineering/` | Engineering Intelligence, Release Intelligence | | everything else | main Co-founder | 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: | Setting | Options | What it changes | | ------------------------------ | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Inject into every briefing** | on / off | Always-on instead of retrieved. Max **3** documents — a fourth would only shrink the other three inside one shared budget | | **Visibility** | `agents` · `private` · `public` | `private` is yours alone: excluded from retrieval, search, and every prompt. `public` is eligible for sanitized public surfaces | | **Read by** | Every app / one app | Scope. Company-wide by default; scoping it means only that app's briefings read it | | **Delete** | — | Removes the document and its revision history. What the agent already learned from it stays in the Vault | `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](./knowledge-patches) 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 own `growth/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: ``` 956 chars · ~239 tokens · revision 3 Always injected Saved ``` Every save writes a **revision** with an author (`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 | Path | What gets in | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Every briefing** | Pinned documents (`business_context.md` and up to two more), truncated at a heading boundary | | **Briefing retrieval** | Top \~4 documents by similarity against the run theme — your active goals plus the previous briefing | | **Chat** | Top matches against the question you just asked. Short follow-ups ("and pricing?") get recent turns folded into the query so a two-word question still retrieves usefully | | **Specialist briefs** | The specialist's department folder | `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: | Tool | What it does | | ----------------------- | ----------------------------------------------------------------------- | | `search_documents` | Semantic search, returns snippets | | `read_document` | Full body at a path | | `list_documents` | Tree listing | | `write_document` | Create or overwrite — **refuses** `business_context.md` and `AGENTS.md` | | `delete_document` | Remove a path | | `propose_context_patch` | Suggest a change to a protected document or a profile field | 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](../concepts/knowledge-base) — how the Library relates to profiles and the token budget * [Knowledge Patches](./knowledge-patches) — the agent's way of asking to change protected context * [Documents API](../api/documents) — REST surface * [Second Brain](./second-brain) — ingesting outside content into the Vault instead