Knowledge base
Give the agent facts to draw on, so it looks things up instead of inventing them.
The knowledge base is the source material the agent reads to answer questions the prompt alone cannot cover: your pricing, your policies, your FAQ, your product details. You add sources, the platform splits and indexes them, and the agent retrieves the relevant pieces when a caller asks. It is one of the shared capabilities of the agent, so the same knowledge serves both the voice and the text agent.
When to use a knowledge base
The prompt is the right home for persona and rules: how the agent should behave, the order it does things, the tone it takes. It is the wrong home for long lists of facts, and especially for facts that change.
Use a knowledge base when the information is:
- Too long to live in the prompt. A 40-line refund policy or a full price list bloats the prompt and the agent reads it on every turn whether the caller asked or not.
- Likely to change. Prices, opening hours, plan tiers, eligibility rules. You update one source instead of rewriting the prompt.
- Reference material the caller asks about by name. Product specs, a FAQ, terms and conditions.
The rule of thumb: keep persona and rules in the prompt, keep facts in the knowledge base. That way a price change is one edit to one source, not a prompt rewrite.
The knowledge base is per agent. Each agent has its own sources, and they are not shared across agents in the workspace. Within a single agent, the voice and text surfaces both read the same knowledge.
The three source types
You add knowledge from the Knowledge section of the agent editor. There are three ways to add a source:
- Upload a file. Supported formats are PDF, Word (
.docx), plain text (.txt), Markdown (.md), and CSV (.csv). Files can be up to 10MB. - URL to a web page. The platform fetches the page and reads its content. Pages behind a login or that render entirely in the browser may come back empty, and the source is marked failed with a reason.
- Text pasted directly. Give it an optional name and paste a snippet or a whole article.
Whichever type you pick, the platform takes it from there. You do not edit the indexed content by hand: adding (or re-fetching) the source is all you do.
How ingestion works
Every source, of every type, goes through the same pipeline:
- Extract. The raw text is pulled out of the file, the web page, or the pasted content.
- Chunk. The text is split into overlapping pieces of roughly 500 tokens each, broken on paragraph and sentence boundaries so a chunk reads as a coherent passage. The overlap keeps context from spilling across a boundary.
- Embed. Each chunk is turned into a vector (a numeric fingerprint of its meaning) so it can be matched by meaning, not just by keyword.
A source moves through statuses as this runs: pending, extracting, embedding, then ready (or failed, with an error message you can read in the detail pane). A ready source is searchable; a failed one is not, and you can re-fetch it to try again.
Ingestion runs a paid embedding step, metered to your workspace by token count. The add dialog says so before you confirm. See Billing and credits.
How the agent retrieves it
The knowledge base does nothing on its own. The agent reaches it through the Search knowledge base builtin tool. When a caller asks something the prompt does not answer, the model calls that tool with a short search query. The platform embeds the query the same way it embedded the chunks, finds the closest matches by meaning, and returns the most relevant passages for the model to answer from.
Two things follow from this:
- The tool must be on the agent. The knowledge base only helps if Search knowledge base is one of the agent's tools. When you add your first source, the platform attaches the tool to the draft automatically so this works out of the box. If you removed it, add it back from the Tools section.
- Retrieval is by relevance, not by reading everything. The agent gets back a small set of the closest-matching passages, not the whole knowledge base. Only passages above a relevance threshold come back, so a query with no good match returns nothing rather than a weak guess.
When the search finds nothing relevant, the tool tells the model to say it does not have that information and offer to take a message or transfer to a human. This is deliberate: the agent should look it up and, if it is not there, admit the gap, never invent an answer.
Pairing the knowledge base with the prompt and tools
The knowledge base earns its place when it works with the other two surfaces.
- Prompt: tell the agent to look things up. A line like "For anything about pricing, plans, or policy, use the Search knowledge base tool before answering. If it returns nothing, say you do not have that detail and offer to take a message" turns the knowledge base from a passive store into a habit. See Prompt.
- Tools: the Search knowledge base tool's description is where you tell the model when to search, for example "use this when the caller asks about plans, pricing, refunds, or eligibility". A good description means the agent reaches for the knowledge base at the right moments. See Tools.
The combined effect is a look-it-up-do-not-invent agent: the prompt sets the rule, the tool description sets the trigger, and the knowledge base supplies the facts.
Managing sources
The Knowledge section lists every source down one side and the selected source's detail on the other. From the detail pane you can:
- Preview the indexed content as the chunks the agent will actually search.
- Re-fetch a URL source to pull the page again and re-index it, which is also how you retry a source that failed.
- Delete a source. This removes its indexed content too, so the agent stops drawing on it immediately.
Because the agent answers from what is indexed, a stale source means a stale answer. Treat the knowledge base as living content: when a price or a policy changes, update the source.
Scheduling a URL re-crawl
A URL source can go stale on its own when the page behind it changes. You can put a URL source on an auto-sync schedule so the platform re-fetches and re-indexes it on a recurring basis, for example every day at 3am or every Monday morning. The schedule is set per source, in the timezone you choose, and it fires on the platform's own clock without anyone clicking re-fetch.
Auto-sync is for URL sources only. Text and uploaded files have no remote to re-fetch, so there is nothing to schedule. Each scheduled sync is a real re-ingest: it re-fetches and re-embeds the page, and is metered to your workspace the same way a manual add is, not a free poll. It is a time-based pull only, not a webhook push.
What to put in it
Start with the things callers actually ask about and that you would not want to maintain by hand inside the prompt:
- Pricing and plan details.
- Policies: refunds, cancellations, eligibility.
- Product or service specifics.
- A FAQ in your own words.
Keep each source focused and well-written. Clear headings and short paragraphs chunk cleanly and retrieve better than a wall of text or a scanned document.