Knowledge Bases
A knowledge base (KB) is a private collection of documents that an AI Employee's agents can search at run time. When an agent needs grounding — answering from your policies, your product docs, your help center — it retrieves the most relevant passages from its attached knowledge bases and reasons over them. This is retrieval-augmented generation (RAG): the model's answer is grounded in your content, and it can cite the exact sources it used.
A knowledge base belongs to exactly one AI Employee. It is scoped by ai_employee_id, so a KB's content is only ever searched by the AI Employee that owns it.
How a knowledge base works
Documents flow through an ingestion pipeline, then become searchable:
- Connect or upload. A KB draws its documents from a connector (SharePoint, Google Drive, Confluence, Box, ServiceNow) or from direct file uploads.
- Extract. The pipeline extracts text from each document, including PDFs and Office files (.docx, .xlsx, .pptx).
- Chunk. The text is split into overlapping chunks — by default about 1024 tokens per chunk with 128 tokens of overlap — so each chunk is small enough to embed and large enough to carry meaning. Overlap keeps context from being cut at chunk boundaries.
- Embed. Each chunk is turned into a vector embedding by EmaFusion™. The embedding model is a platform-level setting shared by all tenants.
- Store. Chunks and their embeddings are stored in a vector index, with the document's folder path kept alongside for filtering.
Once a document finishes ingesting, its chunks are immediately searchable.
Connections and KBs are managed by administrators. Source connections (the credentials for SharePoint, Drive, and so on) and knowledge bases are created by administrators. As a builder, you select from the knowledge bases available to your AI Employee and scope them with a folder filter — you never handle credentials.
Retrieval at run time (RAG)
When an agent with attached knowledge bases runs, the platform performs a vector search:
- The agent's query is embedded with the same model used for the documents.
- The platform runs an approximate-nearest-neighbor search (an HNSW index) over the KB's chunks using cosine similarity (similarity =
1 − distance). - Chunks scoring below the agent's
min_scorefloor (default 0.15) are dropped, and the toptop_kmatches that remain are ranked by similarity and injected into the agent's context with numbered source labels so the model can cite them.
Retrieval is tunable per agent through its type_config. Values outside the valid range are ignored and fall back to the default:
| Parameter | Default | Range | Notes |
|---|---|---|---|
top_k (chunks returned) | 20 | 1–50 | How many chunks the agent retrieves. Out-of-range values fall back to the default. |
min_score (similarity floor) | 0.15 | 0.05–0.95 | Chunks below this cosine-similarity score are dropped. |
| Knowledge bases per agent | — | — | An agent can search several KBs in one query. |
The Search & Respond agent type is built around this loop and cites its sources automatically. See Agents.
Folders and the folder filter
Documents carry a folder path from their source. You can scope an agent's retrieval to a subset of a knowledge base with a folder filter — a path prefix the search must match.
The folder filter is applied at search time, not at ingestion time. That has two practical consequences:
- Adding or changing a folder filter on an agent node takes effect on the next run, with no re-ingestion.
- One knowledge base can serve several agents, each scoped to a different folder.
For example, a single "Company Docs" KB might back an HR agent filtered to policies/hr/ and a finance agent filtered to policies/finance/, with no duplicate ingestion.
Search and extraction knowledge bases
A knowledge base has an intent that determines how its content is prepared:
- Search (the default) — content is chunked, embedded, and indexed for vector retrieval. This is what RAG agents query.
- Extraction — the full extracted text is stored as a single LLM-ready document, with no chunking or embedding. Use this when an agent needs the whole document (for example, an Extraction agent reading an uploaded file) rather than retrieved passages.
How a knowledge base stays current
- Connector sync keeps a KB aligned with its source. Sync runs on a schedule (or on demand) and uses incremental change detection so unchanged documents aren't re-processed.
- Document triggers can run a workflow when a document finishes ingesting in an attached KB — useful for pipelines that act on newly added content. The run executes against the AI Employee's live published version.
- Version snapshots capture which documents a workflow version searched, so reverting a published version reconciles the KB back to that state. See Workflows.
Where to go next
- Agents — how the Search & Respond agent uses knowledge bases.
- Integrations and data — connecting sources and managing knowledge bases.
- EmaFusion™ — the model layer that embeds documents and queries.