Knowledge
One knowledge base, every channel
What the agent knows is part of the agent, not of the channel. That is why the phone, the website widget and the chat all answer the same - and it is also the source of the limits on this page.
How knowledge actually gets in
Three routes, all in the agent's knowledge tab:
- A URL. Give the page address and its text content is extracted and imported. Useful for an about page, a services page, a price list.
- A document. PDF - including text recognition for scanned pages - plus Word, plain text and Markdown.
- Free text. Typed straight in. In practice this is where most of the good knowledge ends up, because it is written for the agent rather than for a website visitor.
Imported knowledge is compiled into the agent's instructions. It is not indexed into a vector store and it is not retrieved per question. There is no knowledge API, no search endpoint, no chunking, no embeddings and no citations. Every consequence on this page follows from that one fact, and knowing it will save you from designing an integration around a retrieval layer that does not exist.
- Website URLPDF / Word / textTyped knowledge
- One body of textVersioned per agentPer language
This is the step that makes it shared - and the step that bounds how much fits.
- PhoneWeb voiceWeb chatWhatsAppTelegram
No channel has its own knowledge. Maintain it once.
What follows from that
| Consequence | What to do about it |
|---|---|
| Everything is always in context - no retrieval step can miss it. | Nothing. This is the upside, and it is a real one: no failed retrieval, no irrelevant chunk, no reranking to tune. |
| Size is bounded. A URL import is capped at roughly twelve thousand characters. | Import the page that holds the facts, not the whole site. Write a condensed knowledge text instead of importing five pages. |
| Imports are point-in-time. Nothing re-crawls. | Re-import when the source changes. Put it in whatever process already exists for updating prices or hours. |
| Navigation, cookie banners and footers come along with a crawl. | Review what was imported before saving it. Boilerplate is noise the model has to read past on every turn. |
| No citations. The agent cannot say which page an answer came from. | If provenance matters - legal, medical, regulated pricing - do not rely on the agent to state it. Route to a human. |
| Live data does not belong here. | Stock, order status and availability change during the conversation. Those are tool calls, not knowledge. |
Knowledge or prompt?
Both end up in the same place, which is exactly why the distinction is worth keeping in your head:
| Prompt | Knowledge | |
|---|---|---|
| Holds | Behaviour, tone, rules, limits, escalation | Facts: hours, services, policies, prices |
| Changes when | You want the agent to act differently | The business changes |
| Written by | Whoever owns the agent's behaviour | Whoever owns the content |
| Reviewed | With the prompt reviewer | By reading it back before saving |
Writing knowledge that works out loud
Website copy and agent knowledge are not the same text. A page is skimmed; an answer is heard.
- Answer the question, do not describe the section. "Open Monday to Thursday 08:00–17:00" beats "Our opening hours can be found below."
- Strip the markup. Tables, links and asterisks are read aloud - the reviewer flags them.
- Write out what gets spoken. "Fifty euro" rather than "50,-" and spelled-out abbreviations, unless you want to hear how the model guesses.
- State the exceptions. Holiday closures, the one service you do not offer, the case that needs a person. The model fills gaps if you leave them.
- Keep it per language. Prompts are stored per language. Translated knowledge belongs with the translated prompt, not appended to it.
What a retrieval layer would be for
If your knowledge genuinely does not fit - a catalogue of thousands of products, a document base measured in megabytes - compiling it into instructions is the wrong shape, and no amount of editing fixes that. That case wants retrieval, and the honest answer today is that it is a tool call against a search index you run, not a platform feature. It is also an active research topic at neob.dev rather than something to design a launch around.
Building that index and the tool in front of it is ordinary engineering work, not a bitpull feature request. If it is not work you want to own, NEOB - the company that operates bitpull - takes it on as a project.