A knowledge base is a website Talqing has crawled, transcribed page by page into clean Markdown, and organized into a table of contents. Attach it to an agent and the agent can answer from that content instead of from a prompt you keep growing. Content comes from websites and the PDFs linked from them. Nothing else. There is no file upload, no Google Drive, no Notion, no Confluence, no pasted text. If the content is not on a URL the crawler can reach, it cannot go into a knowledge base — put it on a page, or serve it through a tool.

​
How retrieval actually works

This is the part worth reading before you design anything on top of it, because it is not the embedding-and-similarity-search setup the phrase “knowledge base” usually implies. There is no embedding model and no vector index anywhere in this. What happens instead:
  1. The table of contents goes into the agent’s system prompt. Every entry, one line each: a short id, a title and a one-to-two-line summary. Content is not in it. That block is the same string on every turn of every call, so it sits in the model’s prompt cache and costs close to nothing per turn.
  2. The model picks entries by reading them. When a caller asks something, the model looks at the map it was given, decides which entries look like they hold the answer, and calls a knowledge_fetch tool with their ids.
  3. The verbatim page text comes back. Up to 24,000 characters across the call, straight out of the transcribed page. The model answers from that.
So retrieval is a model reading titles and summaries and choosing. There is no scoring, no nearest-neighbour lookup, nothing that will surface a page whose summary does not describe what the caller asked for.
The quality of your titles and summaries is the quality of your knowledge base. An entry called “Information” with the summary “Details about our products” will never be fetched, no matter how good the page behind it is. Read the map the agent is actually given before you trust it — see editing.
The upside of doing it this way is that you can see exactly why the agent fetched what it fetched, and fix it by rewriting a sentence. The downside is that there is no fallback: nothing retrieves a page the model did not choose.

​
When it beats putting facts in the prompt

A knowledge base is a snapshot. It reflects the site as it was on the day you built it, and nothing re-crawls on a schedule. When the site changes, you run the build again.

​
The shape of one

A knowledge base moves through discovering → review → transcribing → generating → ready, with error if it stops. Only a ready one can be attached to an agent. The whole lifecycle is in building.

​
In the dashboard

Knowledge bases are listed under Knowledge at https://app.talqing.com/knowledge. Opening one shows the build stage, the URL review step, the table of contents, the per-page transcription status, a preview of the exact prompt block an agent receives, and the KnowledgeCoPilot beside the tree it edits.
Knowledge bases are regional, like everything else a workspace owns. One built against https://api.in.talqing.com does not exist in https://api.us.talqing.com. The same token works in both — see regions.

​
Next

Building one

Crawl, choose the pages worth indexing, watch the build, and read what failed.

Using it in an agent

kb_ids, the knowledge_fetch tool, and how to prompt an agent so it actually consults its knowledge.