Knowledge Bases
Create and manage Knowledge Bases — the document libraries agents search when generating replies, summaries, and decisions.
Use this Studio state to connect the product UI to a real business operation: customer signal, agent behavior, workflow path, channel, CRM context, and review outcome.
Summary
Create and manage Knowledge Bases — the document libraries agents search when generating replies, summaries, and decisions.
Concepts covered
Step breakdown
- Open ResourcesStart in the Resources area and confirm what the real screen is showing.
- Inspect product behaviorUse screenshots and visible product states to understand what the screen does, why it exists, and how teams use it.
- Connect the platformSee how the screen connects to agents, workflows, records, activity, channels, integrations, or ownership.
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.
Operational playbook
Use Knowledge Bases as part of the Frontline Studio Resources operating loop: inspect the current product state, confirm the source context, and decide what should happen next.
The goal is not to memorize screens. The goal is to understand how the product surface supports repeatable work, AI assistance, and accountable handoff.
Best practices
Start with the operational job before changing configuration. Name the owner, define the trigger or source context, and decide how the result should be reviewed.
Prefer narrow, inspectable setups over broad automation. Teammates should be able to explain why the system took an action from the visible product state.
Troubleshooting
If the result does not match expectation, check the source context first, then permissions, connected integrations, required fields, workflow logs, and any AI-generated output used by downstream steps.
When in doubt, compare the latest product state with the related record, activity, or workflow execution so debugging starts from evidence rather than guesswork.
FAQs
What does Knowledge Bases teach?
Create and manage Knowledge Bases — the document libraries agents search when generating replies, summaries, and decisions.
How should teams use this lesson?
Use it as a product walkthrough: understand the real screen, the product behavior, the operational outcome, and how the area connects with the rest of Frontline.
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.