Wetel
Go back

Answering from your own policies, with sources you can check

Ask two colleagues how many days of leave a new hire gets. The first answers from memory: confident, quick, and right most of the time. The second pulls the policy binder off the shelf, finds the section, reads it, and answers from what is written there. If you ask “where does it say that?”, the second colleague can show you the page.

You want an AI employee to be the second colleague. A language model on its own is the first one: it answers from what it learned in general, which knows nothing about your leave policy, your refund rules or the handbook you updated last month. This post shows how a Wetel AI employee answers from your own documents instead, how you check which passages it used, how you keep those documents current, and where the honest limits are. It is written for the operations lead who owns the policies and the developer who wires them in.

The short version: a knowledge base, attached to one step

You put your documents in a knowledge base, attach it to an llm step in the AI employee’s workflow, and that step looks up the relevant passages before it answers. A knowledge base is a collection of documents that belongs to your workspace. It is not attached to the AI employee as a whole: you attach it to the particular step that should answer from it, and the same knowledge base can serve several steps and several workflows.

flowchart LR
  Q["Customer asks<br/>a question"] --> R["llm step looks up<br/>the closest passages"]
  KB[("Your knowledge base")] --> R
  R --> A["Model answers using<br/>those passages"]
  A --> Y["Reply to the customer"]
  R -. "which passages, or why none" .-> T["Run record"]

A workspace owner decides what goes in the knowledge base and what the workflow does with the answer. The AI employee looks things up; your people own the binder.

What you can put in

Policies and documents arrive in three ways, each with a documented size limit.

Each format becomes plain text before it is stored. Spreadsheets get one detail that matters for policy tables: every row is written out with its column names (Header: value | Header: value), so a passage cut from the middle of a long table still says which column each value belongs to. Each sheet of a workbook is labelled, too.

The text is then split into passages of roughly 512 words, with some overlap between neighbouring passages, so a rule that sits across a page break is not lost.

How much fits depends on your plan. The documented limits today are one knowledge base, 500 passages and 10 MB of storage on the DEV plan, and ten knowledge bases, 20,000 passages and 500 MB on PRO. A refusal tells you which limit you reached. See plan limits.

How the lookup feeds the answer

For every message, the step finds the passages closest in meaning to what was asked and gives them to the model as reference material. The customer’s message is turned into a numeric fingerprint and compared with the fingerprints of your passages; the closest few are joined into a reference block and placed in the model’s context before it answers. The model sees them as reference material, not as something the customer typed.

By default, the step also tells the model to answer only from that material and to say so plainly if the material does not contain the answer. That default is the “look it up in the binder” behaviour, and for policy questions it is the one you want.

Two details are worth knowing before you rely on it:

Here is the step from the docs’ own support recipe, with the knowledge base attached:

{
  "id": "answer_from_kb",
  "type": "llm",
  "label": "Answer From Product FAQ",
  "config": {
    "promptTemplate": "You are a helpful support assistant. Answer the user's question using the provided reference material where relevant: {{userMessage}}",
    "knowledgeBaseId": 88,
    "outputVar": "kb_answer"
  }
}

Seeing the sources behind an answer

Every run leaves a record of which passages the step retrieved, and you can trace each passage back to its document. In the run record, an llm step with a knowledge base carries retrievedChunkIds (the passages it used) or retrievalError (why the lookup did not run). You read the run record with a dashboard login; see inspecting the run record.

Before you go live, you can see the same thing from the other side. The retrieveChunks query runs exactly the lookup the step uses and returns, for any question you type, the passages it would retrieve, each with its source document, the passage text and a similarity score:

query TestRetrieval {
  retrieveChunks(
    knowledgeBaseId: 123
    query: "What is the onboarding process?"
    topK: 5
  ) {
    chunkId
    documentId
    content
    score
  }
}

Try it with the phrasing your customers really use, not the wording of the policy. The recipe’s advice: if the right passage does not come back near the top for a paraphrased question, revisit the wording or the structure of the source document before building the rest of the workflow.

What the docs do not describe is a list of sources returned with the reply itself. The colleague in our analogy can show you the page; today, that check is something you do from the run record and the test query, not something the AI employee hands to the customer automatically.

Your documents stay in your workspace

Every knowledge base, document and passage belongs to one workspace, and only signed-in users of that workspace can manage or query them. Every request is tied to the workspace of the signed-in session, and a request for one workspace cannot see another workspace’s knowledge. Workspaces share the platform’s database; separation is enforced on every request, and a dedicated database is not offered today. More on that in is my company’s data kept separate?

Keeping the policies current

When a policy changes, change the document in the knowledge base; the next question is answered from the new text. The tools for that are:

Two cautions. First, deleting a whole knowledge base does not delete its documents and passages; they stay in storage, unreachable. If a policy must be removed for good, delete its documents one by one first. Second, the docs describe no automatic link to wherever your policies are maintained, so updating the knowledge base is a job someone owns. Put a name on it, the same way someone owns the binder on the shelf.

When the answer is not in the documents

By default the step tells the model to say that the material does not contain the answer, and the recipe adds the same instruction to the AI employee’s persona. The support recipe’s persona reads, in part: “If something isn’t covered by your reference material, say you don’t have that information and suggest the user contact human support — never guess at policy details.” Use that pattern: an honest “I don’t have that” plus a route to a person.

One more case to plan for: if the lookup itself fails (a temporary error, not “nothing found”), the step carries on without reference material rather than failing the turn, so the AI employee still replies. That is a deliberate choice to keep it online, but it means a configured knowledge base is not proof that a given answer used it. The run record tells the two apart: retrievedChunkIds when the lookup ran, retrievalError when it did not.

The honest limits, and where to add a person

We do not publish an accuracy figure for answers from a knowledge base, and answers can still be wrong. A model can misread a passage, combine two rules that do not belong together, or answer from the nearest passage when the right one was never uploaded. Test with your own questions and documents before you depend on it.

For answers that lead to something consequential (a refund, an exception to a policy, a promise to a customer), add an approval step. You add it to the workflow; it is not on by default. The run pauses, a workspace owner sees the request in the app and approves or rejects it, and the workflow follows the matching path, including an explicit path for when nobody answers in time. Approvers are told in the app; email notice is not sent today.

flowchart LR
  K["llm step answers<br/>from the policy"] --> P{{"approval:<br/>owner checks it"}}
  P -- approved --> G["send the answer<br/>or act on it"]
  P -- rejected --> N["tell the customer<br/>a person will reply"]
  P -- expired --> X["hand over<br/>to the team"]

Live today: knowledge bases, pasted text, file and single-page uploads, the lookup on an llm step, the test query, the run record, editing and deleting documents, and an approval step you can add. Not described in the docs: a list of sources returned with the reply, a minimum relevance score, an automatic sync from where your documents live, and a published accuracy figure.

If you would rather run the lookup yourself, Wetel can also produce the numeric fingerprints for your own search index; see Embeddings.

To build it, start with the Knowledge Base guide: it takes you from an empty knowledge base to a step that answers from your own documents.

Share this post:
Share this post on Whatsapp Share this post on X Share this post on Linkedin Share this post via email
Next Post
When not to use an AI employee: a buyer's guide that says no
Previous Post
Which AI model does my AI employee use, and what happens if it fails?