Knowledge Bases
Create and manage Knowledge Bases — the document libraries agents search when generating replies, summaries, and decisions.
Connect the screen to the operation it controls: customer signal, agent behavior, workflow path, channel, CRM context, and review outcome.
What the Knowledge Bases module shows
The Knowledge Bases section in Studio (Resources → Knowledge Bases) lists every KB available in your workspace. From here you can search existing KBs, open one to inspect its content, and create new ones.
Each Knowledge Base is a named document library. You name it, upload or paste content into it, and then attach it to the agents that should use it.
Creating a Knowledge Base
Open Resources → Knowledge Bases and click Create Knowledge Base. Give it a descriptive operational name — 'Support Escalation Criteria', 'Product Pricing Guide', 'Sales Objection Handling'. Add content by uploading a file or by writing or pasting text directly.
Write KB content as if instructing a new teammate, not as marketing copy. The agent reads it literally: clear, direct, operationally specific language produces more reliable behavior than promotional prose.
What makes a good Knowledge Base
Narrow scope: one KB should cover one topic. A combined product + pricing + support policy document is hard for an agent to use selectively. Create separate KBs for each distinct knowledge domain.
Current content: outdated KBs produce outdated agent responses. Update KBs when product details, pricing, or policies change — agents attached to that KB pick up the new content automatically.
Structured format: numbered lists, clear headings, and explicit 'If X then Y' rules work better than paragraphs. Agents extract structured patterns more reliably than flowing prose.
Attaching a KB to an agent
Creating a KB does not automatically give any agent access to it. To attach it, open the agent in Agent Builder, go to Settings → Knowledge Bases, and select the KB from the dropdown. Save to apply.
After attaching, use the agent Preview to test whether the KB is improving responses. Ask questions the KB should answer and check whether the agent cites the right information without improvising details that are not in the KB.
Good first Knowledge Bases
Support Escalation Criteria: categories, urgency definitions, handoff rules, and examples of cases that must go to a human.
Pricing and Plan Rules: what each plan includes, when to mention limits, and which pricing questions must be escalated.
Sales Objection Handling: approved responses, proof points, and what an agent should ask before recommending the next step.
Writing rules
Write KB content like internal operating instructions. Short sections, explicit conditions, examples, and escalation rules work better than long marketing copy.
Do not mix unrelated topics. If support policy and pricing policy change on different schedules, they should be separate KBs.
Debugging KB answers
If an answer is generic, the KB may be too broad or not attached to the agent. If an answer is wrong, update the source content before changing the prompt.
If an agent answers outside the KB, add an instruction that unsupported questions should be escalated or answered with a clear limitation.
FAQs
What is a Knowledge Base for?
Create and manage Knowledge Bases — the document libraries agents search when generating replies, summaries, and decisions.
What should go into a Knowledge Base?
Use approved operating knowledge: support policies, product limits, pricing rules, objection handling, escalation criteria, onboarding steps, or other content an agent should not invent.
How should this page fit into onboarding?
Use it to understand the product surface, inspect real UI states, and connect the concept to daily operating workflows before configuring production behavior.
What should I verify before using this in production?
Verify ownership, permissions, source context, failure behavior, and the handoff path so teammates can trust what the system does next.