Knowledge

Knowledge bases hold the reference material agents consult while they work — product handbooks, playbooks, style guides — as markdown wikis of folders and files shared across a workspace or an organization.

The problem they solve is repeated context. Without a shared base, the facts an agent needs — how pricing works, what the product is called, how the team qualifies a deal — get restated in every assignment and every conversation, and drift apart as they’re restated. A knowledge base states them once. Every agent in scope reads the same source, and updating one file updates what every future run knows.

A concrete example: a “Product handbook” base for a product team might start small.

Product handbook/
├── positioning.md
├── pricing-and-packaging.md
├── voice-and-style.md
├── glossary.md
└── customers/
    ├── segments.md
    └── case-studies.md

A file like voice-and-style.md is written for a reader who will act on it:

We write in plain sentences and short paragraphs. Prices are quoted annually unless labeled otherwise. Never promise ship dates in customer-facing copy — say “planned” and link the public roadmap. The product name is always written out in full.

Creating a base

On the Knowledge page, choose New base, name it (say, “Product handbook”), and describe what it’s for. Admins also choose who can edit: everyone in the workspace, or only admins. The Workspace and Organization tabs at the top switch between the two kinds of base — an organization base is visible to every workspace in the org.

Scope tends to follow the material. A sales playbook belongs at workspace scope, next to the team that runs it; brand voice and the product glossary belong at organization scope, so every workspace reads the same version (see Organizations and workspaces). The edit setting works the same way: a style guide that changes rarely can be admin-only, while a playbook the whole team improves is better off open to everyone. An admin can change it later from Share in the base’s header, where general access reads Can edit or Can view (admins can always edit) and individual people can be added with their own level.

Files and folders

Create files and folders directly in the base, or start from a README. Use a path like guides/onboarding.md to nest a new file inside a folder. Every file shows who last edited it, and its history keeps every revision: open the history from the editor to compare any version with the current one, and choose Restore this version when an edit needs undoing. The workspace-wide Search page matches text inside knowledge files along with everything else you can read.

Full revision history is what makes shared editing low-stakes. A teammate’s rewrite, an agent’s update, your own hasty correction — each is a revision you can compare against and roll back, so opening a base to more editors doesn’t put its contents at risk.

How agents use knowledge

Agents read knowledge bases the way teammates do: when a task touches something the base covers, the agent consults it. An agent can also add to and edit a base when its Contribute knowledge guardrail is on (see Guardrails), unless the base is admin-only. The content agent drafting an announcement reads voice-and-style.md; the sales agent answering a pricing question reads pricing-and-packaging.md. When packaging changes, you update one file and every run after that reflects it. A base maintained this way compounds: every correction you make teaches every future run.

Knowledge is one of three places know-how lives, and they divide cleanly:

Knowledge bases are shared reference material — curated by people, and by agents where editing is allowed — read by every agent in scope.
Memory is per-agent: what one agent saves across its own conversations. You don’t write it by hand; the agent learns it.
Skills are reusable workflows and expertise — how to do a job, packaged so agents apply it on their own.

If a fact should be true for every agent that touches the topic, put it in a knowledge base.

Patterns that work

Handbook — durable facts: positioning, pricing rules, terminology. The base agents check before writing anything customer-facing.
Playbook — how the team operates: qualification criteria, escalation paths, launch checklists. Leave it open for everyone to edit so the people who run the plays keep them honest.
Style guide — voice and formatting rules for everything agents write, kept at organization scope when they hold company-wide.
Agent-maintained reference — where editing is allowed, an agent keeps a base current as it works: an FAQ that grows as questions get answered, a glossary that keeps pace with the product. Revision history keeps every change reviewable.