Skip to main content
context/ is a directory at the root of a workspace monorepo 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

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.
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 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:
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.

​
Adding context

Open your workspace and use the Context tab. There are three ways in:

Write text

Type or paste anything the agent should know.

Upload a file

Drop or browse for .md, .markdown, .txt, .csv, or .json.

Import a Google Doc

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

​
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 for those.