Skip to content

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.

On the Knowledge page, choose New Base, name it (say, “Product handbook”), and describe what it’s for. Admins can also set who may edit: Any member or Admins only. The scope pills at the top switch between Workspace and Organization bases — 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 Admins only, while a playbook the whole team improves is better off as Any member.

Create files and folders directly in the base; files start empty and are written in the editor. Every file shows who last edited it, and the history panel keeps every revision — open View history to compare versions and Restore this version when an edit needs undoing.

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.

Agents read knowledge bases the way teammates do: when a task touches something the base covers, the agent consults it — and, where editing is allowed, keeps it current. 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.

  • 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. Pair it with Any member editing 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.

For the complete site index, see llms.txt.