A knowledge base is typically one product’s documentation site, a repo, or an internal wiki. Knowledge bases live inside a workspace and own everything needed to answer questions about that product — sources, client keys, agents, actions, and analytics.

​
Create a knowledge base

1

Create the knowledge base

From the dashboard at app.beforequery.com, open your workspace and click New Knowledge Base. Give it a name.
2

Connect your first source

Point the knowledge base at a docs URL — the fastest way to get answers flowing — or pick any other source type from the Sources tab.
3

Test in the Playground

Once the first sync finishes, ask a question in the Playground and check the citations.
The number of knowledge bases you can create depends on your workspace plan — see Billing & Plans.

​
Knowledge Base settings

Each knowledge base carries its own answer configuration, editable under Knowledge Base → Settings:

​
What a knowledge base owns

  • Sources — websites, git repos, connectors, files, and more.
  • Source groups — model docs versions or products within one knowledge base.
  • Client keys — per-knowledge-base credentials for the widget, SDKs, and public API. See Authentication.
  • Agents & actions — agent graphs, AI actions, and approval queues.
  • Analytics & evals — knowledge gaps, per-source citations, answer quality.

​
Internal knowledge bases

A knowledge base is external by default — it can be published through the widget, SDKs, and public API once you issue a client key. Set its type to internal and it has no public face at all. This is enforced, not advisory. Every client-key surface refuses an internal knowledge base before any query runs: the public chat and search API, widget config, the MCP server, A2A, form deflection, and the WebSocket transport. The check sits in one place, so any surface added later is covered too.
  • Client keys cannot be issued for one — the dashboard rejects it, since a key that would be refused on every request shouldn’t exist.
  • The unauthenticated A2A agent card returns 404 rather than confirming it exists.
  • Every document it indexes is forced to restricted, whatever the source says.
It stays reachable from the dashboard, the Ask assistant, and /mcp/portal — by workspace members with chat permission, under exactly the same rules as any other knowledge base.
Chat bots are the one internal surface that is not per-user. Connecting a Slack, Discord, or Teams bot to an internal knowledge base publishes that knowledge to everyone in the channel. See Bots.

​
Archive a knowledge base

Archiving takes a knowledge base out of active use without deleting its indexed content — use Knowledge Base → Settings → Archive. To remove a knowledge base and its documents permanently, use Delete instead. Both actions are recorded in the workspace audit log.

​
One knowledge base or many?

  • One product, multiple docs versions → one knowledge base with source groups (v1, v2, latest).
  • Multiple products with separate audiences → separate knowledge bases, each with its own widget, keys, and analytics.
  • Internal + external knowledge for the same product → one knowledge base; mark internal pages restricted (see Roles & Permissions) or isolate them in an internal-only source group.
  • Knowledge that must never reach customers → a separate internal knowledge base, so there’s no public surface to misconfigure in the first place.