> ## Documentation Index > Fetch the complete documentation index at: https://developers.zite.com/llms.txt > Use this file to discover all available pages before exploring further. # Context > Documents you write for the agent: data model notes, policies, specs, and brand guidelines, stored in context/ at the workspace root. `context/` is a directory at the root of a [workspace monorepo](/framework/project-structure) that holds documents you write for the agent. Data model notes, refund policies, brand guidelines, meeting decisions: the business knowledge behind the code, in a place the agent will read it, instead of something you re-explain in every chat. Context belongs to the workspace, so every app, workflow, and agent session in that workspace sees it. ## Layout ```text theme={"dark"} my-workspace/ ├── context/ │ ├── index.json # manifest: title, description, and source per file │ ├── data-model-notes.md │ ├── refund-policy.md │ └── brand-guidelines.md └── apps/ ``` Context files are Markdown, directly inside `context/`. Subdirectories are not part of the library. ## How the agent uses it Every turn, the agent gets an inventory of your context: each file's title, path, and one-line description, and nothing else. ```text theme={"dark"} Workspace context (docs the user added for you, in context/): - Refund policy (context/refund-policy.md) — Approval thresholds, the 60-day cutoff, and EU cancellation rights - Brand guidelines (context/brand-guidelines.md) — Required colors, fonts, and writing tone for anything customer-facing ``` From those lines it decides what is worth opening for the request in front of it, then reads those files with its normal file tools. Bodies are never inlined, so a large library costs almost nothing until a document is actually relevant. The agent is told to prefer what a context document says over its own assumptions, and to treat the library as yours: it will not edit, rename, or delete a document unless you ask. Agents connected through the [Zite MCP](/mcp/overview) get the same instruction in their framework guide. Because descriptions are the only thing the agent matches on, write them (or let Zite write them) as concrete nouns: product names, table names, screens, policies. "Company guidelines and standards" tells the agent nothing. ## The manifest `context/index.json` decorates the files with a title, description, and where each one came from: ```json theme={"dark"} { "version": 1, "files": [ { "path": "context/refund-policy.md", "title": "Refund policy", "description": "Approval thresholds, the 60-day cutoff, and EU cancellation rights", "source": "written" }, { "path": "context/brand-guidelines.md", "title": "Brand guidelines", "description": "Required colors, fonts, and writing tone for anything customer-facing", "source": "google-doc", "google": { "docId": "1AbC...", "url": "https://docs.google.com/document/d/1AbC...", "syncedAt": "2026-08-30T17:04:11.320Z" } } ] } ``` The files on disk are the source of truth, not the manifest. A `context/*.md` file with no entry still appears in the library, titled from its first `# H1` or from its filename. An entry whose file is gone is dropped. A malformed `index.json` degrades to an empty manifest rather than breaking anything, and the library rebuilds from the files themselves. That means an agent (or you, in the code editor) can add a context document by writing the Markdown file. Adding a matching entry to `index.json` is what gives it a real description in the inventory. | Field | Notes | | ------------- | --------------------------------------------------------------------- | | `path` | Repo-relative, always `context/.md`. The stable id for the file | | `title` | Up to 80 characters, one line | | `description` | Up to 140 characters, one line. This is what the agent matches on | | `source` | `written`, `upload`, or `google-doc` | | `google` | Drive linkage for a `google-doc` file: `docId`, `url`, `syncedAt` | ## Adding context Open your workspace and use the **Context** tab. There are three ways in: Type or paste anything the agent should know. Drop or browse for `.md`, `.markdown`, `.txt`, `.csv`, or `.json`. Pick a doc from Drive. Zite stores a snapshot you can refresh. Zite writes the title and one-line description for you when a document is added, and rewrites the description when you edit the body. Both are editable, and a title you supply is always kept verbatim. A Google Doc is a snapshot: Drive owns the content, so the document is read only in Zite and **Refresh from Google** re-pulls it. Written and uploaded documents are editable in place. Every add, edit, and delete is a commit in the workspace's version history, alongside the agent's own changes. PDF and Word files are not accepted. A binary in `context/` is invisible to the agent, so adding one would look like it worked while doing nothing. ## Limits | Limit | Value | | ------------------- | ----------------------------------------------------- | | Files per workspace | 50 | | Size per file | 600 KB | | Title | 80 characters | | Description | 140 characters | | Location | Markdown files directly inside `context/`, no nesting | ## What to put in it Good candidates are the things you would otherwise say out loud at the start of every chat: * **Data model notes.** How your entities relate, which fields are authoritative, what a status value means. * **Policies and rules.** Approval thresholds, cutoffs, regional exceptions, who can see what. * **Brand and voice.** Colors, fonts, and tone for anything customer-facing. * **Process and decisions.** How a team actually works, and what was already decided and why. * **Specs.** What a feature is supposed to do, before someone builds it. Context files are committed to the workspace repo and read by the agent, so they are not the place for credentials. Use [integrations and secrets](/concepts/integrations-secrets) for those.