Back to Help Center

Knowledge

Knowledge is the shared pool of internal context AI workers use to answer and decide. The biggest gotchas, in order: (1) it is shared at the team level — you cannot give one worker its own private knowledge, (2) putting something in Knowledge does not make workers read it (skills do that), and (3) database nodes are typed tables with row-level access.

Overview

Why knowledge is a team-wide pool, the five node types, the database node, and how workers reach knowledge through the knowledge-manager skill.

Basics

Team-wide shared pool (no per-worker access scoping)

The Knowledge tree is a single pool shared across the team. You cannot create knowledge that only one worker can see. Express scoping through folder structure and naming.

Example (above): top folders for Customer Success Knowledge, Sales Knowledge, Legal Knowledge, Product Manuals, with each folder holding only what that function needs. If you want "Sales worker should not read Legal Knowledge," implement that through the worker's instruction prompt and skill permissions — not through knowledge access controls.

Five node types and their icons

The Knowledge tree supports five node types. Spot them by the icon shape inside a folder.

  • Folder: a container for other nodes
  • Text page: Markdown editor for manuals, FAQs, and templates (file icon)
  • Database: tabular data with fields and rows (database icon)
  • JSON: structured document
  • File: uploaded PDF / image / spreadsheet

The screenshot above (inside the Customer Success Knowledge folder) shows FAQ Master (database) and SLA Cheatsheet (by plan) (page) side by side. Inside a text page, typing / lets you insert image or file blocks, so it works for mixed text-and-image runbooks too.

Database nodes (typed columns and row-level lookup)

Use a database when you want row-level inserts and lookups — customer lists, product masters, inquiry histories, FAQ catalogs. At creation time you define column names and types (text / number / date). After creation, add rows and edit cells in place.

Details worth knowing:

  • created_at and created_by are auto-added, so the column count in the header includes two more than what you defined
  • Only the Grid view is available today (the saved-state model leaves room for more views later)
  • Bulk import is currently manual — add row, click cell, type
  • Workers reach individual rows through the knowledge-manager skill

Access via the knowledge-manager skill

Putting content into Knowledge does not by itself make workers read it. On the worker's Skills tab, enable knowledge-manager (or another knowledge-aware built-in skill) — that is what lets the worker reach into the tree on demand.

If a worker "never seems to look at our knowledge," check first whether this skill is on, then whether the worker's instructions tell it when to consult knowledge. That fixes the issue more often than upgrading the model.

Checklist

  1. Have you split the tree into top-level folders by function (Sales / CS / Legal / Product) with only the right node types underneath each?

  2. For database nodes, did you define columns and types first, then add rows, and confirm knowledge-manager can search them?

  3. On every worker that needs knowledge, is knowledge-manager (or the relevant knowledge skill) enabled on the Skills tab?