> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anyreach.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Attaching a knowledge base

> Wire a knowledge base to an agent so it can answer factual questions.

A knowledge base (KB) gives an agent a body of factual content to draw from — product specs, FAQs, policy documents, scraped support pages. When attached, the agent retrieves relevant chunks at every turn and includes them in the LLM context.

## Attach a KB

<Steps>
  <Step title="Open Knowledge section">
    On the agent edit page, click the **Knowledge** section.
  </Step>

  <Step title="Click Attach knowledge base">
    Pick from your existing KBs. You can attach more than one.
  </Step>

  <Step title="Set retrieval parameters (optional)">
    Most agents work fine with defaults. See [tuning](#tuning-retrieval) below.
  </Step>

  <Step title="Save and republish">
    Changes only apply to new calls after the agent is republished.
  </Step>
</Steps>

## How retrieval works

At each user turn:

1. The agent's STT produces a transcript of what the caller said.
2. The platform embeds that turn (plus a small window of conversation context).
3. It performs a vector similarity search across all attached KBs.
4. The top **top\_n** chunks (default 5) are inserted into the LLM context for that turn.
5. The LLM generates a response that can quote or paraphrase the chunks.

The agent does this implicitly — you don't have to tell the prompt to "use the knowledge base."

## Tuning retrieval

| Lever        | Default | When to change                                                                                                                              |
| ------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| `top_n`      | `5`     | Increase to `8-10` if answers are missing context. Decrease to `3` if the LLM keeps quoting irrelevant snippets.                            |
| Multiple KBs | One     | Split into multiple KBs when the content covers very distinct domains (e.g. *Product FAQ* + *Returns Policy*) so retrieval is more focused. |

## When implicit retrieval isn't enough

For most use cases, just attaching a KB is sufficient. Reach for explicit `knowledge_base` tools (see [Tools](/agents/tools)) when:

* You want the agent to announce that it's looking something up
* You want different KBs queried for different question types ("for product questions, query Product FAQ; for policy questions, query Policy KB")
* You want a higher `top_n` for some questions than the default

## Anti-patterns

**Putting too much in one KB.** If your KB has 10,000 chunks covering five unrelated domains, retrieval will be noisy. Split it.

**Stale content.** Embeddings are recomputed only when sources are added or updated. If your product changes, refresh the KB.

**Treating the KB as a memory store.** KBs are for static reference content. For per-call state (the caller's name, what they asked earlier), rely on the conversation context, not retrieval.

## Pairing KBs with prompts

If you instruct the agent in the system prompt to *"only answer from the knowledge base — don't make things up"*, you'll get fewer hallucinations but more "I don't know" responses. Conversely, telling it to *"use the knowledge base when relevant, otherwise answer from general knowledge"* makes it more flexible but also more prone to confident wrong answers.

For most production agents, the safer instruction is:

> When the caller asks a factual question, prefer the knowledge base. If you can't find an answer in the knowledge base, say "I don't have that information — let me get someone who does" and use the transfer tool.