Your agent searches your documents before it answers.
Add a web page, a PDF, or text you paste. Saaya splits it, embeds it, and stores it in a collection of its own. Your agent searches that collection during the conversation, and passages below the relevance floor you set never reach the model.
Retrieval narrows what the model can say. It does not verify what it said.
Without a knowledge base, a language model answers your customers out of its training data, fluently and often wrong about your product. A Saaya Knowledge Base gives the agent somewhere better to look: your own sources, searched during the conversation, with the retrieved text handed to the model as the material to answer from.
A source is a web page Saaya fetches, a PDF it can reach by URL, or text you paste in. Each one is split into overlapping chunks of roughly a thousand characters, embedded, and stored in a collection of its own, one per knowledge base. Re-indexing is on demand: change a document, hit sync, and the old vectors are replaced only once the new ones land.
The one real guard is the relevance floor. Every knowledge base carries a minimum similarity score, 0.35 by default and set per knowledge base where you attach it to an agent, and the search engine drops anything below it before the model sees a word of it. When nothing clears the floor the agent is told the knowledge base had nothing and is instructed to say so rather than answer from memory. That is a genuine constraint on the input. It is not a check on the output: nothing inspects the sentence the model produces, so a wrong answer is still possible and transcripts still deserve review.
What the retrieval layer does, and where it stops.
Every number below is a real default in the running system, not a target.
Sources you can actually add
A web page URL that Saaya fetches, a PDF it can reach by URL, or text you paste in. One page per source, because there is no crawler: a documentation site is a list of URLs, not one link to follow. A source has to fetch in under 10 MB and yields at most 2,000 chunks.
Fixed-size chunking, stated plainly
Text is cut into roughly 1,000-character chunks with 200 characters of overlap, breaking at the nearest paragraph, line, or sentence boundary. It is not structure-aware. Headings, code blocks, and tables get no special handling, and a wide table will not survive the split intact. The overlap is what stops a sentence being severed mid-thought.
Passages arrive labelled
Retrieved text reaches the agent numbered and tagged with where it came from: "[1] (source: Refund Policy)". That is the knowledge base name, not the document, and there is no click-through link. Nothing forces the agent to repeat the label out loud, so treat it as provenance in your transcripts rather than a citation your customer sees.
Re-index on demand
One button, one API call: sync re-reads every source and replaces the vectors. Old vectors are pruned only after every source re-indexes cleanly, so a dead link leaves yesterday’s answers standing instead of emptying the knowledge base. There is no refresh schedule and nothing watching your pages, so you sync when you know something changed.
Scoping is per agent, not per user
A knowledge base belongs to one organisation and is unreachable outside it. Past that, the only scoping is which knowledge bases you attach to which agent. There are no per-entry audience tags and no per-user permissions: anyone who can talk to an agent can reach everything in every knowledge base attached to it. Keep internal material in its own knowledge base, attached only to internal agents.
A relevance floor you set
Each knowledge base carries a minimum similarity score, 0.35 by default, and a cap on how many passages come back, five by default. Both are per knowledge base per agent, in the dashboard as Match strictness and Passages read. The floor is enforced by the search engine, so weak matches never reach the model at all. It lowers the odds of a confident wrong answer. It does not remove them.
Four steps from raw docs to grounded answers.
Connect a source
Paste a URL, point at a PDF Saaya can fetch, or type the text straight in. Give it a filename so you can tell your sources apart later. Indexing runs in the background and the knowledge base reads as processing until it finishes.
Chunk & embed
Text is split into ~1,000-character overlapping chunks and embedded with the platform embedding model. There is no per-knowledge-base model choice, on any tier. Vectors land in a collection of their own, named for the knowledge base, on Saaya’s managed cluster.
Search mid-conversation
Knowledge search is a tool the agent calls when it judges the question needs it. Your prompt steers that; it is not automatic on every turn. The search returns the top passages above the relevance floor, ranked by score and merged across the knowledge bases attached to that agent.
Answer, or say so
Passages come back numbered and labelled, and the agent is instructed to answer from those alone. If nothing clears the floor, or the search itself fails, the agent is told to say it does not have that information rather than guess. Where it goes next, a person or a callback or a ticket, is a handover you wire yourself.
A working KB, ready to ship.
import { createKnowledgeBase } from '@saaya/sdk'
// Source types: 'url' (one page, no crawl), 'pdf' (fetched by URL),
// 'text' (inline). Indexing runs in the background.
export const productDocs = await createKnowledgeBase({
name: 'Product docs',
description: 'Public help-centre pages and the handbook.',
sources: [
{ type: 'url', filename: 'Billing FAQ', file_url: 'https://docs.acme.com/billing' },
{ type: 'url', filename: 'Cancellation', file_url: 'https://docs.acme.com/billing/cancel' },
{ type: 'pdf', filename: 'handbook.pdf', file_url: 'https://storage.example.com/acme-public/handbook.pdf' },
],
})On every tier, what you get.
Tiers change how many knowledge bases you get. They do not change the retrieval engine: same chunking, same embedding model, same relevance floor on every plan.
1 knowledge base · on-demand sync · relevance floor and passage cap included.
10 knowledge bases · on-demand sync · relevance floor and passage cap, tuned per KB per agent.
Knowledge-base limits negotiated. Same retrieval engine as Free.
Pair this with the right Solution.
Frequently Asked Questions.
Less than we used to claim on this page. What you get is the plumbing, already running: fetching and text extraction for pages and PDFs, chunking, embedding, a collection per knowledge base, background re-indexing that prunes safely, a relevance floor and passage cap you set per knowledge base per agent, and a search tool already wired into the live voice and chat runtime with the prompt text that tells the model what to do when nothing comes back. What you do not get is structure-aware chunking, a crawler, refresh schedules, per-entry permissions, or a choice of embedding model. If you need those, you would be building them on top of us rather than instead of us.
Ground your agents.
Add a URL or paste a page, attach it to an agent, and the next conversation searches it. Set the relevance floor where you attach it — that dial is the one that matters.